A dashboard for business owners, and what belongs on it

The request usually arrives fully formed. Somebody wants a screen with the numbers on it, live, so they can stop asking three people for three different spreadsheets on a Monday morning. It is a reasonable thing to want and the version most people describe will not survive its first month.

The failure is not technical. It is that a dashboard which shows everything answers nothing, so after the novelty passes there is no specific moment in the week when opening it is the obvious thing to do. This note is about what to put on one, what to keep off, and how to tell whether you should build it at all.

Why the ones that fail, fail

A dashboard is not a report. A report is read once and answers a question somebody asked. A dashboard has to earn a place in a routine, which means it has to change what you do that day, and most do not.

The usual cause is scope. Everybody who is asked what should be on it adds something, and the result is thirty tiles that each get two seconds of attention. Nielsen Norman Group's work on dashboard design and preattentive attributes makes the underlying point precisely: people read length and position accurately and read area and angle badly, which is why pie charts, donuts and gauges consume space while communicating less than the bar chart they replaced. Their conclusion is that a dashboard has to be comprehensible without significant cognitive effort, and thirty tiles is not that.

The second cause is staleness. A number that was true at 3am is not live, and once somebody catches the dashboard disagreeing with reality they stop trusting all of it, including the parts that were correct.

The five that usually earn a place

This is not a universal list, and the point of naming five is that the constraint is the useful part. For most owner-managed businesses the set that changes behaviour looks like this.

The fifth row is the one that matters and the one nobody can fill in for you. For a clinic it is tomorrow's unfilled appointment slots. For a workshop it is jobs waiting on a part. For an agency it is hours booked against hours sold. It is whichever number, when it moves in the wrong direction, tells you about a problem before the financial numbers do.

Choose the shape before the chart

Most numbers on an owner dashboard should be text, not a chart. A single large figure with a small comparison underneath is faster to read than any visualisation of the same fact, and the comparison is what does the work: this month against the same month last year, or today against the same day last week.

• Use a plain number when there is one value and you care what it is.
• Use a bar when you are comparing a handful of things, because length is read accurately.
• Use a line only when the shape over time is the point, not decoration.
• Avoid gauges and donuts. They take the most space and are read the least accurately.
• Colour should mean a category or a threshold, never a magnitude.

The threshold point is worth spending money on. A number that turns amber when it crosses a line you set is doing something a number alone cannot, because it removes the need to remember what good looks like. That is most of the value of a dashboard and it is usually the last thing built.

What to leave off

Anything that belongs to somebody else's job. A sales team needs its own view with pipeline stages and activity on it, and putting that on the owner's screen produces a manager watching a team rather than an owner running a business. The sales-side version is a genuinely different design, and bdg-labs set out which six numbers survive the cut for that audience in their piece on what earns a slot on a sales KPI dashboard.

Also leave off vanity counters, anything you cannot act on this week, and anything that requires a person to interpret it before it means something. If a number needs a sentence of explanation every time somebody looks at it, it is a report, and reports are better as reports. We make the same argument about what to automate in automating manual reporting.

When not to build one

If your numbers live in one system already and that system has a usable summary screen, use it. A custom dashboard built on top of a tool that already answers the question is a maintenance liability bought for a cosmetic gain.

If the underlying data is not trustworthy, fix that first. A dashboard makes bad data faster to see and no more correct, and the first disagreement between the screen and the bank account ends its credibility permanently. Where the data still lives in files, the ordering problem is covered in moving from spreadsheets to a database without losing the history, and the smaller version of that decision is in when a stock spreadsheet starts costing more than it saves.

And if the honest requirement is one number, once a day, then the right build is not a dashboard. It is a message sent to you at eight in the morning with that number in it, which costs a fraction as much and gets read considerably more often.

What it costs after it is built

The build is the cheap part. The running cost is that every dashboard is coupled to the systems it reads, so an accounting package upgrade, a changed field name or a new sales process quietly breaks a tile, and a broken tile that still displays an old number is worse than one that shows an error.

Budget for someone to own it, and set the expectation that it will need attention two or three times a year. The wider version of that argument is in software maintenance cost after launch. If nobody will own it, build the eight in the morning message instead. It is not a lesser answer, it is the one that is still working in a year.