Against the dashboard
The default answer to any data question has become a grid of charts nobody reads. There is usually a better shape.
Someone asks for visibility, and within a sprint there is a dashboard: eight cards, four charts, a date range picker, and a number at the top that nobody can explain the provenance of. Six months later it is opened twice a week, mostly by the person who built it.
Dashboards answer questions nobody asked
A dashboard is a hedge. Rather than find out which decision the user is trying to make, it displays everything that might be relevant and delegates the analysis back to them. That is a reasonable move when you genuinely do not know the questions. It is a poor one when you do and have not bothered to ask.
What usually works better
A single answer, in a sentence, with the working shown underneath. Most people asking for a dashboard want to know whether something is fine. Tell them it is fine, tell them what would change that, and let them expand into the detail if they want it.
Where genuine exploration is needed, a good table beats a grid of charts almost every time. Tables sort, filter, and compare — the three things people actually do with data — and they do not force a visual encoding onto a question that has not been formed yet.
The one good dashboard
The exception is monitoring: a small number of known metrics, watched continuously, where deviation is the signal. That is a real job and dashboards do it well. The failure is applying that pattern to every question a product has about itself.
Before building one, try writing the sentence the user is hoping to read. If you can write it, build that instead.
Tell me what you are building.
If you have a product that is nearly right and stuck, or a blank page and a deadline, I would like to hear about it. A first call is thirty minutes and costs nothing.
Open for two projects this spring