Dashboard Design Process: From User Decisions to Tested UI

The dashboard design process starts with a person and a recurring decision, not with charts: who looks at this screen, what they need to decide, which data answers it, over which periods, with which filters and comparisons — and what the screen shows before any data exists. Only then do layout, charts and polish have something to serve. Skip that, and you get the most common dashboard in software: beautiful, busy and useless by Wednesday.

Most dashboard projects we are asked to design arrive with the same brief: make a beautiful dashboard. The brief sounds like a design problem. It almost never is. Behind it sits a data and decision model nobody has defined yet, and no amount of gradient will define it for you.

That matters because dashboards are expensive. Every metric on screen needs a data pipeline, a definition everybody agrees on, a place in the layout and somebody to maintain it. Build twenty of them for a user who needs three, and you have paid for seventeen widgets people learn to ignore — plus the support tickets from the users who misread the other three.

This guide walks through the process we use, from the decision behind the dashboard to a tested interface your engineers can build: users and decisions, the dashboard’s job, data, periods and filters, configuration, hierarchy, chart choice, honest scales, states, testing, accessibility, handoff and life after launch.

ANODA solves the decision model and the interface together. We define who needs which answer, map the data and states, and design the filters, comparisons and routes into action. The Combat Sales, Vecna and marketing analytics examples below show how that approach carries across roles and products. You get a dashboard people can work from, instead of an expensive screen they check before reopening the spreadsheet.

The numbers and the setup behind them

RoasRocket puts the brand and tracking completeness before traffic, revenue and the funnel, then lets marketers reach the underlying events. Its custom funnel builder and event-matching screens make the configuration behind a number visible. Marketing analytics design connects that setup to the decisions teams make; dashboard design defines the hierarchy, periods, drill-downs and states. ANODA connects the number with its setup and the next decision, so teams can understand what they are looking at before moving their budget.

The problem is rarely visual

Oksana Kovalchuk, ANODA’s founder, describes the typical start of a dashboard project like a short play in one act:

“Let’s make a beautiful dashboard.” Fine. What are we going to show? “Well, we don’t know. Maybe how many orders were made.” Great. For which period? Which filters do we need? Can we compare the last two weeks with the previous two, or with the same weeks last year? All of this has to be clarified before the dashboard is designed.

Every one of those questions changes the interface. The period decides the default view. The comparison decides whether you need two lines or one. The filters decide the toolbar, the empty results and half the edge cases. A designer who starts drawing before these answers exist is not designing a dashboard. They are drawing a mood board with axes.

It is the art gallery that commissions an ornate frame before anyone has chosen the painting. The frame is lovely. The wall is still empty, and now it is an expensive empty.

Start with the user and the recurring decision

A dashboard is not a report. A report answers a question once. A dashboard answers the same question again and again, for the same person, on a rhythm: every morning, every Monday, every time an alert fires. So the first design artifact is not a wireframe. It is a short decision brief.

For each primary user, write down:

• Who looks at this screen, and in which role.
• The recurring decision they make with it: restock this week, move budget between channels, escalate a failing job, report to the board.
• The questions that decision depends on, in their words.
• The data that answers each question, and whether it actually exists.
• The cadence: hourly, daily, weekly, monthly.
• Done when: what a successful visit looks like, in time or outcome.

If you cannot fill this in, you are not ready to design a dashboard. You are ready to do research. The brief also exposes the elephant in the room early: two stakeholders who want the same screen for opposite decisions. Better to find that in a one-page document than in the fourth round of visual review.

Find the decisions before you write the brief

The decision brief is only as good as the research behind it, and “we asked the stakeholders what they want to see” is not research. Stakeholders ask for metrics. Users make decisions. The two lists overlap less than anyone expects.

Four sources get you to real decisions quickly:

