Run a dashboard requirements interview
In this article (7 sections)
Run a dashboard requirements interview around the decisions the dashboard must support. Clarify who uses it, what action follows a result, which metrics and populations matter, and how the team will know the dashboard is correct.
Chart preferences can be discussed after those questions. Starting with colors and visual types risks building an attractive display whose measures mean different things to different users.
Open with the operating situation
Hypothetical request: “We need a weekly sales dashboard.” Ask what happens in the weekly review, which decisions are currently difficult and what information users compare.
Suppose the clarified need is to review paid-event amount by region, identify Unknown-region records and confirm that the report is ready before a management meeting. That is more specific than a general sales overview.
The original weekly reporting case provides synthetic evidence for this scenario. It does not represent an actual stakeholder interview.
Clarify the measure with concrete examples
Ask whether “sales” means orders placed, paid events, invoices or another measure. Confirm the unit, period timezone, status filter and handling of late arrivals or duplicates.
In the worked case, eligibility uses event occurrence time from January 5 inclusive to January 12 exclusive in UTC. One identical event replay is removed; an eligible event arriving after the period end remains included under the supplied readiness rule.
Use a boundary record to test agreement. Ask what should happen to an event exactly at the exclusive period end. A specific example can reveal ambiguity that a general definition leaves hidden.
Capture requirements as testable statements
| Interview finding | Acceptance statement for the synthetic case |
|---|---|
| Weekly paid amount is the headline | Three selected events total 3,500 paise |
| Region breakdown must reconcile | North 1,000, South 2,000 and Unknown 500 sum to the headline |
| Unknown region must remain visible | The 500-paise contribution is not silently excluded |
| Readiness matters | Source checks must pass before the report is prepared |
| Review precedes use | Output remains pending review and not sent |
Acceptance statements connect the conversation to verification. “Easy to use” is a valid aspiration, but it needs an observable task or review method before it can guide implementation reliably.
Ask about use, access and refresh
Identify the intended users, the level of detail they need and whether different users may see different records. Confirm refresh timing, source availability and what should happen when data is late or incomplete.
Do not assume a real dashboard can expose row-level details merely because they are useful for debugging. Access requirements belong in the design and the actual authorization system.
For this public teaching example, all records are fictional and no live access-control configuration is implemented. A real project must resolve those arrangements before deployment.
Separate essential scope from later ideas
List the smallest useful view that supports the decision, then record optional enhancements separately. A regional comparison may be essential; an AI narrative or forecast may be optional and require additional evidence.
When a new feature is suggested, ask which decision it improves and what source or validation it needs. This keeps the scope connected to use rather than a growing collection of visuals.
Confirm what the dashboard should not imply. The paid-event amount in this case is not profit or recognized revenue, and one week does not establish a trend.
Close with a written readback
Summarize the decision, metric contract, source dependencies, essential views, acceptance checks and unresolved questions. Ask the stakeholder to correct the understanding through the project's normal review process.
Keep unresolved definitions visible. An implementation can begin on independent work, but a disputed metric should not be silently decided by whichever formula is easiest to write.
Exercise: role-play the interview with someone asking for a “customer performance dashboard.” Produce three clarification questions and one acceptance test that would prevent a misleading result.
NeuraPath's Data Analytics with Generative AI course connects stakeholder questions with metric design and BI implementation. A good requirements interview gives the dashboard a purpose and a result that can be checked.
Continue learning
This article is part of the Metrics, visualization and decision communication sequence. Use the neighbouring tasks when you need the prerequisite or the next application.
- Review the prerequisite or neighbouring task in Create an analysis handover with assumptions and open questions.
- Continue with Translate a vague request into an answerable analytical question.
Pankit Kumar has 10 years in Data Science & AI, building and shipping production systems in regulated pharma and clinical environments. He is a freelance trainer at Boston Institute of Analytics, AnalytixLabs and Scaler, and has taught this material to thousands of working professionals.
This article is part of our Data Analytics with Generative AI programme — 3–4 months. The full analyst stack — Excel, SQL, Power BI and Python pipelines — then a generative-AI layer you can prove is right.
Explore Data Analytics with Generative AI