What makes a dashboard good. Six rules from rebuilding one.
Published Every example is a real decision, including the wrong ones
I spent a fortnight building analytics boards for my own site, ended up with thirteen of them, and then could not find the one I actually needed. This is what I learned taking them apart.
A dashboard is good when one screen answers one question and every number on it can be explained. Almost every failure is structural rather than visual: mixed row types on a page, a zero printed where the measurement is missing, and a percentage shown where three things happened.
How do you tell a dashboard is badly organised?
Ask what one row means.
On my boards the answer was different in every section of the same page. One panel had a row per day. The next had a row per URL. Below that, a row per search query, then a row per referring site. Four units of analysis on one screen, and no way to sort or filter across them without the operation meaning something different in each block.
Naming the row makes the test mechanical rather than a matter of taste. Once each board owned one unit, placing a panel stopped being a design argument: if its row is a URL, it goes on the page whose row is a URL. That single rule removed two thirds of what I had built, because it exposed how much of it was the same table wearing different chrome.
I counted afterwards. Six panels had a row that was a URL. Six more had a row that was a referring host. Four had a row that was a query. I had not built a dashboard, I had built the same three tables repeatedly and arranged them by visual style.
The six rules
Each of these came from something being wrong first.
One screen, one row type, one question. If you cannot say what a row is, the screen is doing more than one job. Organise by the unit of analysis, never by layout. Naming a page after its visual treatment is how you end up unable to find your own work.
A missing value is not zero. This one cost me two weeks. My board reported thirty of sixty-eight pages indexed and I believed it. The real figure was sixty-four of sixty-seven. The panel was counting pages that had received a search impression and calling that indexation, and a page can be perfectly indexed while nobody searches for anything it says. Two different states, opposite responses, collapsed into one number that looked precise.
Every number names its source. My funnel runs three hundred and eighty to one hundred and sixty-nine to fifty-one to three. Four stages from four different systems, and none of them agree on what a visit is. One counts impressions, one counts visitors, one counts engaged sessions, one counts people. The step rates between them are real arithmetic, but they are not one instrument measuring one thing, and the only honest fix is to print the source next to every stage so nobody reads the chain as a single measurement.
Counts lead, percentages follow. A tile on my board read minus fifty per cent in alarming red. The underlying movement was six clicks to three. At small volumes a percentage is a magnifying glass held over noise. Show the count at full size, let the percentage sit quietly beside it, and suppress it entirely below a threshold where it stops carrying information.
Deliberate is not broken. One page on my site carries a noindex tag on purpose. The obvious treatment is red, because it is not indexed. That would be wrong: colouring a decision you made deliberately with the same colour as a failure teaches you to ignore the colour that means failure. Deliberate exclusions are muted and listed under a heading that says they are intentional. Red is reserved for the page a search engine dropped without being asked.
A status screen that is never empty is one you stop reading. My health board shows nothing that is resolved. No green ticks, no reassurance panels, no history of things that used to be wrong. If everything is fine the page is almost blank, which is the point. An alert surface with a permanent amber item on it trains you within a week to stop looking at amber.
Every derived number should carry its formula
Not in a tooltip. In the source, next to the function that produces it, as a comment a person can read.
The test I use: if someone asks where a number came from, can I answer with a named function rather than by reading through a component? Margin ratio, unrealised profit and loss, spread in basis points, size-weighted average price. Each one lives in a module whose whole job is to hold the arithmetic, and each carries the formula above it.
This sounds like housekeeping and it is not. A number nobody can derive is a number nobody can defend, and a dashboard full of undefendable numbers is a dashboard people quietly stop trusting without ever saying so.
Stale data is a state, not an absence
A feed that stops updating still looks like a feed. The chart still has a line on it, the numbers still have digits, and nothing on screen admits that what you are reading stopped being true twenty minutes ago.
This is the worst failure a live surface has, because it is invisible. Every component I build for live data now takes a feed status and renders it, and dims itself when the data goes stale. Showing a price nobody can get is worse than showing nothing, and the same is true of an operations dashboard whose source went down at lunchtime.
When is a dashboard finished?
When it is small enough that you stop working on it.
I had thirteen boards and four organic visits a month. The boards were not the problem the site had. Building them felt productive in a way that writing did not, which is exactly why it kept happening, and it is the trap I would warn anyone about hardest.
A dashboard is instrumentation. It tells you whether the work is landing; it is not the work. If yours is growing faster than the thing it measures, that is worth noticing before another panel goes on it.
Common questions
What makes a dashboard good?
A dashboard is good when one screen answers one question and every number on it can be explained. Most failures are structural rather than visual: mixed row types on one screen, a zero printed where the measurement is missing, and a percentage shown where only a handful of events happened.
How do you know a dashboard is badly organised?
Ask what one row means. If a single screen mixes rows that are days, rows that are URLs and rows that are queries, it is three dashboards sharing a page. Sorting, filtering and comparison all become ambiguous because they mean different things per section.
Should a dashboard show percentages?
Only when the underlying count is large enough for a percentage to carry information. At small volumes a percentage exaggerates: a drop from six clicks to three reads as minus fifty per cent. Show the count first and let the percentage support it.
What should a dashboard show when a value is missing?
Anything except zero. Missing and zero demand opposite responses. A page nobody searched for and a page search engines never indexed both produce no impressions, and printing zero for both hides the only difference that matters.
Why should every number name its source?
Because numbers from different systems rarely measure the same thing. A funnel drawn from four tools is four instruments with four definitions, not one measurement, and naming the source on each stage stops the arithmetic between them from looking more solid than it is.
When is a dashboard finished?
When it is small enough that you stop working on it. A dashboard is instrumentation, not the product. Time spent adding panels is time not spent on the thing the panels measure.
I build dense interfaces for products where being wrong is expensive: trading surfaces, agent consoles, operations dashboards. Book a fifteen minute call if you have one that people have quietly stopped trusting.