• Interviews about the last time, not about wishes. “Walk me through the last time you decided what to restock” beats “which charts would you like” every time.
• Shadowing the current workaround. Most dashboards replace a spreadsheet, an export or a weekly email. Watch how people use it today: which columns they sort, which rows they highlight, which numbers they copy somewhere else.
• Usage data from the existing product, if there is one: which reports get opened, which exports run every Monday, which filters are always set the same way.
• Support tickets and chat logs: every “where can I see…” is a missing view, and every “why does this number…” is a missing definition.

A dashboard user interface is the visible layer on top of all this: the layout, charts, filters and states people use to answer their recurring questions. Get the questions wrong, and the most polished UI in the world answers the wrong ones, beautifully. That is the costliest kind of wrong, because nobody notices until the renewal conversation.

Decide which job the dashboard does

Not every dashboard does the same job, and mixing jobs on one screen is how you end up with a remote control that has sixty buttons and one that matters.

• Operational dashboards answer “what needs action now?” They are live, scannable and built around exceptions.
• Analytical dashboards answer “why did it change?” They reward exploration: drill-downs, filters, comparisons.
• Strategic dashboards answer “are we on track?” They move slowly, summarise, and are often read in a meeting.
• Monitoring dashboards answer “is anything broken?” They stay quiet until they should not.

Decide which job each screen does. An operational screen with analytical depth hidden behind a click is fine. An operational screen that tries to be strategic at the same time is a meeting slide pretending to be a control room.

Decide the data before you design the interface

With the decision and the job defined, the next step is the unglamorous one: the data. For each question in the brief, confirm which data answers it, where it comes from, how fresh it is, who owns its definition and what happens when it is missing.

This is where many projects stall, and it is better that they stall here than in development. “Revenue” means three different numbers to finance, sales and marketing. “Active user” means whatever the last person to write the query decided. If the dashboard shows a number, the team has to agree on what the number means, or the screen will generate arguments instead of decisions.

Data readiness also shapes the design directly. A metric that updates once a day should not sit in a live panel pretending to be real-time. A metric that is sometimes incomplete needs a partial state. A metric that is missing for new accounts needs an empty state — we will get to that, because it is the most neglected screen in the entire product.

Periods, comparisons and seasonality

A number on its own is trivia. Twelve hundred orders — is that good? Compared with what? The period and the comparison are what turn a number into information, and they have to be decided before anyone draws the screen.

Decide the default period for each dashboard job, and which comparisons users need: the previous period of the same length, the same period last year, a target, a peer group. Seasonality matters more than most teams admit. A shop whose orders drop in January has not failed; it has had January. Comparing with the same weeks last year tells the truth that comparing with December hides.

Then design the comparison itself: how the user switches between comparisons, how the delta is labelled, what happens when the comparison period has no data, and whether the chart shows both periods or only the change.

Filters and compound filters

Filters look simple until the second one arrives. Date is easy. Date and region is manageable. Date, region, and channel online or marketplace, but not wholesale — now you have compound filters, and a set of design decisions most teams make by accident.

Decide early:

• Which fields can be filtered, and which cannot, and why.
• How filters combine: AND across fields and OR within a field is the most common rule, but users must be able to see it.
• Where active filters live, so nobody reads a filtered number as the total.
• Whether views can be saved and shared, because the same combination gets rebuilt every Monday otherwise.
• What happens when a combination returns nothing, which is not an error and should not look like one.

The most expensive filter error can be invisible: a user forgets a filter is on, reads the filtered number as the whole and makes a decision on it. Make active filters clear beside the result.

MantisHub: keep powerful filters visible without taking over the list

In MantisHub’s issue-tracker redesign, the old View Issues page placed a large grid of filter fields above the issues. We moved filters into a dedicated panel, with fast filters and separate issue, people, date and other criteria. Each tab shows how many criteria are applied; Clear and Save Filter sit beside the work they affect.

