What we do
SaaS Dashboard Design
Dashboards and admin interfaces designed for people who use them all day, with the states, density and edge cases real data brings.
Start a conversationA dashboard is judged in ten seconds by someone who opens it forty times a day. That is a different problem to a marketing site, and it is mostly about restraint: what the screen answers first, how dense it can be before it stops being readable, and what it does when data is missing, wrong, or far larger than the mockup assumed.
How we think about it
Most dashboard design fails the same way. It is drawn with invented data that behaves politely: three-digit numbers, short labels, tidy time series, every widget populated. Real products have accounts with nine hundred rows, customers with forty character names, metrics that are null for the first week, and a Monday morning where everything loads at once. The interface has to hold up under all of it, which makes the work mostly about states and hierarchy rather than layout.
The first decision on any dashboard is what question the screen answers. A screen that answers one question well beats one displaying twelve metrics with equal weight, because equal weight is the same as no weight. We lead with the number and its direction of travel, keep charts for the people who want to interrogate it, and resist turning every figure into a graph. A table is frequently the correct visualisation, and a sentence is sometimes better than both.
Then the unglamorous half: every empty, loading, error and overflow state, designed rather than invented at build time by whoever reached it first. That work is invisible in a portfolio shot and it is the difference between a product that feels solid and one that feels like a demo.
Who this fits
- A SaaS product whose interface grew feature by feature and now feels inconsistent
- An operations tool where staff work around the software rather than in it
- A product with real data that looks nothing like the design it was built from
- A team that needs a design system so new screens stop drifting
What you get
- Information hierarchy: what each screen answers, and in what order
- Full screen designs with every state: empty, loading, error, partial, overflow
- Data visualisation decisions with the chart matched to the question
- A component library and tokens so future screens stay consistent
- Responsive behaviour for the widths your users actually work at
- Developer-ready handoff, or the built front end if you want one team
How it runs
- 01
Understand
Watch people use the current tool and find where they slow down or work around it.
- 02
Structure
Decide what each screen answers and what genuinely belongs on it.
- 03
Design
Build the system and the screens using your real data rather than samples.
- 04
Prove
Test the dense and awkward cases before sign off, not after.
- 05
Hand over
Documented components and states, or we build the front end ourselves.
The proof
From the notebook
Asked often
Can you work with our real data instead of placeholders?
We prefer to, and we will ask early. Anonymised exports or a read-only account are ideal. Designs built on sample data hide the problems that matter: long names, empty periods, huge row counts, and numbers that need aligning. If the data cannot leave your systems, we will work from realistic ranges you supply instead.
Do you build it or only design it?
Either. We design and hand over to your engineers with documented components and states, or we design and build the front end ourselves. Teams with strong in-house engineering usually take the first, teams without a front end specialist usually take the second.
Our product is old and inconsistent. Where would you start?
With the screens people use most, not the ones that look worst. We audit which screens carry the daily work, standardise the shared parts first, typography, spacing, tables, buttons and states, then work outward. That makes the product feel coherent long before every screen has been touched.
Will a redesign disrupt our existing users?
It can, and it is worth planning for. Experienced users work from muscle memory, so moving things costs them speed even when the new layout is better. We usually change the surface freely and the structure carefully, roll out in stages, and keep the old interface available for a defined period on significant changes.