Dashboard Design: Principles, Examples and a Step-by-Step Process

By Nick Babich

Key Takeaways

• Study examples by job: ten annotated dashboards, from SaaS analytics to finance, logistics and healthcare, look nothing alike yet follow the same rules: one role, few numbers, context for each and priority by position.
• Start with decisions: dashboard design begins with one role, the moment that person opens the screen and the decision they make next. The list of available data comes later.
• Keep headline numbers few: show the metrics that answer the role's first questions, each with a target, a comparison or a trend, and move everything else to detail views.
• Let position carry priority: status goes at the top left, the numbers that explain it sit in the middle, and the lists people act on go at the bottom.
• Choose charts by question: bars, lines and dots on a common scale are read faster and more accurately than angles, areas or 3D effects.
• Design the unhappy states: loading, empty, zero, stale, partial, error and restricted views are part of the scope, and they multiply the work.
• Review with real data: check the design against a real extract and the real role before calling it finished.

Dashboard design is the work of deciding which few numbers a specific person needs to see, in what order and with what context, so they can tell at a glance whether something needs action. A good dashboard answers a recurring question in under a minute and points to the next step. A weak one shows everything the database holds and leaves the reader to work out what matters. The process below starts from decisions, turns them into a short list of cards, arranges those cards by priority and then designs the states that real data produces.

This guide is for product managers, designers and founders building analytics, admin or reporting screens inside B2B software. It opens with ten annotated examples, then follows one fictional worked example from the first question to the final layout. If you plan to bring in outside help, our UX design partners we review for data-heavy products are one place to start, and the shortlist of dashboard UX design agencies we compared covers provider selection. Here the focus stays on the design decisions themselves.

Dashboard Design Examples by Type

The ten examples below are illustrative. Each is a fictional product with invented data, drawn for this guide, and none is a screenshot of a real company’s software. They differ on purpose in palette, type, theme and density, because dashboards are built for different people: a dispatcher who watches one screen all shift can handle far more density than a founder who looks once a week.

For each one, check four things: the role, the question the screen answers first, whether every headline number has context, and where the thing to act on sits. The notes point to the matching step later in this guide.

1. SaaS product analytics: dark theme, medium density

Role and question: a product manager reviewing growth on Monday morning and asking where new users drop off.

What works: Every headline number carries a change figure and a sparkline, so none stands alone (Step 3). The funnel summary names the biggest drop in words, so the reader does not have to hunt for it. The retention heatmap uses one hue and prints each value inside its cell, so color is never the only signal.

Note: A −0.3% change in session length is flagged in red as strongly as a real problem would be. Keep strong color for changes that matter and show small moves in neutral gray.

2. Finance and CFO: editorial serif, light theme

Role and question: a CFO reviewing the month-end position and asking whether the business is on budget and how long the cash lasts.

What works: Five headline numbers sit in one strip, each with a comparison to last month, budget or target (Step 3). Actual cash and the forecast share one line, with the forecast shaded, dashed and drawn as a range rather than one falsely precise path. Receivables aging and the days-sales-outstanding trend sit together, so the reader sees both size and direction.

Note: The pill reading “Month-end close: day 6 of 8, 3 accruals open” is the partial-data state from the states section, placed in the header where nobody can miss it. Finance readers need to know whether the figures are final.

3. Sales pipeline: rounded cards, coral accent

Role and question: a sales manager in the weekly forecast review, asking whether the team will hit quota and which deals need help.

What works: The quota bar carries a marker for straight-line pace, so 52% attained reads as ahead of the 43% expected at day 40 instead of just “about half”. The bottom band is the action list: late-stage deals, the next step and how long each has stalled (Step 4).

Note: The stage bars are sized by dollar value but labeled with deal counts. Say what a bar encodes, or readers will assume its length is the count.

4. Marketing performance: bright, friendly, lower density

Role and question: a head of growth checking where the month’s budget went and which campaigns earn it back.

What works: Large colored tiles form the status band, and the campaign table is limited to “campaigns that need a decision”, with the 3.0x ROAS target in its caption. That is the cut list from the worked example below in practice: not every campaign, only those that change what someone does.

Note: A stacked area chart makes the total and the bottom layer (organic) easy to read but the middle layers hard to compare. For “which channel is growing fastest?”, use lines or one small chart per channel (Step 5).

5. Logistics and operations: dark control room, high density

