Dashboard Requirements: What to Settle Before Anyone Builds
A dashboard request names a subject. A requirement names a decision, the person who makes it and what they need to see to make it. Seven things have to be settled before building, and the first of them decides whether a dashboard is the right answer at all.
A request for a dashboard names a subject: complaints, sales, waiting times. It says what the dashboard is about and nothing about what it is for. Built from the subject alone, a dashboard shows everything that can be counted about it and answers no particular question, because none was asked.
Requirements work is the conversation that turns the request into something buildable. This guide sets out the seven things to settle, in order; how to run the conversation with the person asking; and when the right outcome is something simpler than a dashboard. It covers the stage before building. What to check when a finished dashboard is not used is a separate question.
What a dashboard is for
It helps to be exact about the object. Stephen Few’s definition, written in 2004 to clear up confusion in the market, still does the job: “A dashboard is a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance”1.
Three parts of that sentence are requirements in disguise. “Needed to achieve one or more objectives” means there must be objectives, stated. “The most important information” means something has been left out. “Monitored at a glance” means the reader returns to it regularly to see whether anything has changed. Few adds a limit that is worth telling a requester early: a dashboard “quickly tells you what’s happening, but not why”1.
A display that nobody monitors, that serves no stated objective, or that is expected to explain causes is not a dashboard in this sense, and may not need to be one.
Research on dashboards as they are used supports starting from purpose and audience. A survey of dashboards in practice, written in 2018 by researchers at Microsoft, Tableau Research and Simon Fraser University, found that the term now covers far more than Few’s monitoring screen. In the authors’ words, a dashboard’s purpose has expanded so far that it “may not even support decision-making at all”2. They describe a dashboard by “design dimensions such as functional design, purpose, audience, and data semantics”2, and observe that “The visual and functional aspects of a dashboard typically reflect the intended audience, their domain and visualization experience, and their agency relationship with the data”2. For requirements work the implication is direct. Since the word no longer settles what is being asked for, purpose and audience have to be asked about first, and the answers decide the rest.
The seven things to settle
The seven are DII’s ordering of what a builder needs. They run from purpose to acceptance, and each depends on the ones before it.
Seven things to settle before building a dashboard
| Settle | The question | A sign it has not been settled |
|---|---|---|
| 1. Decision | What will someone do differently because of this? | The answer is that it would be useful to see |
| 2. Audience | Who looks at it, how often, and in what setting? | “Everyone” or “management” |
| 3. Measures | Which few measures, with which definitions? | A list of every field available |
| 4. Grain | At what level of detail, over what period, with what comparison? | A wish to drill into anything |
| 5. Refresh | How current must it be for the decision? | “Real time”, with no reason given |
| 6. Access | Who may see which rows, and is any of it sensitive? | Not discussed until the first complaint |
| 7. Acceptance | How will we know it is right and finished? | The requester expects to know it on sight |
1. The decision
Everything else follows from this. The question is what the reader will decide or do, and how often. An operations manager deciding each Monday which sites get extra staff is a decision. Leadership wanting visibility of operations is not.
The UK government’s guidance on performance measurement offers a form that works for dashboards too. It asks teams to write hypotheses, and explains why: “Hypotheses will help you make better decisions with data, because they let you measure the effect of a specific course of action you’ve chosen to follow”3. A dashboard requirement can be written the same way: if this measure moves, this person will do that. Where the business outcome behind the decision is unclear, the chain from outcome to data in how to align a data strategy to business outcomes is the place to start.
If no decision can be named, stop. This is the most useful moment in the whole process to say that a dashboard may not be needed.
2. The audience
A dashboard for a named role, used in a known setting, can be designed. One for everyone cannot. The UK government’s service design guidance states the general rule: “If you do not understand who they are or what they need from your service, you cannot build the right thing”4.
The same guidance contains a discipline that prevents a common failure. It tells teams to “Treat any opinions or suggestions that do not come from users as assumptions that have to be proven by doing research”4. In dashboard work the requester may not be the user. A director asks for a dashboard their managers will use. The managers have to be in the conversation, or the requirement records what a director imagines a manager needs.
3. The measures
Few’s phrase is “the most important information”1, and the work here is exclusion. The same service guidance gives the reason: “Focus on what’s most important for your users so you do not create an unmanageable list of user needs”4.
Each measure needs a definition that already exists or is agreed now. A dashboard is the wrong place to discover that two teams calculate a KPI differently, and the right moment to find out. The elements of a complete definition are set out in how to define KPIs and metrics that mean the same thing everywhere, and the KPI Register / Definition Worksheet holds them.
4. The grain
Grain is the level of detail and the comparison. Daily or monthly. By site or by region. Against target, against last year, or against a threshold. A number with nothing to compare it to tells the reader nothing about whether to act.
The request to “drill into anything” should be resisted. It turns a dashboard into an exploration tool, which is a different product with different requirements. Agree the two or three paths a reader will actually follow.
5. The refresh
How current the data must be depends on how often the decision is made. A weekly staffing decision needs data that is right on Monday morning, and gains nothing from updates every minute. Faster refresh costs more to build and to run and brings more ways to fail, so it should be justified by the decision.
Agree also what happens when the data is late or incomplete. A dashboard that shows its last refresh time, and says so when a load has failed, keeps its reader’s trust through a bad day.
6. Access
Decide who may see what before the build, because the answer shapes the data model. A sales dashboard where each manager sees only their own region is a different build from one where everyone sees everything. If any of the data is personal or commercially sensitive, say so now.
7. Acceptance
Write down how the finished dashboard will be judged. Useful acceptance criteria are specific: the total reconciles to the finance system for last month; the operations manager can answer the Monday question in under a minute; the figures match the existing report for three named sites. The UK Government Data Quality Framework supplies the principle: “Understanding user needs is essential to ensuring that data is fit for purpose”5. Acceptance is where fitness for the stated purpose is tested.
Checks on the data itself, as opposed to the display, belong further upstream and are discussed in where to put data quality checks in a pipeline.
Running the conversation
The seven are settled in conversation, not by sending a form. A sequence that works:
- Ask what happened. Asking what prompted the request produces the real need more reliably than asking what the requester wants to see. Behind a request there is often an event: a missed target, a question nobody could answer in a meeting.
- Ask what they do now. The spreadsheet or report in use today shows what they actually look at and what they ignore.
- Ask the decision question. What would you do differently on seeing this? Stay on it until there is an answer.
- Sketch before building. A drawing on paper, with invented numbers, exposes misunderstandings in minutes. The requester can react to a picture when they could not specify one.
- Write it down and confirm. One page, seven headings, sent back for agreement.
The Dashboard Requirements Template is that page: the seven headings with prompts for each and a place for the sketch and the acceptance criteria.
When to decline a dashboard
The requirements conversation sometimes shows that a dashboard is the wrong answer. Saying so is part of the job. DII would decline, and offer something else, in four cases.
- The question is asked once. A one-off analysis answers it. A dashboard would be maintained indefinitely for a question nobody asks again.
- The need is to be told when something goes wrong. An alert does that. Nobody should have to look at a screen every day to discover an exception.
- The reader needs the detail, not the summary. A list or an export serves someone who works through individual cases.
- The need is to understand why. That is analysis. As Few’s definition implies, a dashboard shows what is happening and passes the question of cause to something else.
Declining is easier when it comes with the alternative and a reason tied to the decision the requester described.
After the build
Requirements do not end at launch. The acceptance criteria become the first review, and the decision named at step one becomes the test of whether the dashboard is still earning its place. The Dashboard Review Checklist covers that check. When a dashboard that was built carefully is still not used, the causes are examined in order in why dashboards go unused, and what to check before rebuilding. How one well-specified dashboard fits into a function people can rely on is the subject of what makes business intelligence trustworthy.
Sources
- Few, S. Dashboard Confusion. Intelligent Enterprise, 20 March 2004 (Perceptual Edge). 20 March 2004.
- Sarikaya, A., Correll, M., Bartram, L., Tory, M. and Fisher, D. What Do We Talk About When We Talk About Dashboards? (author manuscript for IEEE Transactions on Visualization and Computer Graphics; presented at IEEE InfoVis 2018). 2018.
- Government Digital Service (UK Government). How to set performance metrics for your service (Service Manual). 5 December 2017.
- Government Digital Service (UK Government). Learning about users and their needs (Service Manual). Updated 23 March 2017.
- Government Data Quality Hub (UK Government). The Government Data Quality Framework. 3 December 2020.
This article is general professional information. It is not legal or regulatory advice.