1. Write the decision in one sentence
Start with a decision rather than a list of charts. For example: “The operations manager needs to identify which locations require a stock review each Monday.” Record the person making the decision, its frequency and the next action. A report that supports several unrelated decisions may need more than one view.
Ask what users do today, which information they trust and where the current process becomes difficult. Existing reports reveal useful definitions and exceptions, even when the goal is to replace them.
2. Identify the audience and working context
List the intended users and their responsibilities. Find out whether they will use a desktop, a shared meeting screen or a smaller device, and whether they need an overview or account-level details. Note accessibility and language requirements. These answers shape the layout and navigation before visual styling begins.
- Named business owner and primary users
- Expected review cadence and working device
- Overview, investigation and export needs
- Required permissions and restricted fields
3. Define a small set of measures
For each measure, record its meaning, unit, reporting period, source, calculation and exclusions. Specify the denominator for rates and the reference point for comparisons. Terms such as “active customer,” “revenue” and “completed” often hide different departmental rules.
Have the business owner approve the definition. If teams require different versions of a measure, label them explicitly instead of presenting them as interchangeable. Keep a metric dictionary alongside the requirements.
4. Review the source data and its grain
Determine what one row represents in every source: an order line, a daily account balance, a claim event or another unit. Mixing grains without checking the relationship can change totals. Identify join keys, duplicate records, missing dates and the available history.
Record the update method, expected delay and the person responsible for the source. Define how the dashboard will indicate incomplete or stale information. A chart cannot resolve a missing source or an undefined business rule.
5. Sketch the investigation path
Outline the first question, the useful comparison and the detail needed to investigate an exception. Keep filters focused on actual user tasks. Agree which interactions should affect which views and what context should remain visible.
A simple sketch is enough to review reading order and terminology. Use clearly identified wireframes during discovery; do not present invented values as evidence of business performance. Tableau’s dashboard guidance also emphasizes purpose, audience and keeping the number of views manageable.
6. Agree acceptance and handover
Choose reference totals and representative scenarios before development. Include at least one exception case, an empty result and the permissions of a typical user. Decide who signs off the calculations and who owns the report after publication.
Acceptance should cover interpretation as well as arithmetic: can a user find the required answer and explain the period and population behind it? Handover should name the refresh owner, support route and change-review process.
- Reference totals and reconciliation method
- User scenarios and expected behavior
- Refresh, access and performance expectations
- Named approver and ongoing report owner
Example of an acceptance criterion
For a monthly sales report, a useful criterion is: “With the agreed month and store filters applied, net sales reconcile to the approved source report; a user can identify the categories behind the variance and see how returns are treated.” This describes observable behavior and a reference, giving the business owner a concrete basis for approval.
Turn the checklist into a brief
Keep the output concise: the decision, audience, metric dictionary, source inventory, first-view sketch and acceptance checklist. Record unresolved questions with an owner instead of silently assuming an answer. This brief gives your team a shared basis for estimation and helps later requests be evaluated against the original purpose.