A dashboard is not a set of charts

Start at the other end. Find one decision that somebody makes on a schedule, weekly reorder quantities, which campaigns to pause, whether to chase an invoice, how many shifts to roster, and work backwards from it.

Write the decision down as a sentence. Then write the two or three questions you would need answered to make it. Those questions are your dashboard. Everything else is a chart you built because the column was there.

This filter is brutal and it is meant to be. A CSV with forty columns will support perhaps four questions that anyone acts on. The other thirty-six columns are context you look up when a number surprises you, and context belongs in a table you can filter, not on the front page.

If you cannot name the decision, you are not building a dashboard. You are building an exploratory view, which is a legitimate thing to build, but it has different rules: it should be wide, undesigned and fast to filter, and it should not be sent to anyone.

Once you have the questions, the chart form is close to determined. There are only four questions that ordinary business data answers, and each has a form that answers it and three forms that obscure it.

Is it moving, and in which direction? A trend chart. Time on the horizontal axis, one line per series, and no more than about five series before the lines stop being readable. The common failure is a bar chart of monthly values, which makes it hard to see a slope and impossible to see a change in slope.

Which of these is bigger? A comparison chart. Horizontal bars, sorted by value, with the labels readable without turning your head. Sorting alphabetically instead of by value is the single most common way to make a comparison chart useless, because the reader's eye has to do the ranking that the chart existed to do.

Is this number typical? A distribution chart. A histogram or a box plot. This is the form people skip, and skipping it is why so many dashboards report an average that describes nobody. If your order values are bimodal, the mean sits in the empty valley between the two humps, and every decision downstream is calibrated to a customer who does not exist.

What is it made of? A composition chart. A stacked bar or a treemap, and only when the parts genuinely sum to the whole. Composition is the form most often used where comparison was meant, because a pie chart looks finished in a way a bar chart does not.

If a chart on your dashboard does not answer one of those four questions, work out which question it does answer. Usually the honest reply is "none", and it comes off.

Four omissions, and none of them are about the charts. A dashboard can be beautiful and correct and still fail the first hard question, because the reader has no way to check any of it.

No row count. Every dashboard should say how many rows it was built from, on the page, near the top. Without it there is no way to notice that this week's refresh read 4,200 rows where last week's read 11,800. That is the most common serious failure in any regularly refreshed dashboard, and it is invisible unless the count is shown.

No date range. "Sales are down" means nothing until you know whether the current period is complete. A month-to-date figure sitting next to twelve complete months will always look like a collapse. Print the first and last date in the underlying data, not the range the filter was set to.

No definition of the metric. Revenue including or excluding VAT, before or after refunds, recognised on order date or ship date. Two reasonable people will pick differently, and both will be confident. One line of definition text under each headline number removes the entire argument.

No note on what was dropped. Every load drops something: rows with null keys, dates that would not parse, negative quantities, test orders. If the dashboard does not say what was excluded and how many rows that was, then any discrepancy someone finds later becomes a question about your competence rather than a question about the data.

These four are the substance of before you trust a dashboard, and they are also the answer to the more painful problem: two dashboards over the same CSV showing different numbers. That almost always resolves to a different filter, a different date field or a different exclusion rule, none of which either dashboard declared. Why two dashboards disagree walks the reconciliation.

Four checks. They take about ten minutes and they catch most of what gets caught in a meeting instead.

Reconcile one total to something outside the file. The revenue figure against the accounting system, the headcount against the payroll list, the order count against the order confirmation emails. If you have nothing external to reconcile against, reconcile against the raw file: sum the column in the CSV with no filters and compare it with the dashboard's headline. A difference is not necessarily wrong, but you should be able to explain it before you present it.

Recompute one figure a different way. If the dashboard says the average order value is £84, work it out from total revenue divided by order count and see whether you get £84. When the two methods disagree it is nearly always because one of them is silently excluding rows the other keeps.

Check the edges. Look at the earliest and latest date, the largest and smallest value, and the row with the most nulls. Truncated loads and parsing failures show up at the edges long before they show up in the middle.

Read three rows in full. Pick three at random and follow each one from the raw file through to how it is counted on the dashboard. This is slow and it is the check that finds a wrongly joined table, which none of the other three will.

More than feels comfortable. A dashboard with four things on it that people act on is worth more than one with twenty things on it that people scroll past.

Specifically: leave off any chart you cannot say a decision for. Leave off the second chart that shows the same thing in a different form. Leave off vanity totals with no denominator. Leave off anything derived from a column you have not checked, because a figure on a dashboard reads as verified whether or not it is, and one wrong number spends the credibility of every correct one next to it.

Keep the detail table. When someone questions a figure, the ability to filter down to the rows behind it ends the conversation in thirty seconds. Without it the conversation moves to email and lasts a week.

If the dashboard is for you alone, and you built the data, most of this is overhead. You already know the row count, the date range and what you dropped, because you dropped it. Build the four charts and get on with it.

The moment the dashboard goes to someone who did not build it, everything above becomes load-bearing, because they have no way to reconstruct any of the context you carry in your head. That is the transition people miss. The dashboard did not change; the audience did.

Data Analysis App builds the dashboard from the file, and the part worth knowing about is how the figures on it are produced. A language model may decide what to compute, but it never decides what the answer is: every figure is computed twice by two independent engines, and anything the two disagree about is dropped rather than shown. The row count, the date range and the list of excluded rows are printed alongside the charts rather than left for you to reconstruct. The narrower version is the Excel dashboard generator.