The design separates access to complex criteria from awareness of the current result. A compact list still needs to show that filters are active. Saving a view preserves a repeated working context; clearing criteria changes the result without implying that the underlying issues were deleted. That is the difference between a powerful filter panel and a list people can confidently work from.

For an agreed flow with unclear visual hierarchy or missing interaction states, UI design turns those requirements into an interface engineers can build. If the screen is part of a technical product, developer-tools design connects the data, setup and recovery controls to the operator’s job. In Superstream, a Kafka cluster overview connects optimization status, savings and technical context to the next action. ANODA makes the control understandable without stripping away the detail specialists need.

Roles, permissions and who sees what

Many dashboards serve several roles at once: an owner, a manager, an analyst, a client who logs in once a month. Each sees a different slice, and the design has to decide how.

Start from the decision brief for each role, then decide what changes between them: which metrics appear, which filters are pre-set, which data a role is not allowed to see at all, and what the screen shows when a permission hides part of it. A widget that silently disappears for one role leaves a hole in the layout and a question in the user’s head. A short “available to account owners” message answers it.

Be careful with totals. A manager who sees three of five regions and a headline figure labelled “Total” will read it as the company total. Label scope explicitly — “Total for your regions” — or you have built a dashboard that misleads by permission.

Combat Sales: make the role and company context explicit

Combat Sales serves five roles: Superadmin, Company Administrator, Trainer, Reviewer and Student. We mapped their permissions and workflows before redesigning selected areas of the existing desktop platform. The Reviewer remained a separate role, while the Superadmin needed an explicit selected-company context when switching between client organisations.

For an LMS product, bring us the dashboard where a trainer cannot find the course awaiting approval or a student cannot see the next lesson. ANODA connects the company context, role permissions and learning task before choosing the widgets.

The dashboard lesson is practical: define the work and scope for each role before choosing its widgets. A trainer’s day, a student’s progress and cross-company administration need different priorities. The redesign retained the familiar dark interface and extended the existing UI kit; it did not require inventing a new platform to clarify those decisions.

Fixed, widget-based or configurable

Another decision that belongs before design: can users change the dashboard? There are three honest answers, and each one has consequences.

A fixed dashboard is the same for everyone. It is the fastest to design and test, and right when users share one job. A widget-based dashboard lets users choose from a curated set of blocks, which keeps quality high while allowing some personalisation. A fully configurable dashboard lets users build their own from metrics, chart types and filters. It sounds generous and is by far the most expensive: every combination needs to render sensibly, including the ones nobody imagined.

Oksana’s point here is precise: if the dashboard is not editable, fine — but it still must adapt to the user’s own data. Fixed layout does not mean fixed numbers.

Prioritise metrics and build the hierarchy

Once the data is defined, most teams discover they have far too much of it. The temptation is to show everything, because every metric had a sponsor. The result is a fridge full of neatly labelled leftovers from 2019: technically all food, practically nobody eats any of it.

Triage ruthlessly against the decision brief:

• Primary metrics answer the recurring decision directly. Three to five, at the top, large.
• Secondary metrics explain the primary ones. They sit nearby, smaller.
• Everything else goes into drill-downs, detail pages or a separate analytical view.

Then build the visual hierarchy to match: position, size, contrast and grouping should tell the eye what matters before the brain reads a single label. Consistent units, consistent decimal places and consistent time labels do more for comprehension than any colour palette.

Overview, detail and the paths between them

One screen rarely carries a whole decision. The usual structure is an overview that answers “is anything unusual?” and detail views that answer “what exactly, and why?”. The design work is in the paths between them.

• Every primary metric should lead somewhere. Clicking a number should open the breakdown behind it, with the same filters and period already applied. A drill-down that resets the filters is a trapdoor.
• Keep the way back obvious. Breadcrumbs, a persistent back action and a visible summary of the current filters stop users from getting lost three levels deep.
• Split dashboards by job, not by department. When one screen starts serving two different decisions, it is time for two screens, linked to each other, rather than one screen with twice the widgets.
• Name views after the question they answer. “Restock this week” is findable. “Inventory analytics v2” is not.

