Open the Shopify admin and the home screen tells a merchant what they came for: sales so far, and the handful of things waiting on a decision. Catalogue, analytics, and settings all exist just one level down, so nothing dilutes the user’s focus. The page was built intentionally around one goal — to inform the user about the key metrics — which made a tool handling a lot of information read as calm.
The good news is — such intentionality has a name. It is dashboard design: the craft of deciding what a screen shows, in what order, and to whom, so a user can act without leaving the page. Tricky part: dashboard design must align with your product’s functionality and industry.
In this article, we’ve gathered insights from our AI UX design team — all the nuance you need to know about which type of dashboard fits what product and what design solutions are worth implementing to make your product stand out.
Key takeaways
- Dashboards split along two axes, and many teams mix them. Function is the job the dashboard does and the decision rhythm it serves. Industry is the product it lives in. Every fintech, CRM, or AI dashboard runs on one of the four functional types underneath.
- Decision rhythm picks the type, and the type picks everything else — density, interaction depth, and refresh rate. Data-heavy products put the most strain on this choice, and data dashboard design covers the techniques that hold up at volume.
- The practices stack in a fixed order: decision, metrics, owner, type, hierarchy, drill path, states, style. Teams starting at the styling end ship the dashboard nobody opens a week after launch. Dashboard layout and UX covers the hierarchy stage in depth, and dashboard UI design shows annotated screens where the order was followed.
- Low adoption is usually a decision problem. When a dashboard shows correct data about things nobody acts on, restyling changes nothing. A decision inventory takes about a week and normally finds the cause.
Types of dashboards categorized by function and industry
Dashboards are classified two ways, and many teams mix them. The difference is both straightforward and slightly sneaky. Function stands for the job a dashboard does and the decision rhythm it serves. Industry describes the product it lives inside.
Taxonomies we’ve come across contradict each other because they blend the axes. Keeping the categories apart is what makes the classification usable.
“In dashboard design, function comes first, since it settles density, interaction depth, and refresh rate. Industry then layers on the constraints specific to your product, which is where most SaaS and B2B teams find their real design problem.”
{{Anna Demianenko}}
Types of dashboards per function
There are four types of dashboards by function: operational, analytical, strategic, and tactical. Each is defined by how often its audience makes a decision.
Decision rhythm is the organizing principle, and it frames the rest: how dense the screen can be, how deep the interaction goes, and how often the data needs to be refreshed.
The table below sets out each type, who opens it, what belongs on it, and a product running the pattern well.
The dashboard type you pick costs you more than every design choice you make later. Choose the wrong type and your dashboard gets opened twice, then abandoned, and you start again. Copying the product you admire tells you about its users, whereas these five questions tell you about yours.
1. What does an hour-old number cost the business?
- Money is lost, or a system stays broken → Operational
- A deadline slips before anyone notices → Tactical
- Nothing until the next review → Strategic
- The investigation gets slower → Analytical
2. How long does a user stay on the screen?
- Under a minute → Operational or Strategic
- Long enough to reassign work → Tactical
- Ten minutes or more → Analytical
3. What does a user do immediately after reading it?
- Fix the system → Operational
- Move a deadline or a person → Tactical
- Report, fund, or defend a position → Strategic
- Ask the next question → Analytical
4. Where does the screen get opened?
- On a phone, mid-shift → Operational
- In a weekly stand-up → Tactical
- On a slide in a board pack → Strategic
- On a second monitor, with the raw data beside it → Analytical
5. What do users complain about when the screen fails them?
- "Nobody saw it in time" → Operational
- "I can't tell whether we are on track" → Tactical
- "I had no answer when I was asked" → Strategic
- "I could see what happened, and never why" → Analytical
Where KPI dashboards fit? A KPI dashboard is any of these four built around a defined set of metrics. Our blog on KPI dashboard design covers the selection method and the five role-based variants.
Types of dashboards per industry
Industry dashboard types describe the product a dashboard lives in. Each type is worth an expert debrief. That’s why our designers wrote dedicated guides for each one.
Here’s how to use this table. Find your industry in the first column, then read across to the functional type. That type is your rulebook: it sets the layout, the drill path, the filters, and the refresh rate. The industry column tells you what data you are handling and which constraints come with it. Design to the type, and adapt for the industry.
Each industry name links to a dedicated guide. Open the one for your product: it covers the patterns specific to that market, the constraints worth planning for early, and annotated examples of screens that handle them.
Dashboard design best practices: 8 steps to good dashboard design
Good dashboard design is judged by whether users come back to the product, making retention the metric worth optimising against. The practices supporting it stack in a fixed order, and most failures come from starting halfway up.
1. Name the decision. Write down the choice this screen helps a user make, and how often they make it.
Practical example: Vessel Finance begins with the cargo an investor needs to move, and the summary screen shows the single figure the deal turns on.
2. Select metrics against that decision. Keep a metric when people act on it as often as they open the screen. Two checks do the cutting: if naming a metric takes more than four words, it is the wrong metric, and every metric needs a target or a prior period next to it.
Practical example: Fieldstream applies both, with one filter panel and views built around the metric in question.
3. Give every metric an owner. Put a name next to each metric while you are still choosing them. Anything you cannot assign comes off the list, which usually removes about a third of it.
Practical example: GCF shows the assigned analyst, status, and due date on every engagement, and lets anyone claim unassigned work in a click.
4. Pick the functional type. How often the decision is made tells you which of the four types you are building, and the type then sets how dense the screen can be, how deep the interaction goes, and how often the data refreshes.
Practical example: Flikair stays operational: shipments are ranked by urgency, and everything else waits.
5. Build the hierarchy, and treat the default view as the product. Three to five items at the top, supporting context below, detail behind a click.
Practical example: Xceed365 opens on what needs action, and the modules sit one level down.
6. Design the drill path as carefully as the surface. You can predict the next question. List the two or three follow-ups each top-level metric prompts, design the path to them before any styling, and keep the filters applied as people move down it.
Practical example: eDiscovery Assistant gets a user from the dashboard to a relevant case in three clicks. After our team redesigned the platform, research time fell 75%, from 45-plus minutes to roughly two.
7. Design all four states, and timestamp the data. Loaded, loading, error, and empty. Loaded is the one that reaches review, while empty is the first thing a new user sees, so give it a job.
Practical example: Sentry fills a project with no events with the install snippet.
8. Style last, and let precision carry meaning. Chart type and colour follow the seven decisions above.
Practical example: Thorn Associates ended up with a high-contrast dark interface and colour-coded indicators because the volume of operational data called for them.
Sticking with the right order is key to optimizing the design process. Teams working the stack from step eight upward produce the dashboard nobody opens a few days post-launch.
How a dashboard design engagement runs
At Lazarev.agency, a dashboard project runs in four phases, and the first does most of the work.
Decision mapping (1–2 weeks). We interview your users and record the decisions they make, how often, and what they currently look at to make them. The output is a decision inventory that determines the metric set. Teams skipping this phase almost always build around irrelevant data.
Structure (1–2 weeks). Functional type, information tiers, and the metric set per role. The hard cuts happen here, and the decision inventory finalizes what to drop and what to keep in mind in the design process.
Interface (3–5 weeks). Components, chart selection, all four states, responsive behaviour, and the design system entries supporting it.
Validation (1–2 weeks). Testing with real data at production cardinality, then a five-second test with actual users, and a review at week twelve against the decision inventory.
Pro tip: If you have a dashboard and adoption is low, start with the decision inventory. It helps unravel the problem and build a data-driven strategy to tackle it. If you are scoping a dashboard, settle the functional type first; the constraints following from that choice resolve most later arguments on their own.
We design dashboards for SaaS, fintech, AI, and Web3 products. Talk to us about your dashboard, and we will start with the decisions your users need to make.
