Dashboards and reporting

Dashboard Design for SaaS and Internal Tools

Dashboards built around the decision which each person makes with them, so the screen is opened and acted on every day.

See case studies

Five-star reviews from clients on Upwork

The Roadcase tours dashboard on a Studio Display on a perforated steel platform

What I do

Six kinds of reporting work

Whether the users are your customers or your own operations team, the job is the same, so I decide what the screen is for before I decide what it looks like.

Dashboard redesigns

An existing screen which nobody opens, taken back to the decisions which it should support.

New reporting surfaces

Screens built from the questions which people ask every week, using whichever fields answer them.

Data tables and list views

Density, filters, saved views and bulk actions, which I think is where most of the daily time is saved.

Role-specific views

Operations and management want different screens, and that's cheaper to build than it sounds.

Component systems

The pieces which repeat across every reporting screen which you will build after this one.

Customer-facing analytics

Reporting which your own customers see inside the product, where every chart is judged like the rest of the interface.

The method

I follow six steps in this order,
and 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, which means what each role decides with this screen and how often, because wants produce widget lists and decisions produce a hierarchy.

Step / 02

Cut what serves no decision, so every widget earns its place by connecting to one, and everything else moves to a reports page, where it stays available.

Step / 03

Make the healthy state boring, so on a normal day the screen stays calm and the exceptions carry the emphasis, which is what makes it worth opening.

Step / 04

Fix the table, because in B2B I think the table is the product, so the alignment, tabular figures, density, saved views and bulk actions all matter.

Step / 05

Design the states which nobody asks for, so empty, error and partial, and what happens at forty rows as well as three.

Step / 06

Agree the measure before launch, so the result can be defended afterwards.

The full walkthrough with a worked example is in a SaaS dashboard redesign, step by step.

What good looks like

Six numbers worth tracking

I would capture these before anything changes, because a redesign without a baseline can't be defended later, and on internal tools someone always asks.

Time to first action

How long after opening the screen someone does something, which should fall.

Exports to spreadsheet

Every export is a question which the product failed to answer, so it's the most uncomfortable of the six and also the most useful.

Sessions that use it

The share of sessions which open the dashboard and use it, where the rest go straight past it to the table underneath.

The outcome it protects

Orders missing their date, tickets breaching and stock running out, which is the reason the screen exists.

Requests to the data team

Every request to pull the numbers is a question which the screen should have answered, so the count should fall.

Questions about the screen

Tickets and messages asking where a number is or what it means, and each one is a label problem or a layout problem.

The core idea

Make the healthy state boring

Most dashboards treat every number identically, with the same card, the same weight and the same colour, and when everything shouts, nothing carries a signal, so people learn to skip the screen entirely.

I think the fix is to turn that around, so on a normal day the screen stays calm and mostly grey, and when something needs attention it becomes the loudest thing on the page and names itself, which gives the exception the emphasis and the healthy state a deliberate quiet.

See case studies
The Fathom back office sales overview on a Studio Display mounted on an industrial rack

What it costs

I quote each project once I've read the brief

I quote a dashboard from the number of surfaces and roles which it serves, and a single dashboard surface mostly takes 3 to 5 weeks, depending most on how quickly I can meet the people who use the screen.

Common questions

Before you contact me

What is dashboard UX design?

It means deciding what a screen is for before deciding what it shows, so in practice I name the decision which each role makes with the screen and how often, give that decision the hierarchy and move everything else to a reports page. The principles which I keep returning to are in B2B dashboard design principles.

How long does a dashboard redesign take?

One surface takes three to five weeks, and what moves that is how quickly I can meet the people who use the screen, because I think two hours of watching someone work is the cheapest input in the project and reliably the last thing which anyone schedules.

Does our dashboard need a redesign or just tuning?

If people open it and act on it, it needs tuning, but if they route around it to the table underneath, the screen has the wrong job and needs deciding again, and if the data itself is wrong or late, the data has to be fixed before any design can help.

Our stakeholders want every metric on there.

I would ask each requester what they would do differently if the number moved, and anything without an answer goes to a reports page, which turns a removal into a move, and almost nobody objects to a move.

Do you work with our charting library?

Yes, and the library is rarely the problem, because the hierarchy, the defaults and what earns space on the screen are the same decisions whatever renders the chart.

Can you serve both operations staff and executives?

Yes, they need different default views of one product, so the components stay the same and only the arrangement changes, which is a much smaller job than building twice.

How do we know the redesign worked?

I would agree the measure before launch, because afterwards everyone reaches for whichever number flatters the project, so that's the time to first action, the exports to spreadsheet, the share of sessions which touch the dashboard at all and the business outcome which the screen exists to protect. Capture all four for a few weeks before changing anything, so the result can be defended later, and a worked example is in a SaaS dashboard redesign, step by step.

Case studies

Dashboards in recent work

Client reviews

Always built
on trust

  • Upwork

    Mike is an absolute star. A great communicator who takes initiative, and has the skills to complete the job well each and every time. He is a fantastic partner in all-things design and development, is a pleasure and easy to communicate with.

    Gwyn P. Founder, Sail Digital

  • Upwork

    Mike was one of the easiest consultants we have worked with. Good attitude, willing to take on feedback, good designs and willing to please. Will have no hesitation to hire!

    Fiona M. Director, CArio

  • Upwork

    Mike not only gave us an amazing new website but also gave us time back to focus on growing our SaaS company and the confidence to know that we can leverage their skills again in the future. I unreservedly recommend!

    Andrew Former director, shibumi

  • Upwork

    Mike helped us design and develop our new website in Webflow. He is very responsive to changes and iterations, and helped find faster ways to implement what we wanted.

    Julien R. Founder, Hire Donna

Your dashboard should be the first screen which your team opens each morning.

Tell me what the dashboard is for and who uses it, and I can usually tell within one call whether the problem is the hierarchy, the data or a decision which nobody made, and what fixing it would take.

See case studies
The Roadcase live budget view on an Apple Studio Display