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.
Five-star reviews from clients on Upwork
Dashboards and reporting
Dashboards built around the decision which each person makes with them, so the screen is opened and acted on every day.
Five-star reviews from clients on Upwork
What I do
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.
An existing screen which nobody opens, taken back to the decisions which it should support.
Screens built from the questions which people ask every week, using whichever fields answer them.
Density, filters, saved views and bulk actions, which I think is where most of the daily time is saved.
Operations and management want different screens, and that's cheaper to build than it sounds.
The pieces which repeat across every reporting screen which you will build after this one.
Reporting which your own customers see inside the product, where every chart is judged like the rest of the interface.
The method
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
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.
How long after opening the screen someone does something, which should fall.
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.
The share of sessions which open the dashboard and use it, where the rest go straight past it to the table underneath.
Orders missing their date, tickets breaching and stock running out, which is the reason the screen exists.
Every request to pull the numbers is a question which the screen should have answered, so the count should fall.
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
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.
What it costs
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
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.
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.
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.
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.
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.
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.
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.
The thinking behind it
Client reviews
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
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
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
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.
Send me an email
To Mike Lopez <mike@mikeui.co>
I use these details to reply to you and keep them for 12 months after our last message. Privacy notice