A dashboard can contain accurate numbers and still leave its reader unsure what to do. The first design question is who opens it and what decision they need to make. A founder reviewing the month and an operator handling today’s exceptions may use the same data but need very different views.
Write the questions the screen must answer
Imagine a small equipment-rental company. Its morning dashboard might need to answer: Which items must leave today? Which returns are overdue? Which bookings need attention? A colourful revenue graph does not answer those operational questions, even if it looks impressive.
Write three questions for the main role, then match each to information and an action. Put urgent exceptions near the top. If another role needs a different view, define it deliberately rather than adding every metric to one crowded screen.
Explain exactly what each number represents
Give a metric its unit, date range, and definition. “Bookings: 42” could mean new reservations, active rentals, or completed returns. Show which it is. Make the comparison period explicit and explain whether cancelled bookings are included.
Also distinguish a real zero from missing data. If a connection fails, showing zero rentals could send the operator in the wrong direction. Display a clear unavailable state, the last successful update when known, and a sensible way to retry.
ⓘRevenue = paid orders minus refunds, VAT included. Target set on the 1st.
Each question gets the one chart that answers it, with the number defined right beside it.
Connect the overview to the work
An overview should lead to the records behind it. An overdue-return count can open a filtered list with due dates and contact actions. Keep the chosen filter visible so people understand why certain items are shown.
Tables need careful decisions about sorting, row actions, selection, and empty states. Use clear labels for destructive actions and explain their consequences before applying them. A useful dashboard often depends more on a well-designed list than on the number of chart types available.
Design a phone view around priority
On a narrow screen, show the essential status and next action first. A wide table may need a focused summary with a detail view, or a clearly indicated horizontal scroll region. Do not silently hide a column that is required to interpret the row.
Test with realistic variation: long customer names, many overdue items, no bookings, and an old update timestamp. Ask someone to explain what they would do next. If they must open another tool to understand the main screen, revisit the information you prioritised.
Before you build
- Name the primary role and three decisions.
- Label units, periods, definitions, and data freshness.
- Link summaries to actionable records.
- Test empty, stale, busy, and narrow-screen views.