Designing Management Dashboards: See What Needs Action at a Glance

Late in almost every system project, the client says: "I want a dashboard — log in and see all the numbers." And we ask back: "Once you see those numbers, what will you do?" Most people can't answer. A dashboard nobody can answer that question for goes unread within three months of launch — a trap we've stepped in with our own systems and watched clients step in many times.

Lots of numbers is not the same as useful

The most common failed dashboard looks like this: today's revenue, this month's revenue, order count, member count, page views… a dozen numbers standing in a row, each a "current snapshot." The problem: snapshots have no context. Today's revenue is NT$80,000 — good or bad? No idea, because you don't know what the same day last week did or what this month's target is. The boss looks at it for two weeks, realizes no viewing ever leads to any action, and naturally stops looking.

A dashboard's purpose isn't "know how things are" — it's "know what to do now." A dashboard that can't do that is just expensive wallpaper.

Our three principles for dashboard design

1. Exceptions first: show what's abnormal

Things running normally don't need daily attention. What belongs on the first screen is the exceptions: orders unshipped for more than three days, items below safety stock, failed payments awaiting handling, today's unanswered complaints. In our own inventory-management back office, the first block is always "items awaiting action," never a revenue chart. Staff log in, glance once, and know the three things to do first today.

2. Trends and comparisons: every number needs a reference point

A lone number is meaningless; comparison gives it meaning. This week's revenue sits next to the same period last week; this month's order count sits next to the same month last year. One detail trips people up: comparing against "yesterday" is often misleading, because weekday and weekend volumes differ by a lot — comparing Monday to Sunday is scaring yourself. The right comparison is "same day last week" or "the average of the same weekday over the past four weeks."

3. Action-oriented: numbers should be clickable into the fix

If "5 orders overdue for shipping" can't be clicked, the user still has to go filter the order list themselves — the dashboard did half the job. Every alert number should link directly to a pre-filtered working screen: click, and you're already started. This follows the same logic as our piece on admin-panel UX design: every operation you remove is one more chance the tool actually gets used.

Different boards for different roles

Another common mistake: one dashboard for everyone. The owner cares about trends and margins, the store manager cares about today's tasks and stock, the accountant cares about reconciliation discrepancies. Cram it all onto one board and everyone has to hunt for their signal in each other's noise. In practice we split boards by role: the same data, different default views. The engineering cost is lower than you'd think, because the underlying queries are shared — only the layout assembly differs.

Ask the questions first, draw the charts last

If you're about to plan a dashboard, use this order: first list the decisions to be made daily/weekly/monthly, then work back to the numbers each decision needs, and only then choose chart formats. Reverse the order — pick pretty charts first, then find numbers to fill them — and you're on the road to wallpaper. Line charts are for trends, bar charts for comparisons, and pie charts can mostly be skipped entirely; nobody can read information out of a pie chart with more than five slices.

The dashboard is the feature most likely to be "finished but useless," and the clearest test of whether a team has real operating experience. If your system vendor only asks "which numbers do you want to see" and never "what will you do after seeing them," feel free to forward them this article. To talk through how your back office should be designed, have a look at our custom systems and SaaS services.