Designing for the question, not the chart
A reporting experience is useful when it helps someone recognise what matters and decide what to do next. That starts with the question, long before anyone chooses a chart.
Where should a report or dashboard start?
A report should start with the decision it is meant to support, not with the data that happens to be available or the chart that looks most impressive. Write down who needs to answer which question, how often and what they would do differently depending on the answer; the design follows from that.
In practice, reporting projects often begin with an inventory instead: these are the sources and metrics, how should we display them? The result is a screen where everything is visible and very little is clear.
What does “start with the decision” look like in practice?
In Define & Explore, before we sketch anything, we try to describe the reporting experience as a set of moments rather than a set of metrics. For each person who uses the report, we want to understand:
- When they look. Every morning before a meeting, at the end of the month, or only when something seems wrong.
- What they are trying to decide. Whether to intervene, where to send attention, what to report upwards, whether a plan is still on track.
- What would make them act. A threshold, a change in direction, a gap between plan and reality, an outlier.
- What they compare against. Last week, the same period last year, a target, another region, a peer group.
- What they do next. Call someone, open a record, write a summary, adjust a forecast.
Those answers are rarely in the brief. They come from talking to the people who use the information and, where possible, watching them use what exists today. A manager may say they need “an overview of sales” when the real question is narrower: which three accounts need a conversation this week, and why.
Once the questions are written down, most screens can show less. Metrics that do not serve a decision either move to a detail view or leave entirely. That is not a loss of information; it is a decision about where information belongs.
Why is a chart not the same as an insight?
A chart shows that something happened. An insight explains why it matters to the person looking at it. The gap between the two is where most reporting falls short.
A line going down is a fact. “Weekly sign-ups are lower than the same weeks last year, and the drop is concentrated in one channel” is closer to something a person can act on. Getting there usually depends on three design choices:
- The right comparison. A number on its own is rarely meaningful. The comparison you place next to it, whether target, trend or peer, does most of the interpretive work.
- Context at the point of reading. Annotations, known events and definitions belong next to the figure, not in a separate glossary.
- A visible path to the next step. If the answer is “look closer”, the drill-down should be one step away and should keep the question in view.
Often this calls for a simpler chart, not a more elaborate one.
A good reporting experience is not the screen with the most charts. It is the one that answers the question people actually came with.
Efabrika
How honest should a report be about what it does not know?
Very honest. An insight is not automatically a proven cause, and a suggestion is not automatically a verified recommendation. A report that blurs those lines teaches people to trust it too much, and then, after the first wrong call, not at all.
We find it helps to design these distinctions into the interface rather than leaving them to footnotes:
- Separate observation from interpretation. “Returns rose in the northern region” is an observation. “Returns rose because of the packaging change” is a hypothesis until someone has checked.
- Show data freshness and gaps. When data was last updated, and which sources are missing or delayed, should be visible without searching.
- Label estimates and forecasts as such. Use clear visual treatment for anything predicted, modelled or partial.
- Make the uncertainty proportionate. Not every number needs a confidence interval, but people deciding on a forecast should know how much it has moved before.
The way a figure is presented tells people how much weight to give it.
How does a reporting experience keep improving?
Questions change. A new product launches, a team reorganises, a target is reset, and the report that fitted last quarter starts to drift. That is why we treat reporting as part of a loop rather than a one-off deliverable.
In Design & Develop we shape hierarchy, comparisons and views around the questions we have documented, then build and validate them with the people who will rely on them. In Optimize we watch how the reporting is used: which views people return to, where they export data to work elsewhere, which questions still go to a colleague instead of the screen. Each of those is evidence that the report and the question have moved apart.
That evidence leads back to Define & Explore. Sometimes the change is small, such as a new comparison or a clearer label. Sometimes a view is retired because the decision it supported no longer exists.
A short checklist before you choose a chart
- Can you name the person, the moment and the decision this view supports?
- Is there a comparison next to every number that matters?
- Would someone new to the team understand what to do after reading it?
- Is it clear what is observed, what is interpreted and what is estimated?
- Do you know how you will find out if the question changes?
If you are working through these questions for your own reporting, our page on Insights, Reporting & Decision Support describes how we approach it, and we would be glad to hear what your team is trying to understand.