Requirements are the practical list of what a dashboard must help someone do: the information they need, the decisions behind it, and the boundaries that keep the work focused. Gather them before designing, rather than assuming an initial request tells the whole story. section 8.0 section 8.2.1
Interview stakeholders and users to turn a broad request into specifics. Ask which metrics matter, which filters or breakdowns are useful, whether data must be downloaded or shared in slides, how much time must be visible, who will use the result, and where they will use it. A requirement can also remove work: if a dashboard is used only on a computer, mobile support may not be needed. section 8.2.1
A useful requirement list can pin down:
- The user’s job and the decisions the dashboard should support. section 8.2.1
- Priority metrics, such as fully booked nights, more-than-90%-booked nights, stayovers, and daily checkouts. section 8.2.1
- Interaction and delivery needs, including a movable 30-day view, filters, spreadsheet downloads, and presentation screenshots. section 8.2.1
- Scope constraints, such as the intended audience and desktop-only use. section 8.2.1
A housekeeping dashboard brief
For hotel staffing, the dashboard serves one scheduler across three properties. It needs occupancy metrics, at least 30 days at a time with a movable window, and desktop access; a mobile version is outside the stated need. This is much more actionable than “show hotel occupancy.” section 8.2.1
Keep the list simple enough to guide trade-offs. Skipping interviews or declaring requirements on behalf of users risks a dashboard that wanders in too many directions—and a bumpier project than anyone ordered. section 8.2.1
