One Chart, One Sentence: Chart Selection and Honest Axes for Vibe Projects

All people and products in the examples below are fictional.

First, the verdict: a chart is not decoration, it is a conclusion given shape

Many vibe projects share the same chart-page disease: plenty of charts, zero conclusions. Open the page and you get line charts, bar charts, pie charts and gauges filling the screen, yet after looking at them you still cannot say whether this month made money or lost it, which channel deserves more budget, or which step is leaking users. The fancier the charts, the easier it is to dodge responsibility: the data is all there, so if you cannot read it, that is your problem. That is not data visualization. That is outsourcing thinking to the user.

My rule is blunt: one chart may make exactly one point. Before you draw anything, write that point down as a complete sentence with subject, verb and object. For example, "Repeat customers drove sixty percent of this week's new orders" — not "order trend." The first can be checked true or false; the second can never be wrong and is therefore never useful. If you cannot write the sentence, you have not yet understood what you want to say, and the right move is to go back to the data table, not to open a charting library.

Scope first, so this does not repeat existing guides on the site: the dashboard design guide covers which cards belong on a page and in what priority order; the data table guide covers sorting, filtering and pagination in tables. This guide covers neither. It covers decisions inside a single chart: which chart type fits which data, how to draw axes honestly, and how to write colors and labels so nobody has to guess. It does not cover how data is collected or cleaned; that is upstream work.

The running fictional example: Su Qing runs an online flower shop called "Forest Nook" and built a dashboard with AI to decide how much stock to order each week. Every number is invented and exists only to explain the method.

Step one: pick the chart type with four questions, not with taste

Choosing a chart type needs classification, not aesthetics. Take any dataset and ask four questions, and the answer will narrow the options sharply.

First, comparison or composition? To compare the sizes of different categories, use a bar chart. When Su Qing compares weekly sales across five flower categories, a bar chart settles it at a glance. Composition means showing what a whole is made of and in what proportions — for example, what share of orders came from repeat customers, new customers and group buys. With fewer than five parts, a pie or donut chart works; with more than five, the slices crowd together and nobody can read them, so switch to a horizontal bar chart sorted by size.

Second, is there time involved? Any series over time defaults to a line chart. Time is the most natural horizontal axis, and a line shows trend and fluctuation together. Do not draw a time series as bars unless you want to emphasize that one particular day's absolute value stands out. Looking at twelve weeks of sales, a line lets Su Qing see the cliff in week three and the rebound in week eight at once; bars keep the trend but chop the fluctuation into pieces.

Third, distribution or relationship? To see where a pile of values clusters — for example, which range most order values fall into — use a histogram. To see whether two variables move together — for example, whether bouquet price and repeat-purchase rate rise together — use a scatter plot. These two are the most commonly confused: drawing a distribution as a line makes adjacent buckets look as if they had a sequence, and drawing a relationship as bars chops a continuous variable into fake categories.

Fourth, how much data is there? More than ten categories will crowd any chart. Aggregate before you draw: keep the top five, fold the rest into "other," or merge by business meaning. More than a few thousand points will turn a scatter plot into mush, so bucket, aggregate or sample first. A wrong chart type can be swapped; unaggregated data drawn anyway cannot be saved by any chart type.

A cheat sheet worth pinning above the desk: comparison goes to bar charts, trend to line charts, composition to bar or donut charts, distribution to histograms, relationships to scatter plots. Chart types beyond this list — radar charts, funnels, sunbursts — all have legitimate uses, but a solo team's first dashboard does not need them. Get the five basic types right before reaching for anything exotic.

Step two: the axis is the honesty line — moving it rewrites the conclusion

The easiest place to lie with a chart is not color but the axis. The same data can tell the opposite story if you change where the axis starts. Su Qing's weekly orders rise from ninety-eight to one hundred and two, a gain of just four percent; if the vertical axis is truncated at ninety, the difference in bar heights looks several times bigger, as if sales had doubled. That is not "making it look nicer." That is rewriting the facts. My rule: bar chart axes must start at zero, no exceptions. A line chart that genuinely needs to magnify a fluctuation may truncate, but the truncation must be labeled plainly on the chart, and the title must say so, for example "vertical axis starts at 90." Readers should never have to discover it themselves.

