A dashboard has a job
A dashboard exists to answer a specific question quickly, such as is this service healthy right now. Crowding it with every available metric defeats that purpose.
Principles
- Start with the question. Design each dashboard around one audience and one job, like service health or a single user journey.
- Top down layout. Put the most important, user facing signals at the top, often the SLI driven golden signals of latency, traffic, errors, and saturation. Detailed and diagnostic charts go lower.
- Show context. Mark normal ranges, thresholds, and recent deploys so a viewer can judge whether a value is good.
- Few panels. A glance should reveal health. Link out to deeper dashboards rather than packing everything in.
- Consistent time and units. Align all panels to the same time range and label units clearly.
- Color with meaning. Reserve red for problems, not decoration.
Common mistakes
- A wall of charts where nothing stands out.
- Raw counts with no rate or baseline for comparison.
- Mixed time ranges that mislead when read together.
Key idea
Design each dashboard around one question, lead with golden signals at the top, add context, and keep panels few so health is obvious at a glance.