Too many cooks spoil the broth, and too many stakeholders spoil the overview. If every team demands a tile on the main screen, give each team its own view and keep the overview for the decision it was built for.

For SEO software, a score earns its place when a site owner can see what to fix next. In SEOSpace, ANODA redesigned the extension, web app and website around page checks, site-audit priorities, SEO health and AI Visibility summaries, with recommended next steps. Our SEO software design connects those summaries to the issue, affected page and next action. Bring us the dashboard people read but cannot work from; we turn its findings into a clear path through the product instead of another score users must interpret alone.

Choose charts by question, not by habit

Here is a pattern we see in almost every dashboard we audit. Lines, bars and pies, over and over, whatever the data. Oksana’s complaint is blunt: everyone reaches for the same lines, bars and circles, as if no other visualisation existed.

The chart should follow the question:

• Comparing items? A sorted bar chart.
• Change over time? A line.
• Parts of a whole? A stacked bar, or a pie only when there are very few parts and the point is proportion.
• Two measures per item? A scatter plot.
• Many categories across time? A heatmap.
• Many segments with the same shape? Small multiples.

The deeper problem is dimensions. Most dashboards flatten everything into two: a measure against time, a measure against a category. Real decisions often need three or four: this product, in this region, this month, compared with last year. Oksana’s example from practice is that even popular workspace tools make a four-dimensional slice of data hard or impossible to build. If your users need that slice, the design has to provide it — through small multiples, pivoted tables, heatmaps or drill-down — rather than pretending the question is simpler than it is.

Compare the visualization with the actual question

A missing observation is not zero. Leave a visible gap in a time series when a source failed, and explain the interval rather than drawing a reassuring continuous line. Keep units, rounding, comparison periods and filters consistent between a chart and its table view.

Make the scale tell the truth

This one is small, and it is where dashboards quietly lie. A chart designed with demo data looks perfect with demo data. Then it meets a real user with real numbers.

Oksana’s example: a user who has two orders one week and five the next. For that user, it is a two-and-a-half-times increase — huge news. On a chart whose axis was hard-coded to start at 100, both bars look the same height. The dashboard just told the user nothing happened, at the exact moment something did.

Scales must adapt to the user’s actual values: sensible ranges, a zero baseline for bar charts, readable units at every size, and labels that survive both very small and very large numbers. Test every chart with small, large, zero, negative and missing values before anyone signs off. It is close but no cigar to test only with the numbers in the sales demo.

The small details that decide whether people trust the numbers

Users do not trust a dashboard because it looks expensive. They trust it because every number explains itself when they poke at it. A handful of details do most of that work:

• Exact values on hover or tap, so nobody has to estimate a bar’s height against the gridlines.
• Definitions one step away. A small info affordance on each metric that says what it counts and what it excludes.
• Timestamps. “Updated 5 minutes ago” answers the question every operational user asks before acting.
• Annotations for known events — a campaign launch, a price change, an outage — so a spike is not a mystery every time someone opens the chart.
• Export that respects the view, including the current filters and period, so the spreadsheet matches the screen.
• Consistent rounding and units, so 1.2k on one card and 1,187 on another do not start an argument.

None of these make it into a pitch deck. All of them decide whether the dashboard becomes the place decisions happen or the place people check before they open the spreadsheet they actually trust.

Design every state, starting with empty

Dashboards live in more states than their designers usually draw. The screenshot in the pitch deck shows one: full of healthy data. Real users meet all the others.

The worst of them, in Oksana’s words, is the empty state:

I have just registered, I open the application, and there is an empty dashboard with nothing in it. No call to action, no demo data, nothing at all. That is the most important part.

This is where paid acquisition goes to die. You bought the click, the user signed up, and the first screen they see is a set of empty frames. A new user with nothing to do does not wait for data. They leave, and you pay for the next one.

