Design dashboards around decisions, useful hierarchy, real states, and intentional information density.
A dashboard is not a storage room for every metric. Its job is to help a person understand what needs attention and move into the next useful action with as little interpretation as possible.
Start by writing the decisions the user comes to the dashboard to make. A sales manager may need to see unassigned leads and overdue follow-ups. An operations user may need failed jobs and blocked tasks. Those are more useful starting points than choosing chart types.
A dashboard is incomplete if only the ideal populated state has been designed. An empty state should explain what the user can do next. A loading state should preserve layout where possible. An error should identify the affected area and provide a safe retry path without erasing unrelated working content.
Desktop business software can support more information density than a marketing page, but density should come from alignment and hierarchy rather than tiny text and reduced hit targets. On mobile, prioritize actions and summaries; do not simply shrink a desktop grid until it fits.
Primary documentation and references used to support this guide.