Dual axes are the second big trap. Two scales, one on each side, each line following its own units — the moment the lines cross visually, they look "related," when in fact the crossing may be pure coincidence of scale. A solo team's dashboard should not use dual axes. To compare two metrics with different units, either split them into two small charts stacked vertically, or convert one into an index or growth rate so both share a unit. Splitting looks clumsy, but it is honestly clumsy.

The third trap is an uneven time axis. If a week's data is missing and you simply join the weeks before and after, you are pretending that week never existed. Mark the gap instead: a break, a dashed segment, a grey gap — any of these works, but silently connecting does not. Likewise, never mix granularities on one axis: monthly points and a quarterly total do not belong on the same chart. One chart, one granularity.

One more detail that is constantly skipped: write the unit on the axis, not only in the legend or a footnote. Whether "amount" means yuan or ten thousand yuan is a ten-thousand-fold difference; whether "users" means cumulative or new changes the conclusion entirely. A complete axis title is the cheapest form of honesty there is.

Step three: color and labels save the reader time — they are not makeup

The most common flaw in AI-generated charts is too many colors. Seven or eight colors on one chart, each needing a legend entry, force the reader to spend half a minute decoding the color key before reading any data. The rule: at most three meaningful colors per chart. One main color for the protagonist, grey for background, one accent color for the anomaly or conclusion worth attention. In Su Qing's sales chart, normal weeks are grey and the record week gets one bright color, so the eye knows where to land first.

Color must never be the only channel carrying information. A red-green contrast can be invisible to color-blind readers, so any category distinguished by color should also be distinguished by text, shape or position. In line charts, use solid, dashed and dotted lines for different series; in bar charts, label the value directly on the bar. Direct labeling is the most underrated technique in charting: readers get the exact number without shuttling back and forth between legend and bar.

Labels belong next to the data, not piled into the legend. A legend is a last resort, for when there are more than three series and colors genuinely run out. With one or two series, write the name at the end of the line. Titles need the same treatment: do not write a noun like "Sales Statistics"; write the conclusion, like "Repeat customers carried this week's sales." Put the conclusion in the title and the definition plus time range in the subtitle, for example "Definition: paid orders; period: weeks 1–4 of October." Definitions inside the chart are ten times more useful than definitions in a document, because when a screenshot travels, the document does not travel with it.

Step four: only three interactions — hand the rest to the table

Interactive charts are easy to overbuild: zoom, pan, drill-down, cross-filtering, animation, everything switched on, and after clicking around the user still has no conclusion. A solo team's charts need exactly three interactions. First, hover for exact values: hovering a point shows the precise number and date, answering "roughly how high." Second, filtering: slicing by category or time range, answering "just this segment." Third, drill-down: from month to week, or from category to item — but at most one level deep, because two levels down the user has forgotten where they came from.

Anything beyond those three should not be piled onto the chart; it should become a table. Tables are a chart's best safety net: charts tell trends and comparisons, tables give exact values and line items. Under every important chart there should be a one-click path to its data table, or at least a data export. When a user needs to verify a number, a table is faster than any interaction. This also solves accessibility cheaply: the chart's screen-reader alternative can simply be the table, with no separate description to maintain.

Large datasets must be aggregated before rendering. Tens of thousands of points drawn straight into the browser will freeze the page, and the chart itself will be mush anyway. Bucket by time and sum or average, compress to a few hundred points, then draw; beyond two thousand points, switch a scatter plot to a heatmap or bucketed counts. Chart performance is never really a "optimize the renderer" problem; it is a "decide how fine the reader needs it" problem.

Step five: how to brief AI so you do not redo the chart three times

Most charts in vibe projects are AI-generated, and the reason for rework is usually not that the AI drew something ugly but that the brief was vague. "Draw me a nice sales chart" leaves the AI guessing. A usable brief contains five sentences: the conclusion sentence, the data fields, the chart type, the definition, and the anti-patterns. For example: "The conclusion is that repeat customers carried this week's sales; fields are order date, customer type, order amount; use a weekly stacked bar chart; definition is paid orders only; do not use a pie chart, do not use dual axes, start the vertical axis at zero." With all five sentences, the first draft is usually usable; without the definition and anti-patterns, three rounds of rework are normal.

