1. What decision should become easier?
A dashboard is a means of supporting a decision, not an outcome by itself. If the brief begins with a list of charts, it is easy to produce an attractive surface that still leaves its audience wondering what to do next.
Start with a recurring decision in plain language. A leader may need to decide where an exception requires attention. A coordinator may need to decide which work item should move next. A reviewer may need to decide whether the available information is complete enough to approve. Each of those decisions requires a different interface, level of detail, and update cadence.
Name the primary person or role responsible for that decision. Other audiences may need visibility, but designing one screen to satisfy every level of the organization often removes the context each group needs. A clear primary audience gives the dashboard a useful centre of gravity.
- Which recurring decision is currently slow, unclear, or dependent on manual preparation?
- Who is accountable for making it?
- How frequently does the decision occur?
- What is the consequence of deciding late or with incomplete information?
- What action should become possible once the answer is visible?
2. What information is needed, and where does it live?
Once the decision is clear, work backwards to the minimum information required to support it. Separate information that changes the decision from information that is merely interesting. This protects the first version from becoming a catalogue of every field the organization can access.
For each required item, identify its source and condition. It may live in a business system, a database, a spreadsheet, a form, a shared document, or an informal exchange between people. Determine whether it can be accessed, how it is structured, how often it changes, and whether the same term means the same thing across departments.
Data availability should be verified before an interface is treated as feasible. An existing system may not expose the necessary information in a supported way. A source may be technically accessible but too incomplete or inconsistent for the intended decision. Those are discovery findings, not interface problems that a chart can conceal.
- Which source is authoritative for each required value?
- How current must the information be for the decision?
- Can the source be accessed through a supported export, API, database connection, or other approved method?
- Which definitions or calculations need agreement before they are displayed?
- What should the interface show when information is missing, delayed, or disputed?
3. Who owns the information and the definitions?
A dashboard can make a definition visible, but it cannot decide who has the authority to define it. Terms such as complete, overdue, available, at risk, or on track may have different meanings across teams. If those meanings remain unresolved, the interface can make disagreement look more precise without making it more useful.
Assign ownership at several levels. Someone must be accountable for each source, someone must approve shared definitions and calculations, and someone must decide who can view or change information. The organization also needs an owner for the product itself: the person who can prioritize corrections and future changes after launch.
Permissions belong in this conversation early. Executive visibility, operational editing, approval authority, and administrative access are not interchangeable. The design should expose the right detail to each role without relying on everyone to ignore information or controls they should not use.
- Who owns the source and addresses quality problems?
- Who approves definitions, thresholds, and calculations?
- Which roles can view, comment, edit, approve, or administer?
- Who decides when the dashboard itself should change?
- What history or audit evidence must remain available?
4. What should happen when something needs attention?
Visibility matters only if it connects to an appropriate response. If a dashboard identifies an overdue approval, an asset requiring attention, or a report with missing information, define what should happen next. Otherwise the dashboard may become another place people check before returning to email and spreadsheets to do the work.
The answer does not always require a complex workflow engine. It may be enough to identify an owner, expose the supporting record, and provide a clear route to the existing system where action occurs. In other cases, the value of the product may depend on assignment, acknowledgement, comments, approval, or escalation within the same experience.
Notification also needs restraint. Decide which events justify an alert, who receives it, through which channel, and what happens if nobody responds. More notifications do not create more accountability; a clear response path does.
- What condition requires action rather than observation?
- Who becomes responsible when that condition occurs?
- Can the action happen in the dashboard, or should the user move to a source system?
- What context must travel with an assignment, approval, or escalation?
- How is the item resolved, and what record of that resolution is required?
5. How will you know the dashboard remains useful?
A dashboard can match its original brief and still lose relevance as definitions, source systems, responsibilities, and operating priorities change. Plan for review rather than assuming the first release will remain correct indefinitely.
Usefulness should be evaluated against the decision named at the beginning. Ask whether the intended people can find the information, understand its condition, and take the required next step. Feedback from actual use is more informative than counting available charts or fields.
Agree who will receive feedback, how corrections are prioritized, and how source or definition changes are communicated. Also define the support boundary: who monitors the system, who manages access, who responds when data is delayed, and who is responsible for technical maintenance.
- Is the intended decision clearer and appropriately timed?
- Do users understand the source, freshness, and meaning of the information?
- Are exceptions reaching a responsible owner with enough context to act?
- Which unused or confusing elements should be revised or removed?
- Who owns review, support, access, and future enhancement?
A useful first brief can fit on one page
You do not need a technical specification before starting a dashboard conversation. A one-page description of the decision, audience, information, ownership, response, and review process is a stronger starting point than a detailed list of screens built on untested assumptions.
Bring the messy version: the recurring report, the spreadsheet, the inbox handoff, the source-system limitation, and the question leadership keeps asking. Discovery can then determine whether the responsible answer is a custom dashboard, an existing product, a smaller automation, a process change, or something outside the proposed scope.