Sevginur Ak Parlak
Jul 12, 2026
9 min read
B2B SaaS Dashboard Design: How I Design Data Heavy Interfaces
Every second product I am asked to look at has a dashboard, and in most of them the dashboard is the least used screen in the product. People land on it, scan it for 2 seconds, and click straight into the table or the list where their actual work lives.
That is the core problem with dashboard design in B2B SaaS. Teams build a screen that shows data, when the user needed a screen that answers a question. Showing data is easy. Answering a question means you decided, before any chart existed, what the user is trying to find out and what they will do about it.
This post is how I design data heavy interfaces: what I ask before I open Figma, the layout patterns I use, how I treat tables and charts, the states everyone forgets, and what a dashboard project costs and takes at Studio Scale.
Dashboards fail for 4 reasons, and none of them is visual
Before the patterns, the diagnosis. When I audit a dashboard that nobody uses, it is almost always 1 of these 4.
It has no question.
The screen was specified as "show the key metrics", so it shows 12 numbers of equal size, and none of them tells the user whether today is a good day.
It is a copy of the database.
Every table in the backend became a card in the interface. The structure of the system leaked into the structure of the screen, which is the most common information architecture failure I see in B2B products.
It serves 3 roles at once.
An admin, an analyst and a field user open the same screen and each of them needs a different first row. Instead of 3 designs, the product ships 1 design with 3 audiences and satisfies none.
It has no next action.
The user sees that conversion dropped 8 percent and there is nothing to click. A number without a path to act on it is a report, not a product surface.
The 5 questions I ask before designing a dashboard
I run these in the kickoff call, and they take about 45 minutes. Every dashboard project I have done where we skipped them cost more later.
1. Who opens this, and how often?
A screen someone opens 30 times a day is a different design from one they open every Monday. Daily users need density and speed, weekly users need context and labels. If you tell me both, we design 2 views, not 1 compromise.
2. What decision follows?
I ask the user to finish this sentence: "when I see this, I will ...". If the sentence cannot be finished, the metric is decoration and I remove it. In most dashboards I audit, between 30 and 50 percent of the visible numbers fail this test.
3. What is the 1 number that means something is wrong?
Every operational dashboard has one. Failed payments, queue length, error rate, unassigned tickets. That number gets the top left position and the largest type, and everything else supports it.
4. What is normal?
A number alone is unreadable. 4,200 sessions is only meaningful next to last week, the target, or the same day last month. Comparison is not a nice extra, it is the thing that makes a metric legible.
5. Where does the user go next?
Every card should lead somewhere: a filtered table, a detail view, a workflow. I design the dashboard and the destination together, because a dashboard without destinations is a dead end.
The layout I use for most B2B dashboards
I structure a data heavy screen in 4 bands, top to bottom, and the order is about attention rather than aesthetics.
Band 1, the status line.
1 sentence or 1 number that answers "is anything wrong right now". This is the part a user reads in under 2 seconds while the coffee is still in their hand.
Band 2, the 3 to 5 headline metrics.
Not 12. Each with a comparison and a trend direction. If your team argues about which 5, that argument is the design work and it is cheaper to have it now than after the interface is built.
Band 3, the 1 chart that explains the headline.
A dashboard needs fewer charts than people expect. I usually design 1 primary chart with a time range control, and I push the rest into an exploration view.
Band 4, the work.
The list, table or queue where the user actually does something. In most B2B products this band is where 80 percent of session time is spent, and it deserves 80 percent of the design attention.
Tables are the real dashboard
In B2B SaaS the table is the product. I spend more design time on 1 table than on 5 charts, and these are the decisions that matter.
Density.
Give the user a row height control with 3 options. A compact row of 32 pixels shows about twice the rows of a comfortable one, and power users will always choose compact once they know the data.
Column priority.
Decide the first 4 columns with the person who uses the product daily, not with the product owner. Everything else goes behind a column picker, and the picker remembers the choice per user.
Alignment.
Numbers right aligned, text left aligned, tabular figures for anything you compare down a column. This sounds small and it changes scan speed a lot.
Filtering over searching.
Search finds 1 known thing. Filters answer a question. B2B users need saved filters far more often than they need a search bar, and saved views are the feature that turns a table into a workflow.
Row actions.
The primary action belongs in the row, not 2 clicks deep in a detail page. If the user opens 40 records a day only to click 1 button, that button belongs in the list.
Bulk actions and undo.
Anything applied to 200 rows needs a preview of what will change and a way back.
Choosing charts, with 3 rules
I do not choose charts by taste. I choose them by the question in the caption.
Change over time is a line chart. Comparison between categories is a horizontal bar, because labels fit and stay readable. Composition is a stacked bar, not a pie, unless there are 2 parts. Distribution is a histogram, and it is the most underused chart in B2B products, because averages hide the tail where your support tickets come from.
The 3 rules I hold to:
Every chart carries a caption that states the argument, not the metric name. "Signups fell for 3 weeks after the pricing change" instead of "Signups over time".
No chart without a comparison baseline: a target, a previous period, or a segment.
If a chart needs a legend of more than 5 items, it is 2 charts.
For colour I follow the same rule as our own brand system: 1 accent with 1 meaning per screen. In a dashboard the accent means "this is the thing to look at", and the moment a product uses 6 colours as decoration, colour stops carrying meaning at all.
The states everyone forgets
This is where I find most of the work in a dashboard project. A single data card has at least 7 states, and teams usually design 1.
Empty, new account - Show what the card will contain, with sample data or a setup action
Empty, filtered to nothing - Say which filter caused it and offer to clear it
Loading - Skeleton in the same shape as the result, not a spinner
Partial - Show what arrived and mark what did not, rather than blocking the screen
Stale - Say when the data was last refreshed, always
Error - Say what failed and what the user can do, and keep the rest of the page alive
Too much data - 10,000 rows, 400 series, a name of 90 characters. Decide now, or the browser decides for you
No permission - Explain that the data exists and who can grant access
Add a role dimension to that list. In a multi role B2B product, the admin, the manager and the operator see different cards, different filters and different empty states. I design the role matrix before the screens, because retrofitting permissions into a finished dashboard is one of the most expensive changes a team can make.
Performance is a design decision
A dashboard is the slowest screen in most products, because it asks 9 questions of the backend at once. 3 things I design around it:
Load the page in sections, so band 1 and band 2 arrive first and the heavy chart arrives after. A user who sees the status line in 400 milliseconds will wait 3 seconds for the chart.
Make the default time range small. Most teams default to 12 months because it looks impressive in a demo, then every user waits for data they did not ask for. Default to the range the daily user needs.
Design the refresh model explicitly. Live updating numbers look modern and make a table impossible to read while you work in it. My default is a manual refresh with a visible timestamp, and live updates only where the job is monitoring.
Mistakes I see most often
Designing with fake data.
Real data has 47 character names, negative values, missing days and 1 customer with 400 times more rows than everyone else. All of it changes the layout.
Adding a metric because it is available.
Every number you show costs the user attention on the numbers that matter.
Copying a consumer analytics product.
Those dashboards are designed for browsing. Your users are working, and working users want density, filters and speed over generous white space.
Building a customizable dashboard too early.
Drag and drop widgets look like a solution to disagreement inside the team. In practice under 10 percent of users ever rearrange anything, and you now maintain every possible layout. Design 2 good default views per role first.
Treating the dashboard as a launch feature.
The dashboard is usually the last screen that should be designed, because it summarises work that the rest of the product has to define first.
FAQ
What makes a good B2B SaaS dashboard?
It answers 1 clear question for 1 role, in under 5 seconds, with a comparison so the number is readable, and a path to act on what it shows. Every card leads somewhere, and every state, including empty and stale, is designed.
How many metrics should a dashboard show?
3 to 5 headline metrics. Beyond that people stop reading and start scanning. Everything else belongs in an exploration view or a table with saved filters.
How long does dashboard design take?
1 to 2 weeks for a single role dashboard on an existing design system, 3 to 4 weeks when the working table and a second role are included, and 5 to 8 weeks for a full analytics area with 3 or more roles.
Should a B2B dashboard work on mobile?
Usually not as a full copy. I design a reduced mobile view with the status line, 3 metrics and the 1 action people need away from a desk, like approving or assigning. Reproducing a 12 column table on a phone helps nobody.
Do we need a design system before the dashboard?
Not before, but you will need one after. A dashboard produces the largest component set in most products: tables, filters, charts, cards, empty states. We usually extract the system from the first dashboard rather than building it upfront.
Working with us
We design B2B SaaS dashboards, admin panels and data heavy interfaces for product teams, usually within 2 to 4 weeks, working against your real data from day 1. You get the role matrix, the layout, the component set including every state, and a working session with your engineers so the table behaves the same way in production as in Figma.
We also say when a dashboard is not what you need. Sometimes the honest answer is that the table needs saved views and the dashboard can wait 2 quarters.
If your dashboard is the screen everybody skips, book a free 15 minute intro call and show it to us. We will tell you which question it is failing to answer.