Review should not be "does the screenshot look good" either. Run a checklist: can the conclusion sentence be read directly off the chart; does the bar axis start at zero, or is truncation labeled; are there more than three meaningful colors; are key numbers labeled directly; are the definition and time range written into the chart; does it survive on a phone without crowding or overflow; can the data table be reached in one click. Seven checks, all must pass before launch, and any failure is worth a revision. After launch, revisit: a month later, ask whether this chart has ever changed a single decision. If a chart has never influenced a decision, it is not part of the dashboard — it is decoration. Delete it, and the page gets cleaner.

Step six: does the chart still hold up on a phone

A chart that works on a desktop does not automatically work on a phone. Narrow screens crush legends, long axis labels and multi-series lines into a tangle. My rule: validate at phone width first, desktop width second. Never reverse the order, because shrinking a desktop chart is the most common shortcut — and once shrunk, the text is unreadable, the lines indistinguishable, and users are left guessing. A phone chart must pass three gates: first, horizontal axis labels must not overlap — tilt them, abbreviate them, or show every nth label, but never let words pile on top of each other; second, a line chart with more than three series should show only the two most important by default on phones, with the rest behind a filter users can add back themselves; third, hover does not exist on phones, so key values must be labeled directly on the chart, or revealed by tapping a point — never assume a mouse.

Chart library choice should follow the same standard. A solo team does not need the most feature-complete library; it needs the library with the most honest defaults. Before adopting one, ask four questions: does the vertical axis start at zero by default; is the default palette color-blind friendly; does the default font stay legible in Chinese; do the title and definition travel along when the chart is exported as an image. If any answer is no, pick another library or fix the defaults before launch. However beautiful the documentation, dishonest defaults mean every chart needs manual inspection after launch, and the cost lands later.

One more chart type deserves a specific warning: the real-time chart. Data ticking every second, a line endlessly crawling rightward, looks impressive but tells the reader nothing. Real-time charts fit exactly one scenario: a value crossing a line must trigger immediate action, like server load or stock alerts. Anywhere else, live refresh is noise. The right default is an aggregated static chart, with real-time as an opt-in, or a refresh interval stretched to minutes. A chart that moves is not the same as a chart that helps; the more frequently it moves, the harder it is to treat as a basis for decisions.

One often-neglected step deserves mention: the definition that travels with an exported chart. Many teams' charts are correct on the page and wrong once screenshotted, because the conclusion in the title survives while the definition and time range in the subtitle get cropped out. An exported image must be self-contained: conclusion in the title, definition, time range and data source in the subtitle, generation date in the footer. An export feature that cannot do this is worse than no export at all — at least on the page the user sees the complete version. Likewise, once a chart is shared into a chat group or a document, readers cannot click through interactions or open the data table, so the static version must carry more information than the interactive one, not less. Treat export as the chart's second launch: if the screenshot still stands up after circulating, the chart is truly done.

One counterintuitive closing thought: the highest achievement of charting is making people look at fewer charts. A mature team's mark is not how many charts its dashboard holds, but that anyone opening it can say within thirty seconds what to do today. Charts are the means; decisions are the end. Any chart that does not help someone decide faster, however beautiful, is a cost.

Launch checklist

• Every chart carries a complete conclusion sentence as its title.
• Chart type chosen by comparison, trend, composition, distribution or relationship; more than ten categories aggregated first.
• Bar axes start at zero; line-chart truncation is labeled on the chart.
• No dual axes; different units split into two small charts or converted to a shared unit.
• At most three meaningful colors, plus text or line style as a second channel.
• Key numbers labeled next to the data; definition and time range written into the chart.
• Interactions limited to hover values, filtering and one-level drill-down; exact values live in the table.
• Points compressed to a few hundred before rendering; readable on a phone without crowding or overflow.