Role and question: a dispatcher watching live deliveries during a shift and asking which ones are late or at risk right now.

What works: This is an operational dashboard in the sense used below: status first (on-time rate, active vehicles, open exceptions), a map for the one question that is really about place, and an exceptions table that states each impact in text, so the map’s colors are not the only signal. “Live · 12 s ago” shows freshness, so a stale feed would be visible.

Note: This density suits a trained operator who watches the screen all day. The same screen would overwhelm an occasional user, so density should follow the role and how often they look.

6. E-commerce store: minimal, teal accent

Role and question: a store owner checking at 2:30 PM how today compares with yesterday.

What works: The header states the one time frame (“as of 2:30 PM, compared with the same time yesterday”), so every card shares it (Step 3). The cumulative line shows pace through the day, not just a total, and the stock list converts inventory into days of cover, the number that drives a reorder.

Note: Conversion is down 0.22 points while sales are up 14.5%. Headline numbers can disagree, which is why the funnel sits right beside them, in the explanation band of the layout (Step 4).

7. Customer success: friendly blue, readable table

Role and question: a customer success lead planning the week’s outreach. It uses the same role as the worked example later in this guide, but a different product and different decisions.

What works: The health mix uses a donut, which is acceptable here because it has only three parts and the counts are printed beside it. Each flagged account gets a plain-language reason (“Logins down 41% in 14 days”), so the manager knows what to say, not just that a score is low.

Note: The top cards mix a current snapshot, a trailing 12-month figure and a four-month look ahead, and each one labels its period. Whenever cards use different time frames, the label is what keeps readers from assuming one shared range.

8. Healthcare unit: large type, low density

Role and question: a charge nurse running a 32-bed unit on the day shift and asking which patients need attention now.

What works: Large type and big bed tiles suit a glance from a few feet away. Alerts get a red border and the score in text (“NEWS 7”), never color alone, and “Needs attention now” lists the three patients to see first, with vitals, in priority order (Step 4).

Note: A screen that a whole unit can see should show as little identifying detail as possible, which is why this one uses initials. Who may see what is the restricted state from the states section, and in healthcare it needs designing before launch.

9. Energy and IoT: black with a neon accent

Role and question: a facilities manager in a building control room, asking whether the load is normal and where it comes from.

What works: One large number for the current load sits above a bar against the 2.5 MW demand limit, instead of a dial gauge: it uses less space and shows the headroom exactly (Step 5). The load line is set against a typical Monday, so “is this normal?” is answered without a click, and the floor grid answers “where?”.

Note: On the floor grid the brightest cells are the biggest consumers, not faults. The faults live in the anomalies table with High, Med and Low tags. Putting both in one color scale would blur “busy” with “broken”.

10. HR and people analytics: warm light theme

Role and question: a VP of People in the monthly review, asking where the company is losing people and why.

What works: Attrition bars are sorted from high to low with head counts beside them, so 15.6% in Sales (71 people) can be weighed against 11.8% in Engineering (148 people). Sorted horizontal bars are the chart the guide recommends for comparing items (Step 5). The engagement heatmap prints each score as well as coloring it.

Note: Survey averages hide spread: a 3.0 can mean everyone is neutral or half the team is delighted and half is not. The chart guide warns against averages alone, so offer a distribution view one click deeper.

What the ten examples have in common

Palette, type and density change from one example to the next. The structure underneath does not:

• One role and one moment: every screen answers a named person’s first question, and the table above says which.
• Few headline numbers, with context: a target, comparison, trend or capacity limit sits next to almost every one.
• Priority by position: status comes first, explanation sits in the middle and the work list comes last, even where the map or a hero number takes the first spot.
• Color with a second cue: labels, signs, numbers or text back up every status color.

Those four habits come from the process below, shown here in one picture.

What a Dashboard Is For, and What It Is Not

A dashboard is an overview. It tells someone whether things are on track and where to look next. It is not the place for every chart a team has ever requested.

The intended use changes the design. Page Laubheimer at Nielsen Norman Group separates operational dashboards from analytical dashboards: operational ones support time-sensitive tasks such as monitoring server availability or customer-service calls, while analytical ones support analysis and decisions without the same urgency. An on-call engineer needs deviations to jump out within seconds. A customer success lead reviewing the week can afford one more click, but needs trends and comparisons.

