Dashboards and reporting
Dashboard Design for SaaS and Internal Tools
Dashboards that answer a question instead of displaying every metric the database can produce.
What I do
Five kinds of reporting work
Whether the users are your customers or your own operations team, the job is the same: decide what the screen is for before deciding what it looks like.
Dashboard redesigns
An existing screen nobody opens, taken back to the decisions it should support.
New reporting surfaces
Built from the questions people actually ask, not from the fields that happen to be available.
Data tables and list views
Density, filters, saved views and bulk actions, which is where the daily time is genuinely won.
Role-specific views
Operations and management want different screens, and that is cheaper to build than it sounds.
Component systems
The pieces that repeat across every reporting screen you will build after this one.
The method
Six steps, in this order.
The first does most of the work.
Every widget has to earn its place
by connecting to a decision.
Six steps / three to five weeks
Step / 01
Find the decision. Per role, what gets decided with this screen and how often. Wants produce widget lists. Decisions produce hierarchy.
Step / 02
Cut what serves nothing. Every widget earns its place by connecting to a decision. Nothing is deleted, it moves to reports.
Step / 03
Make the healthy state boring. On a normal day the screen should be calm. Exceptions get the emphasis, and that is what makes it worth opening.
Step / 04
Fix the table. In B2B the table is the product. Alignment, tabular figures, density, saved views, bulk actions.
Step / 05
Design the states nobody asks for. Empty, error, partial, and what happens at forty rows rather than three.
Step / 06
Agree the measure. Before launch, so the result can be defended afterwards rather than argued about.
The full walkthrough with a worked example is in a SaaS dashboard redesign, step by step.
What good looks like
Four numbers worth tracking
Capture these before anything changes. A redesign without a baseline cannot be defended later, and on internal tools someone always asks.
Time to first action
How long after opening the screen before someone does something. It should fall.
Exports to spreadsheet
Every export is the product failing to answer something. Uncomfortable, and the most useful of the four.
Sessions that use it
As opposed to routing straight past it to the underlying table.
The outcome it protects
Orders missing their date, tickets breaching, stock running out. The reason the screen exists.
The core idea
Make the healthy state boring
Most dashboards treat every number identically: same card, same weight, same colour. When everything shouts, nothing carries signal, and people learn to skip the screen entirely.
The fix is to invert it. On a normal day the screen stays calm and mostly grey. When something needs attention it becomes the loudest thing on the page and names itself. Exception gets the emphasis, and the healthy state gets deliberate silence.
What it costs
Ranges
Single dashboard surface$3,000 to $8,000
Multi-role reporting across a product$10,000 to $30,000
Design plus front-end buildAdd 40 to 60%
Typical timeline, one surface3 to 5 weeks
The variable is rarely design time. It is how quickly I can get in front of the people who use the screen.
Common questions
Before you get in touch
What is dashboard UX design?
Deciding what a screen is for before deciding what it shows. In practice that means naming the decision each role makes with the screen and how often, giving that decision the hierarchy, and moving everything else to a reports page. The principles I keep returning to are in B2B dashboard design principles.
How much does a dashboard redesign cost?
A single dashboard surface is $3,000 to $8,000 of design work in 2026. Multi-role reporting across a product runs $10,000 to $30,000. Adding the front-end build is roughly 40 to 60 percent on top, and removes the handoff entirely. Rate detail is in what a UI/UX designer costs.
How long does a dashboard redesign take?
Three to five weeks for one surface. The variable is not design time, it is how quickly I can get in front of the people who use the screen. Two hours of watching someone work is the cheapest input in the project and reliably the last thing anyone schedules.
Does our dashboard need a redesign or just tuning?
If people open it and act, it needs tuning. If they route around it to the underlying table, the screen has the wrong job and needs re-deciding. If the data itself is wrong or late, no amount of design fixes it.
Our stakeholders want every metric on there.
Ask each requester what they would do differently if the number moved. Anything with no answer goes to a reports page. That reframes removal as relocation, and almost nobody objects to relocation.
Do you work with our charting library?
Yes. The library is rarely the problem. Hierarchy, defaults and what earns space are the problem, and those are the same decisions whatever renders the chart.
Can you serve both operations staff and executives?
They need different default views rather than different products. Same components, different arrangement, which is a much smaller job than building twice.
How do we know the redesign worked?
Agree the measure before launch, because afterwards everyone reaches for whatever number flatters the project. Time to first action, exports to spreadsheet, the share of sessions that touch the dashboard at all, and the business outcome the screen exists to protect. Capture all four for a few weeks before changing anything, or the result cannot be defended later. A worked example is in a SaaS dashboard redesign, step by step.
The thinking behind it
Judgement, in writing
Send me a screenshot of the dashboard and tell me who uses it.
I can usually tell within a call whether the problem is hierarchy, data, or a job nobody decided.