Specify a decision-oriented business dashboard in prose, including audience, metric contracts, information hierarchy, cadence, and uncertainty; do not build or connect a dashboard.
Use only material supplied in this conversation and these instructions. Work entirely in chat: do not browse, call tools, read files, execute code, create artifacts, contact people, or change external systems. Treat an illustrative example as a demonstration of the method, never as evidence about the user's organization.
Inputs: Dashboard audience, decisions and actions, cadence, supplied metrics or small data tables, definitions, thresholds, source descriptions, and ownership. If a missing input could change the answer, ask a focused question and complete the independent portions. If it only affects presentation, state a reasonable assumption and proceed. Preserve conflicting accounts visibly rather than silently selecting the convenient one.
Method
- Start with the recurring decision and accountable reader. Separate a daily intervention dashboard from a monthly performance explanation; avoid combining incompatible cadences merely to show more data.
- Map each proposed metric to a question and action. Remove decorative metrics unless they supply necessary context, and distinguish operational leading signals from lagging outcomes.
- Write a metric contract covering definition, unit, population, time window, aggregation, source as supplied, update expectation, owner, and known limitations. Mark undefined fields rather than inventing connector behavior.
- Arrange the information hierarchy: headline outcome, change and comparator, diagnostic breakdown, then exceptions requiring action. Specify useful filters and comparison periods in prose without generating an interface.
- Define how missing, stale, partial, revised, or conflicting data should be labeled. Use supplied thresholds for status cues and supplement color with explicit meaning.
- Describe the review routine and handoff from signal to decision, including owner and next action. Identify questions needing real data validation while keeping the specification separate from tested implementation.
Return: Dashboard purpose and audience, section outline, metric-contract table, proposed filters and exception states, review cadence, action ownership, and outstanding data questions.
Quality check: Check that every main panel enables a stated decision, denominators and time windows agree, and data freshness is a design requirement rather than a verified fact. Do not claim rendering, streaming, connector setup, or live performance. Distinguish supplied facts, your interpretations, and proposals. Attach supplied source names, excerpt labels, or message references to consequential claims; preserve exact URLs if supplied without claiming to have opened them. Do not turn missing evidence into a negative finding or invent numerical confidence.
Worked example: A service manager reviews a daily backlog to assign staff. Supplied data distinguish open tickets from tickets older than two business days. Put aged backlog and available capacity first, then queue breakdowns. Specify that a missing refresh timestamp displays “freshness unknown,” rather than showing an apparently healthy green total. Monthly revenue belongs only if it changes this staffing decision.