A dashboard is also not a report. Reports hold the detail, the full breakdowns and the exports. Microsoft's guidance for Power BI dashboards makes the same split: the dashboard is a single place to monitor the current state of the data, readers drill into the underlying reports for detail, and a detail belongs on the dashboard only if it is what readers need to monitor.

B2B products add their own pressure. One account can have admins, managers and individual contributors with different permissions. Data volume varies wildly between a new customer and a ten-year one. Data often arrives from several systems on different refresh schedules, and many users already export numbers to spreadsheets because the product never answered their question. Those facts belong in the brief from the start.

Step 1: Pick One Role and One Moment

Write one sentence before opening a design tool: [Role] opens this screen [when] to decide [what]. If you cannot fill in all three parts, the dashboard is not ready to design.

The NHS Scotland Turas Design System, in its guide to designing a dashboard, recommends the same discipline: never design a dashboard for everyone, and capture the need as a user story with a user, a need and an outcome. Its example is a workforce manager who wants to see vacancy rates across a service area to identify staffing pressures and prioritize recruitment.

When two roles want different answers on first view, give them different views. A shared screen that tries to serve an executive, a team lead and an analyst usually ends up serving none of them, and the arguments about which card goes first never end.

Step 2: Turn Questions Into Decisions

List the questions the role asks every time they open the screen. Then attach a decision or action to each one. A question with no action attached is usually curiosity, and curiosity belongs in a report.

Three tests help here:

• The action test: if the answer changes, does someone do something different? If not, drop the question from the overview.
• The frequency test: is the question asked on most visits? Questions asked once a quarter can live one click away.
• The owner test: can the person looking at the screen act on the answer? If only another team can act, the card belongs on that team's view.

Step 3: Choose Metrics and Give Each One Context

Each surviving question needs a metric with a written definition: the formula, the data source, the refresh rate and who owns it. Teams that skip this step end up with two cards called "active users" that show different numbers.

Then give every headline number something to be compared with. A number alone says nothing about whether it is good. Useful context comes in four forms: a target, the previous period, a trend over time or a peer group such as the median account. The Turas guide also asks for the reporting period, the date of the latest update, how often data refreshes and any data quality caveats, all of which matter more in B2B products where a sync can fail quietly overnight.

Keep time frames consistent. The Microsoft guidance warns against mixing levels of precision and time, such as one chart showing last month beside charts filtered to a specific month. One global date range at the top of the screen, applied to every card, prevents most of these mismatches. Round numbers to the precision a decision needs: "3.4 million" reads faster than "3,400,000".

Worked Example: A Customer Success Dashboard for a B2B SaaS Product

To make the steps concrete, here is a fictional scenario. Nothing in it describes a real client or product; the numbers are assumptions chosen only to show the method.

• Product: an invoicing platform sold to about 400 business accounts.
• Team: six customer success managers and one customer success lead.
• Data: the product database and the CRM, both refreshed nightly.
• Role and moment: the customer success lead opens the dashboard on Monday morning to decide which accounts get outreach this week and whether renewals are on track for the quarter.

Steps 2 and 3 turn that sentence into five elements: four cards and a ranked table. Each row is one question, the decision it drives, the metric and its context, and where it lands on the screen.

Just as useful is the cut list: metrics that someone asked for but that fail the three tests. In this scenario that includes total sign-ups since launch, revenue by plan, a quarterly satisfaction score and page views. None of them changes what the lead does on Monday morning, so they move to reports linked from the relevant cards.

That is also the answer to how many metrics a dashboard should show: as many as the role's recurring questions need, and no more. Here that is four cards and one table. If the list keeps growing, the screen is probably serving more than one role or more than one moment, and it should be split.

Step 4: Lay Out the Screen by Priority

Placement is the strongest signal of importance on a dashboard. In left-to-right languages, the Microsoft guidance puts the highest level of data at the top left and adds detail in the direction people read. A simple three-band structure works for most B2B dashboards:

• Top band, status: the few numbers that say whether things are fine.
• Middle band, explanation: trends and breakdowns that show why a status number moved.
• Bottom band, action: lists and tables of items someone needs to work on.

PatternFly, Red Hat's open source design system, offers a practical way to get there in its dashboard design guidelines: list the cards, prioritize them, size each one, then arrange them in equal-width columns. Its point about ordering matters for responsive layouts. When a four-column desktop grid collapses to one column on a narrow screen, the priority order decides what people see first.

