A business system can be technically correct and still go unused. Staff open the dashboard, see a wall of charts and unfamiliar labels, and go back to the spreadsheet or the WhatsApp group they trust. The owner concludes that the team resists change, when the real problem is usually the design.
Dashboards are often designed by people who understand the data, for people who only need to do their job. Below are eight mistakes we see in how dashboards get planned, and what to do instead. Most of them can be fixed before any screen is built.
1. Starting from the data you have, not the decisions staff make
The easiest way to plan a dashboard is to list every figure the system stores and find a place for each. The result is complete and useless, because nobody opens the screen with the question “what does the database contain?”
Start with the questions people actually ask during the day. A shop manager might ask, “Which orders are late?” A clinic coordinator might ask, “Who is arriving in the next hour, and who hasn’t confirmed?” Write those questions down, per role, and let each one decide what appears. A figure that answers no one’s question can live in a report instead.
2. Putting everything on the first screen
Fear of hiding something important leads to crowded screens: twelve cards, four charts, three tables. For a non-technical user, every extra element is another thing to interpret, and the important item gets lost among the rest.
Give the first screen a clear hierarchy:
- Top: the few things that need attention today.
- Middle: a small set of summary figures that show how things are going.
- Behind a click: detail, history and filters for people who want to dig in.
If you cannot decide what belongs at the top, that is a sign the purpose of the dashboard is not yet clear. Resolve that first.
3. Using the system’s vocabulary instead of the team’s
Labels such as “entity status,” “SKU variance” or “pending_review” come from the database or from the developers’ notes. Staff do not talk that way. When they have to translate every label, they stop trusting what they see.
Collect the words your team already uses for things: what they call a customer, a job, a delivery, a complaint. Use those words in headings, filters and buttons. Where a term must be precise, add a short plain-language explanation beside it rather than a manual somewhere else. Our microcopy checklist covers this kind of wording in more detail.
4. Showing numbers without meaning
A card that says “148” tells a user nothing on its own. Is that good? Higher than yesterday? Above a target? Someone with analytics training may know how to find out. Everyone else will guess or ignore it.
Give every key figure context:
- A comparison, such as against last week or the same period last month.
- A target or threshold, so people know what “normal” looks like.
- A clear signal when something is outside that range, using words or icons as well as colour.
- A plain label saying what the number counts and over which period.
Also choose chart types carefully. A simple list sorted by urgency is often easier for a non-technical user than a clever visualisation.
A good dashboard lets someone see what needs attention and what to do about it without asking a colleague or a developer. If that takes explanation, the design is not finished.
5. Reporting problems but not letting people act
Many dashboards are built as viewing screens. A user spots an overdue invoice, an unanswered inquiry or a low stock item, and then has to leave, search for the record in another menu, and start again. Each step is a chance to give up.
Wherever the dashboard flags something, put the next action next to it: a button to follow up, reassign, approve or mark done. Clicking an alert should land on the exact record, not a general list. This is one of the main differences between a report and a working tool, and it is why the dashboard should be planned together with the workflows behind it. If your system involves several connected processes, web application and business system design needs to treat screens and workflows as one problem.
6. Building one dashboard for every role
The owner wants revenue trends. The admin wants today’s tasks. The warehouse lead wants what to pack next. A single screen that tries to serve all of them serves none well, and it often exposes information some staff should not see.
Identify the two or three main roles and design a default view for each. They can share components and a visual style while showing different content. Fewer choices per person means less training and fewer mistakes. If you are unsure which roles matter, look at who logs in most often and what they do in their first five minutes.
7. Forgetting the unhappy states
Mockups usually show a dashboard full of tidy data. Real use includes the first day when nothing has been entered yet, a filter that returns no results, a connection that fails, and figures that have not updated since the morning.
Plan these states deliberately:
- Empty: explain what will appear here and offer the first step to get started.
- No results: say so, and offer a way to clear filters.
- Error: say what went wrong in plain words and what the user can do.
- Data freshness: show when the information was last updated, so nobody makes decisions from stale numbers without realising.
A blank panel looks like a bug, and staff who think the system is broken will not return.
8. Testing with the people who built it
Developers and project managers know where everything is, so the screen always seems clear to them. That tells you little about a customer service officer using it at a busy moment.
Before launch, ask two or three real users to complete realistic tasks on a prototype, such as “find the orders that need action today” or “check whether this customer has paid.” Do not explain anything. Watch where they hesitate, what they click first and which words they misread. Even a small round of this tends to reveal problems that a review meeting would not. A UI/UX design process that includes this step costs far less than redesigning after the team has already gone back to spreadsheets.
Concrete takeaways
- List the questions each role asks daily before choosing any chart or card.
- Limit the first screen to what needs attention today, plus a few summary figures.
- Use your team’s own vocabulary for every label, and explain unavoidable terms in place.
- Add a comparison, target or threshold to every key number.
- Place the next action beside every alert and link directly to the relevant record.
- Create a default view per main role instead of one screen for all.
- Design empty, error, no-result and out-of-date states from the start.
- Test with real staff doing real tasks before launch, and again after a few weeks of use.
A dashboard earns its place when staff reach for it first, not when it displays the most data. Get the questions, the language and the next actions right, and the visual polish becomes much easier. If you are planning an internal system or reconsidering one your team avoids, you are welcome to contact Digital Revo to talk through what your staff actually need.
Frequently asked questions
How many items should a dashboard show on its first screen?
There is no magic number, but fewer is almost always better. A useful test is whether a new user can say within a few seconds what needs their attention. If they cannot, move secondary figures to a deeper view or a separate report.
Should we build a custom dashboard or use an off-the-shelf tool?
It depends on how closely your process matches what the tool assumes. Ready-made tools can work well for standard reporting. Custom design makes more sense when staff need to take actions inside the same screen, when roles differ a lot, or when your terminology and workflow are specific to your business. Compare the options against the daily questions your team asks rather than against a feature list.
How do we know if our current dashboard is failing?
Look at behaviour. Are staff keeping parallel spreadsheets, asking colleagues for numbers that are already on screen, or making the same errors repeatedly? Do they ignore alerts? These are signs the design is not matching their work. Ask a few users to show you how they use it, and note where they hesitate.
