The question to ask before you build a dashboard

Most dashboards start with the same question: which numbers do you want to see?

It is a logical question. It is friendly, it is concrete, and everyone can answer it. That is exactly why it is so dangerous. The answer is always a list, and a list is not a design. That is how you end up with fifty KPIs on the wish list and eventually with the dashboard nobody opens.

The question that does work is a different one. And the conversation around it is the most important half hour of any project.

The wrong question

"Which numbers do you want to see?" invites a list. The other person thinks of what he has in Excel today, of what he once saw at another company, and of what sounds professional. Revenue, margin, EBITDA, customer satisfaction, stock turnover.

None of that is wrong. But none of it says what he is going to do with it. And without that you do not know how to show it, what to compare it with, how often it needs to refresh, or whether it belongs on a screen at all.

Revenue as a number is not an answer. Revenue against last year per week, because every Monday you decide whether to schedule extra staff for the weekend, that is an answer. It is the same number, but an entirely different page.

The right question

The question I ask is this: which decision do you make with this, and when?

That question forces three things.

• A decision. If no decision hangs on it, it is context. Fine, but it does not belong up front.
• A moment. Do you decide daily, weekly, monthly? That determines how often the report needs to refresh and what it should look like. A daily decision does not tolerate a slow page.
• A person. Who makes that decision? That is the owner of the page.

Sometimes the answer is: "I don't really decide anything with it, I just want to know." That is an honest answer, and a useful one. It tells you this number does not belong on top.

What the conversation looks like

I do not start with numbers. I start with the week of the person in front of me.

What do you do on Monday morning? Which decisions do you make that week? Which of those do you make on gut feeling, because the numbers are not on time or take too much work? What did you regret afterwards because you saw something too late?

The decisions come out of those answers. Only then do I ask what information would help. And then the numbers come by themselves, but with their context: what they should be compared with, how detailed, and how fast.

An example from retail, where I spent twenty-five years myself. An owner says he wants to see revenue per store. Ask further about the decision and it turns out that every week he decides how many hours to schedule per store. Then revenue per store is not enough. He needs revenue per hour, per store, per day of the week, with footfall next to it. That is a different dashboard from "revenue per store".

Five questions that always come back

After the decision come a few questions that settle most design choices. I ask them almost every time.

1. What do you compare it with? A number on its own says nothing. Against last year, against budget, against another branch, against a threshold? Each answer gives a different chart. And note: your ERP does not store a budget, so if it is budget, it has to come from somewhere.

2. What is normal? If the number is ten percent lower, is that an alarm or noise? The answer determines whether you need an alert and where the threshold sits.

3. What do you do when it deviates? Do you call someone, order something, change something? If the answer is "then I find out why", the page has to make finding out easy. Then you need a drill-through to detail.

4. Who else looks at it? If the sales team sees the same numbers, the page must be readable for them too. And should they see everything? That is a question for who sees what.

5. What exactly does the word mean? Revenue with or without VAT, with or without returns, on invoice date or delivery date? This is the question that takes the most time, and saves the most time. See when three people give three answers.

The question you must not forget

There is one more question, and it is skipped most often: which question can you not answer today?

All the previous questions are about what already exists. This one is about what is missing. And that is often where the biggest value is.

An owner who does not know why his revenue fell, because he does not measure footfall. A contractor who does not know how much time sits between quote and start, because nobody tracks it. A service business that does not know which client costs it money, because hours are not recorded per client.

Those answers do not come out of the ERP. Sometimes they have to be built first. But if you do not ask the question, the answer never comes to the table.

What you avoid

A few things almost always go wrong when you skip this step.

Interviewing everyone at once. In a group the loudest person talks and the rest nod. Talk to the decision makers separately, and bring the answers together afterwards. Ask everyone at once and you get a compromise.

Having the conversation with someone who does not use the report. Sometimes a dashboard is ordered by a director for a department. Then you also need to talk to the department. The director knows what he wants to see, but not always what his people need to make it happen.

Letting people propose solutions. "I want a pie chart with revenue per channel." Take it along as a wish, but ask what is decided with it. The best answer to that decision is rarely a pie chart.

Starting to build too soon. The temptation is strong. The data is there, the tools are there, and a first chart is up in an hour. But an hour building on the wrong question costs a day tearing it down later.

Why a quick prototype anyway

That sounds like it contradicts how we work, because we build a prototype quickly. But the prototype comes after this conversation, not before it.

The conversation delivers the decisions and the definitions. The prototype shows whether we understood them. People often only know what they need when they see something, and that is why building first works better than a long specification. But a prototype without this conversation only shows that you can make charts.

In practice it is half an hour to an hour per decision maker. Then we build. A week later we sit down again with the prototype, and then the question is simpler: which decision did you make with this, and what did you miss?

A simple template

For anyone who wants to do it themselves: this is the sheet I fill in per page before we start.

• Decision: what is decided with this page?
• Owner: who decides?
• Rhythm: daily, weekly, monthly?
• Headline number: which number tells you whether things are going well or badly?
• Comparison: what is it compared with?
• Normal: what is ordinary fluctuation, what is an alarm?
• Action: what happens when it deviates?
• Definitions: what exactly does each word mean?
• Missing: which question can we not answer today?

If you cannot fill in that sheet, the page is not ready to be built. That is not failure. It is exactly what the conversation was meant to deliver.

What you can automate

Not the conversation itself. But everything after it. The definitions you agree on can go into the data model as descriptions, so they show up next to every number instead of in a separate document. The thresholds from "what is normal" become automatic alerts. And you can measure the use of every page, so after a month you see whether the decision it was built for is actually being made with it.

The claim

Never ask which numbers someone wants to see. Ask which decision he makes, when, and what he compares it with. The dashboard follows from that, and whatever does not follow from a decision does not belong up front.