Keep cards of the same level the same size, align everything to one grid and put filters above the content they affect. The image below shows the worked example arranged this way.

Step 5: Match the Chart to the Question

Pick the chart after the question, never before. The Nielsen Norman Group article cited above explains why some charts work at a glance: 2D position and length are preattentive attributes, so bar charts, line graphs and scatter plots support quick, accurate comparisons, while 3D effects distort the shapes that carry the data.

Color deserves its own rule. Give each color one meaning across the whole product, use a neutral palette for everything that is fine and reserve strong color for what needs attention. Never let color be the only signal: pair it with a label, an icon or a position so people with color vision deficiencies get the same message.

Design the States Real Data Produces

Most dashboard mockups show a healthy account with perfect data. Real accounts are new, broken, partly synced or restricted. The Turas guide asks teams to plan how the dashboard communicates loading, errors, zero values and the absence of data. This matrix extends that list for B2B products and applies it to the worked example.

The matrix is also a scope tool. Four cards and one table across seven states is 35 combinations to specify, before any drill-down view. The table and its filters behind the dashboard follow the same rules as other patterns for dense B2B workflows such as data tables and master-detail views, so reuse them rather than inventing a dashboard-only version.

Scope the Design Work Before You Estimate It

Dashboard estimates go wrong when they count screens. Count the drivers instead: roles, views, cards, states and data sources. Each one multiplies the others.

In the worked example the count is one role, one overview plus three drill-down views (renewals, onboarding and an account detail page), four cards and a table, seven states and two data sources. Adding a second role, such as a sales leader who wants the same renewals data with pipeline context, adds at least one view and reopens the priority decisions. Adding a third data source adds another partial state to every card it feeds.

Write the count into the brief and agree on it before anyone quotes or plans a sprint. To turn a count like this into money and time, see how to budget the wider UX design work. A dashboard rarely stands alone, either: it sits inside the SaaS UX process the dashboard depends on, from research to handoff, and inherits its navigation, permissions and component library.

Review the Dashboard Before Release

Use these eight questions as a last check, with a real data extract on screen and, ideally, the real role in the room:

1. Can the named role answer its first question within a minute, without touching a filter?
2. Does every headline number have a target, a comparison or a trend?
3. Does every card lead somewhere: an action, an owner or a detail view?
4. Do all cards use the same time frame, with the period and the last update visible?
5. Does the layout survive real data: long account names, outliers, missing values and an account with one data point?
6. Is strong color used only where something needs attention, and always with a second cue?
7. On a narrow screen, does the card order still follow priority?
8. Has every card been designed in all seven states?

After release, watch which cards and filters people use. A card nobody opens for a month is a candidate for the cut list, and repeated exports of the same table usually point to a missing card.

FAQ

What makes a good dashboard design example?

A good example is built for one named role, shows a few headline numbers that each carry a target, comparison or trend, orders them by priority and uses color for status with a second cue behind it. Visual style matters less than whether the reader can answer their first question in under a minute.

What is the difference between a dashboard and a report?

A dashboard is a short overview that tells a specific person whether something needs attention. A report holds the detail behind it: full breakdowns, history and exports. A good dashboard links into reports instead of trying to replace them.

Should a B2B product have one dashboard or one per role?

Start with the role whose decisions matter most to the product's value and design that view well. Add views for other roles when their first questions differ, and use permissions to filter data within a view when only the scope differs.

What makes dashboard design harder in B2B software?

Multiple roles and permissions, accounts with very different data volumes, several data sources with their own refresh schedules and users who already rely on spreadsheets. Each of these adds states and edge cases that consumer dashboards rarely face.

How do you test a dashboard design?

Give the real role a prototype filled with a real data extract and ask them to answer their recurring questions out loud. Note where they hesitate, misread a number or reach for a filter. Then check usage of each card after release.

Conclusion

Good dashboard design is mostly a sequence of decisions made before any chart is drawn: one role and one moment, questions tied to actions, metrics with definitions and context, a layout that follows priority and charts chosen for the question. The states that real data produces turn a polished mockup into a screen people trust. The ten examples above show the same structure in ten different styles, which is the point: the look can change with the product and the audience, while the decisions underneath stay the same. Keep the cut list, the state matrix and the scope count in the brief, and the dashboard stays focused as the product grows. If you need a team for the work, the dashboard design shortlist and our wider directory mentioned at the start are the places to compare options.