Most B2B dashboards are built backwards. Someone lists every metric the database can produce, the team squeezes them all onto one screen, and six months later nobody opens it without being asked to. The data is technically there. The product is technically done. And the users are exporting to spreadsheets anyway.
I design dashboards, internal tools and B2B portals for SaaS teams, and the difference between a dashboard people use and one they avoid is rarely the charting library. It is a set of UX decisions that get made, or skipped, before anything is drawn. These are the eight I lean on in every engagement.
1. Start from decisions, not data
Every screen should answer one question a specific person actually asks. “Operations lead checks each morning whether any order will miss its promise date” is a design brief. “Show order data” is not. Before wireframing, I write down each user role and the two or three decisions they make with the product each week. The dashboard’s hierarchy falls out of that list almost automatically: the decision-critical number gets the top left, its trend gets the second glance, and everything else earns its place or leaves.
2. Make the first five seconds do the work
A good dashboard answers “is everything okay?” before the user consciously reads anything. That means one clear primary status per screen, calm defaults, and loud treatment reserved for the exceptional case. If your interface shouts about everything, it informs about nothing. Design the healthy state to be visually boring, and let deviation be the thing that draws the eye.
3. Respect the table
B2B products live and die in tables, and tables are where design effort pays back the most. The details that matter in practice:
- Right-align numbers, and keep decimal places consistent so columns scan vertically.
- Use tabular figures so digits line up.
- Offer density options: comfortable for browsing, compact for power users who want forty rows in view.
- Let people sort, filter and keep those settings between sessions. A table that forgets its filters trains users to distrust it.
- Freeze the identifying column so horizontal scrolling never loses the row’s identity.
4. Design the empty, loading and error states first
In demos, every chart is full. In real life, a new customer sees an empty dashboard on day one, a slow query shows a spinner, and an expired integration shows an error. Those three states are most of a user’s first week, and they are where trust is built or lost. An empty state should say what will appear here and how to make it appear. An error should say what happened and what to do next. Skeleton screens beat spinners because they teach the layout while the data arrives.
5. Progressive disclosure beats bigger dashboards
The instinct to add one more chart to the overview is how dashboards die. Structure the product in layers instead: overview for the “is everything okay?” glance, one click to the entity list, one more click to the detailed record with full history. Each layer earns the next. When a stakeholder asks for a new widget on the overview, the real question is: which decision, made how often, requires it at this layer?
6. Use color as a language, not decoration
In a data product, color is semantic budget, and it runs out fast. Pick one meaning for each hue and never spend it on anything else: red for genuine problems, amber for needs-attention, green for confirmed-good, one accent for interactive elements. Everything else stays neutral. The moment red also means “brand accent” and “chart series 3”, your users stop trusting red, and you have lost your alarm channel. This discipline also gets you most of the way to accessible contrast for free.
7. Treat speed as a design feature
Perceived performance is UX. Sub-second screens feel like a tool; three-second screens feel like a report. Designers influence this more than we admit: fewer widgets per view, pagination instead of infinite everything, cached summary numbers with drill-down on demand, and optimistic UI for common actions. If a number is expensive to compute live, show yesterday’s with a timestamp rather than a spinner. Users forgive slightly stale; they do not forgive slow.
8. Systematize early, even for internal tools
Internal tools rot because every new screen is improvised. A small design system stops the rot: one table component, one form layout, one set of status chips, spacing and type tokens, and documented empty/error patterns. It does not need to be fancy. Even a modest component library means screen fifteen ships as fast as screen five and looks like it belongs to the same product. This is also what makes handoff to a stretched engineering team survivable.
The process that gets you there
Principles only work inside a process. Mine is the same four steps whether the project is a marketing site or a distribution platform: immerse in the domain and interview the actual users, document the strategy and flows before drawing screens, design wireframes then high-fidelity with a working prototype, and support development so the details survive contact with reality. You can read more about how I run projects on the about page, and see the kind of work it produces in recent projects, including a B2B distribution SaaS platform.
Frequently asked questions
What makes B2B dashboard design different from consumer UX?
Frequency and stakes. B2B users open the same screens hundreds of times a year to do their job, so efficiency, density and consistency outweigh novelty. Onboarding matters once; the ten-thousandth session is the real design target.
How many metrics should a dashboard show?
As many as the decisions demand and no more. In practice, overviews with five to seven primary numbers plus one or two trends outperform metric walls. Everything else belongs a click deeper.
Should internal tools get real design investment?
Yes, proportionate to usage. A tool used daily by twenty people for years multiplies small frictions thousands of times. You rarely need polish; you always need clarity, speed and consistent patterns.
When should a SaaS team bring in a designer?
Before the data model hardens around the wrong workflows. The cheapest time to fix a dashboard is while it is still a wireframe. If that is where you are, tell me about your product.
Planning a website or product design project?