Skip to content

03 · A dashboard that reads like a product ​

At a glance ​

OutputA charted control surface
Time30 to 60 minutes
TypeDashboard
The hard partNot the charts — deciding what question the dashboard answers

The situation ​

You need a data surface: a metrics board for the team, a results panel for a client, or a console inside an internal tool.

Answer one question first ​

What does the person opening this want to know?

Not "what data do they want to see" — what do they want to know. The difference decides whether the dashboard is useful or merely handsome:

What dataWhat they want to know
DAU, retention, conversionDid something break yesterday?
Spend by channelIs there budget left this month?
Ticket volume, response timeDo we need more people right now?

The right column tells you what to enlarge, what to alarm on, and what can collapse. The left column only gives you a pile of cards.

The prompt ​

text
Build a metrics dashboard.

Who opens it: [and how often]
What they want to know when they do: [one sentence, one question]
If the answer is "something's wrong", what they do next: [concrete action]

Data:
[paste CSV, or describe the structure and what each field means]

Layout:
1. Top row answers the core question. No more than three numbers.
2. Middle holds the charts supporting that judgement. Maximum four.
3. Below, a detail table, collapsed by default.

Constraints:
- Every number needs a comparison basis (period-on-period,
  year-on-year, or target). A lone number says nothing.
- Charts use the design system's palette, not ECharts defaults.
- Y axes start at zero.
- Cover all states: loading, no data, anomalous data, a single day
  of data.
- Label any sample data.
- In dark mode, charts have dark backgrounds too.

Why it's written this way ​

"What they do next" is the most useful line. With it, the dashboard knows what should turn red and which number should be largest. Without it, every metric is equally important, which means none is.

"Every number needs a comparison basis" is rule one of dashboard design. "1,240 orders yesterday" says nothing. "1,240 orders yesterday, down 18%" is information.

"No more than three numbers in the top row" forces you to prioritise. A row of six KPI cards is the classic failure — the eye has nowhere to land.

Acceptance ​

  • [ ] The core question is answerable within three seconds of opening
  • [ ] Every number has a comparison basis
  • [ ] Chart colours match the page
  • [ ] Y axes start at zero (or there's a stated reason)
  • [ ] Loading, empty, and error states all exist
  • [ ] Charts aren't white boxes in dark mode
  • [ ] Sample data is labelled
  • [ ] Charts scroll horizontally on narrow screens; the page doesn't

Variants ​

Wire it to real data

text
Change the chart data source to this endpoint:
GET /api/metrics?from=&to=

Response shape:
[paste a real response]

Handle: loading, request failure, an empty array, missing fields.
On failure, show the last successful data and label it as possibly
stale.

Add a range switcher

text
Add a range switcher: today / 7 days / 30 days / custom.

All charts move together. Show a loading state during the switch
without letting the layout jump. Remember the last chosen range for
the next visit.

A client-facing version

text
Build an external version of this dashboard:
- Remove internal metrics (cost, headcount, tickets)
- Keep outcome metrics
- Add one sentence under each chart explaining what the number means
- Add the client logo and the reporting period at the top
- Support PDF export

Questions that come up ​

Too many charts to read.

Cut. Past six charts nobody reads a dashboard. Ask which are necessary to answer the core question; collapse or demote the rest.

Chart colours clash with the page.

Be explicit: "charts use the design system palette; the primary colour marks the most important series, everything else uses the neutral ramp."

It stalls on large data.

State the scale in the prompt: "a request may return 50,000 rows; aggregate or virtualise." Unstated, it builds for small data.

Charts are blurry in the exported PDF.

Require vector rendering: "render charts as SVG for PDF export, not bitmaps."

An unofficial community guide · compiled from open-design.ai public material and hands-on notes · the official docs win where they differ