The fix is to treat the empty state as a real screen with a job: explain what will appear here, give one clear next action, and offer a way to explore — demo data that is clearly marked and easy to remove, a sample report, a guided first step.

Related, and just as common: making the dashboard the default home page because products are supposed to have one. If there is nothing on it yet, it is the wrong front door. Land new users where they can do the first useful thing, and bring them to the dashboard once it has something to say.

Then design the rest: loading, partial data, stale data, errors and no results for the current filters. Each one needs its own message and its own next step.

Prototype with real data and test with real tasks

Test the dashboard the way it will be used: with realistic data and real decisions, not with lorem ipsum and perfect curves. Build the prototype with data that has the shape of the real thing: small accounts and large ones, gaps, spikes, a bad week.

Then give users tasks that come straight from the decision brief. Which products should you restock this week? Did last month’s campaign pay off compared with the same month last year? Why did orders drop on Tuesday? Watch where they look first, what they misread, which filter they forget is on and how long it takes them to reach an answer they trust.

Ask them to explain each delta in their own words; if they cannot say what “+18% vs same period last year” means for their decision, the label failed, however tidy it looks. Five or six sessions per primary user type usually reveal the big problems: a hierarchy that sends the eye to the wrong place, a comparison nobody understood, a chart that answers a question nobody asked. That is cheaper than finding them after the dashboard ships and the number of people opening it starts to slide.

Accessibility is part of the design, not a pass at the end

Dashboards are dense, which makes them easy to get wrong for people with low vision, colour-vision differences, or who use a keyboard or screen reader.

• Never rely on colour alone. Red and green for good and bad fail for many people. Add a sign, a label or an icon.
• Keep contrast readable for text, lines and the thin gridlines that dashboards love.
• Give charts a text alternative: a short summary of what the chart shows, and a table view for the underlying numbers.
• Make filters and drill-downs keyboard-accessible, with visible focus.
• Check large text sizes, so labels do not overlap or truncate.

An inaccessible dashboard is not a smaller audience problem. It is a group of paying customers who cannot read the numbers they pay for.

Hand off something engineers can actually build

A dashboard design is only as good as what reaches development. Handing over a set of beautiful screens leaves the hard parts to guesswork, and guesswork in dashboards means wrong numbers in production.

A useful handoff includes:

• The metric definitions and freshness rules agreed earlier.
• The data contract for each widget: what it needs, what it does with missing values.
• Every state for every widget, including empty, partial, stale, error and no results.
• Scale and formatting rules: baselines, units, rounding, very large and very small values.
• Filter logic written down, including how filters combine and which fields are filterable.
• Acceptance criteria a tester can check without asking the designer what they meant.

This is also where a component library earns its keep. Charts, cards, filter bars and state messages built once and reused keep the next dashboard from reinventing all of the above.

Dashboard design best practices worth keeping

Most lists of dashboard design best practices are a pile of rules without a reason. These are the ones that survive every project we work on, because each one protects a decision:

1. One primary decision per screen, with the numbers that answer it at the top.
2. Three to five primary metrics, with the rest in drill-downs.
3. Every number with a period, a comparison and a definition within reach.
4. Charts chosen by the question, not by what the library does by default.
5. Scales that start where the user’s real values need them to.
6. Active filters always visible.
7. A designed empty state with one next action.
8. Every state — loading, partial, stale, error, no results — with its own message.
9. Nothing that relies on colour alone.
10. A handoff that includes definitions, states and acceptance criteria, not just screens.

If a rule on some other list does not protect a decision, it is decoration. Decoration is fine. Just do not pay for it before the decisions work.

After launch: measure use, then prune

A dashboard is not finished when it ships. Watch which views get opened, which filters get used, which widgets nobody ever looks at and where users export data to do the work somewhere else. Exports are a strong signal: people usually export when the dashboard did not answer their question.

