Dashboard requirements gathering begins with a decision

The ticket says: can I get exhibitor counts by category, split out by whether they rebooked. Priority normal. It has been sitting in the queue for nine days because it looks small.

It is small, if you build what it asks for. Two hours, one matrix visual, done. Three weeks later the same person asks for the same thing with average stand size added, then with revenue, then with last year's version beside it, and by the end of the quarter there is a report nobody planned and nobody owns.

Dashboard requirements gathering goes better when the first question back is not about the fields. It is about what the person is going to do differently once they have them.

What is the request actually for?

Ask, and in this case the answer took forty seconds. The sales director is splitting the exhibitor book across four reps for the coming cycle and wants the split to be roughly even by workload while keeping each rep on categories they know. The counts by category were a step towards that. Rebooking status was in the request because a rep who inherits a book of lapsed accounts has a harder year than one who inherits renewals.

That is a completely different piece of work from the ticket. It is a one-off allocation exercise with an arithmetic answer, and the useful deliverable is a table the director can rearrange in an afternoon. A dashboard anybody opens weekly would be the wrong artefact entirely.

Wexler, Shaffer and Cotgreave built The Big Book of Dashboards, published by Wiley in 2017, around exactly this framing. The book's subtitle is Visualizing Your Data Using Real-World Business Scenarios, and the structure follows from it: each dashboard in its 448 pages is introduced by the situation it exists to serve and the person it serves, before any chart appears. The order is the point. Scenario, then audience, then visual.

Kimball Group makes the same argument from the warehouse side. Its published description of the data warehouse and business intelligence lifecycle, read on kimballgroup.com in August 2026, sets as the overarching team goal "business acceptance of the DW/BI deliverables to support the business' decision making". Acceptance is measured by use, and use follows from the page changing what somebody does.

The one page brief

Write it before you open a report editor, and keep it to one page, because a brief nobody reads is worse than no brief since it manufactures the appearance of agreement.

Five things, in this order.

The decision sentence. One sentence beginning "After opening this page, the reader will". If you cannot finish that sentence, you do not have a requirement yet and building will not produce one.

The audience, named. Not "sales". The four regional sales directors, or the show director for the Chicago edition, or the two people in operations who run the exhibitor manual chase. Named people, because named people can be asked whether the thing works.

The cadence. Weekly on Monday, daily during show week, once a quarter for the board. Cadence determines refresh, layout, and how much history the page has to carry, and getting it wrong is the most expensive mistake in the brief because it is the hardest to reverse.

The measures, with their filters. Registrations is not a measure. Registrations created, all types, cumulative to date, excluding cancelled, is a measure. Getting the filter and window written down at brief stage prevents the argument that otherwise arrives three weeks after launch, and the wider convention for naming those measures so the filter travels with the name is worth settling separately.

What version one leaves out. An explicit exclusion list is the cheapest scope control there is, and it converts later requests from grievances into changes.

Working the exhibitor request through the brief

Take the ticket above and fill in the five lines.

Decision sentence: after opening this page, the sales director will assign each exhibitor category to one of four reps so that no rep carries more than about a quarter of the book.

Audience: one person, once, in the second week of September.

Cadence: none. This is a one-off.

Measures: exhibitor count by category for the current edition, and the same count restricted to accounts that rebooked at the last close.

Exclusions: revenue, stand size, and any comparison to prior editions.

Now do the arithmetic the director was going to do by hand, because it is the actual deliverable. The show has 412 exhibitors across nine categories, sized 96, 84, 61, 48, 41, 33, 25, 15 and 9. Four reps means a target of 103 accounts each. Grouping adjacent categories to get near that target gives 96 plus 9 for 105, 84 plus 15 for 99, 61 plus 33 for 94, and 48 plus 41 plus 25 for 114. The spread runs from 94 to 114, which is 20 accounts wide, about 19 per cent of the target.

That result is the answer to the request, and it took a paragraph. The dashboard the ticket asked for would have taken two hours and left the director doing this sum in a spreadsheet anyway.

Worth noticing what the brief also surfaced. The rebooking split turned out to matter more than the counts: the 114-account group contained 31 lapsed accounts against an average of 14 in the others, so the rep with the most accounts also had the worst book. That is the kind of thing a requirements conversation finds and a field list does not.

Five questions that get an honest answer

The interview does not need to be long. It needs to avoid the two questions everyone asks, which are "what do you want to see" and "what fields do you need", because both invite a shopping list.

What will you do differently after you look at this. What do you do today instead. How often will you open it, honestly. Who else is going to see the number once you have it. What would make you stop opening it.

The fourth question earns its place more often than people expect. A number that leaves the room in a board pack or an exhibitor email has different requirements from one that informs a private decision, because it has to survive being quoted by somebody who was not in the conversation. That usually means the label has to carry more, and the source has to be traceable.

The fifth question is the one that predicts abandonment. Answers like "if the data is more than a day old" or "if I have to filter it every time" are design constraints stated as complaints, and they are cheaper to hear now.

What if nobody can name a decision?

Sometimes the honest answer is that there is no decision, and the request is for reassurance, or for a number somebody has been asked for by their own manager, or for a page that exists mainly so its absence stops being noticed.

Those are legitimate needs and they are badly served by pretending otherwise. A monitoring page whose purpose is to confirm that nothing has gone wrong is a real artefact with real design implications: it should be almost empty most of the time, it should make exceptions loud, and it should not be judged by how often it is opened. Writing "the reader will confirm that nothing needs attention" as the decision sentence is a valid brief. Writing nothing, and building fourteen tiles instead, is how a page ends up with no defensible reason for any of them, which is the failure a show director's front page shows most clearly.

The other honest outcome is that the request should be a one-off extract. Not everything wants to be a dashboard. A question asked once a year is better answered by a query and an email than by a page that will be stale for eleven months and wrong by the twelfth.

Where this stops

Requirements gathering assumes the reader knows what they would do with a number they have never had. Often they do not, and no amount of interviewing extracts it.

The case where this bites hardest is a genuinely new measurement. Ask a show director what they will do differently once they can see dwell time by hall and you will get a plausible sentence that turns out to describe nothing they actually do, because they have never had the number and cannot yet imagine the decision. The brief looks complete and the page gets abandoned in six weeks.

The treatment is to build the smallest version that produces the number once, show it to them, and hold the requirements conversation afterwards with the real thing on the table. That inverts the order this post recommends, deliberately, for the narrow case where the reader has no experience to draw on. It is slower for one page and much faster than the alternative, which is a fully specified report built on an imagined decision.

The other limit is that a brief cannot settle how much fits. A decision sentence will happily justify eleven measures, and eleven measures will not fit on a page anybody reads, so the brief has to be reconciled against a tile budget before layout starts. That reconciliation is where most of the argument happens, and it is easier to have with a written decision sentence than without one.

Take the oldest unbuilt request in your queue this week and write its decision sentence. Go back to whoever raised it with the sentence rather than a question, and ask them to correct it. Most of the time they will, in one message, and the correction will tell you more than the original ticket did. Doing that consistently is what turns a reporting queue into an event business intelligence practice rather than a build service.