Dashboard Design
Make dense data readable enough to act on.
Dashboard UX for hierarchy, filters, role views and visualisation: scan first, then act. The work is judged by decision quality, not by how decorative the charts look.
Interfaces for decisions
A dashboard is a workplace for incomplete data.
Most dashboards fail because every metric asked to be on the first screen. We start from the decisions each role must make, then design hierarchy, density, filters and actions so charts serve those decisions. Visual polish is last, and it is never the point.
Typical constraints
The view is busy and still does not answer the question.
- 01Every stakeholder got a widget, so nothing is ranked.
- 02Filters reset the page or hide the thing you were looking at.
- 03Charts look finished and still cannot be compared across time or segments.
- 04The same dashboard is shown to operators, managers and executives.
- 05Actions live in another product, so insight never becomes work.
- 06Loading, empty and stale-data states were never designed, so people stop trusting the numbers.
What you receive
Ranked information, not a collage of charts.
The artefacts are decision-led layouts, filter models and visualisation rules. Aesthetic exploration is limited to what improves scan and trust.
01
Decision inventory
The questions each role must answer, and the data that is actually available to answer them.
02
Hierarchy and density model
What is primary, secondary and hidden behind a filter, including how much the first screen may hold.
03
Filter and time controls
Scope, persistence and comparison designed so people can change the question without losing place.
04
Role-specific views
Operator, manager and executive layouts where the jobs genuinely differ.
05
Visualisation rules
Chart types chosen for the comparison, plus labelling, empty and stale states.
06
Action placement
The next operational step sitting next to the insight that triggered it.
How a dashboard is designed
Decisions, then density, then charts.
We do not start by choosing a chart library. We start by naming the decision and the data quality you actually have.
01
Name the decisions the view supports
If a widget has no decision attached, it does not earn a place on the first screen.
02
Rank information by scan order
What must be readable in seconds, what can wait, and what belongs in a detail view.
03
Design filters and time controls
How people change scope without destroying orientation or comparison.
04
Place actions next to insight
Export, assign, alert or open-record, specified as part of the view.
05
Split views by role
When one layout cannot serve two jobs, we stop forcing a single homepage.
06
Specify empty, loading and stale density
Trust is designed. A beautiful chart with last week's numbers is a liability.
Useful when
This is the brief when the screen is supposed to run the day.
- An operations team lives in a view that was designed as a sales demo.
- Analytics exists, but nobody can explain which number to trust.
- Executives want a summary and operators need a worklist, on the same URL.
- A product is adding charts because competitors have charts.
- Filters were implemented as an afterthought and now punish power users.
- A UX audit already showed density problems and the work is to redesign the view.
What we judge
People should leave the view knowing what to do.
Faster scanning
The important comparison is visible without decoding a wall of equal-weight widgets.
Filters that keep orientation
Changing time or segment does not feel like starting the product over.
Role-fit views
Operators and reviewers are not forced through the same first screen.
Actions attached to insight
The dashboard is allowed to start work, not only display it.
Related work
Selected dashboard work will appear here.
Operational interface studies are added when we can show the before-and-after structure and the client permits it. No invented metrics live on this page.
Published case studies will appear here when they are cleared.
Related services
Work that usually sits beside this.
Questions
Buying questions, answered directly.
It may. That is not the success criterion. We judge whether people can find the decision, trust the number and take the next action. A restyle without hierarchy is still a failed dashboard.
Next move
If the dashboard is loud, reduce it to decisions.
Show us the current view, the roles and the question it is supposed to answer. We will say whether a hierarchy pass, a role split or a wider application redesign is needed.