Then prune. Every widget nobody uses is still costing you: data pipelines, maintenance, cognitive load for everyone who scrolls past it. Retiring a widget is a product decision, and it is usually the right one. Kicking the can down the road only makes the next redesign bigger.

What this looks like in a real product

Concussion Media is a SaaS where paid-traffic teams read performance, follow funnels and leads, run automation rules, approve creatives and set up campaigns. The redesign started with an audit of the analytics module — screens, content and open questions laid out and marked up — before anyone redrew a chart.

Only after that did the performance dashboard get its new structure: the numbers teams act on first, each read in the context of the others. Performance leads into spend and budget, audiences and the creatives behind the result. A media buyer can follow the question down the page instead of treating every chart as a separate report.

Read how it came together in the Concussion Media case study. Designing the source, conversion and attribution context behind those figures is covered in our marketing analytics design expertise.

When the summary needs the evidence behind it

In ROAS Rocket, ANODA designed the Activity Log to read from the selected brand and tracking completeness through traffic and sales to funnel stages and recent events. Customer journeys show the clicks leading to a purchase; event management exposes matching scores and the data used in attribution.

For marketing dashboards, that means naming the selected model, period and source alongside a comparison and giving the reader a route into the journey or event behind it. A reporting problem may need a setup correction, not another chart. The product connects analysis with source, event and destination setup for that reason.

Vecna: turn the warehouse state into an owned action

In Vecna Robotics’ CaseFlow redesign, operations managers read live maps, shift progress, robot states and exception analytics in the Console. We unified the chart language, tables and filters, then mapped Customer Alerts from claim through reassignment, snooze and resolution. The work covered 192 unique screens, UI kits and clickable prototypes handed to Vecna’s team.

An exception dashboard needs that path from signal to responsibility: show what happened, who owns it and which action changes its state. The warehouse handheld serves a different job. Its 460 × 460 screen guides pickers through tasks in gloves; it does not shrink the entire management dashboard into the aisle.

For a logistics or warehousing product, bring us the exception your shift team spots but cannot own or resolve. ANODA connects the live status, the responsible person and the recovery action across the Console and handheld task. A new chart cannot fix that handoff; a complete operational journey can.

A reporting interface stops sending the analyst back to a spreadsheet when its definitions, source jobs and actions work together. Our MarTech development service implements that complete path: reconciled inputs, visible freshness and failures, connected reports and controlled automation. Bring the weekly report your team still rebuilds by hand; ANODA will turn the repeated work into a working product.

When to bring in help

If you are planning a new dashboard or a substantial redesign and want the decisions, data, states and interface worked out together, that is what our dashboard design service does. If you already have a dashboard and cannot tell why people struggle with it, start with a UX audit before you pay for another round of visuals. When the dashboard is one part of a larger product, SaaS product design is the broader context.

For the narrower web-layout side of dashboards, read our web dashboard design guide. Designing for small screens brings its own constraints, covered in our mobile dashboard design tips.

The decision rule

Before you commission dashboard UI, check that your team can answer these questions:

1. Who uses this dashboard, and which recurring decision does it support?
2. Which job is it — operational, analytical, strategic or monitoring?
3. Which data answers each question, and does everyone agree on what each number means?
4. Which periods and comparisons matter, including seasonality?
5. Which fields can be filtered, and how do filters combine?
6. Is the dashboard fixed, widget-based or configurable?
7. Will every chart’s scale adapt to the user’s real values?
8. What does a brand-new user see, and what can they do next?

If any answer is “we’ll figure it out in design”, you are about to pay designers to guess. Do not design a dashboard until the product team can say what data it will show, why the user needs it, how the user will filter and compare it, how the scale will respond to real values, whether it can be configured and how the product behaves with no data. A dashboard built for its own sake is an empty frame on a gallery wall. The job is a truthful decision interface that stays useful from the first empty screen to the most tangled multi-period question.