Key takeaways
- Frame the request as a question someone asks regularly — that framing determines what must be visible without interaction.
- Show three things, not thirty. A screen that answers nothing costs attention and returns nothing.
- Design for the worst day: a phone, a stressed user, and someone who did not build the tool.
We build a lot of internal tools. The ones that survive tend to share a small number of characteristics, and they are mostly about restraint.
Start From the Actual Question
Teams request a dashboard because they want information. But the request that succeeds is framed as a question someone asks regularly. That framing determines the layout, because it tells you what must be visible without interaction and what can wait.
Show Three Things, Not Thirty
- Every additional metric dilutes the ones that matter
- A screen that answers nothing is worse than no screen — it costs attention and returns nothing
- Depth should be available, but not on the first view
- Reference figures change slowly and belong elsewhere
Design for the Worst Day
Most people will use this tool on a phone, while stressed, while logged in as a different user to the one who built it. Empty states, long labels, partial data and permission errors are part of the design, not edge cases to handle later.
If a dashboard needs onboarding, it needs fewer numbers. The best internal tools are obvious enough that nobody reads the documentation.
Make It Feel Fast
Perceived performance is what people judge. Filters that reset predictably, tables that hold their scroll position and instant feedback on actions matter more to daily adoption than the underlying query time — although of course both should be good.
Frequently asked questions
How do you design a dashboard people actually use?
Start from the specific question a person asks regularly, show the three or four numbers that answer it without interaction, and put everything else behind a deliberate click. Design for the worst conditions — small screen, partial data, a user without full permissions — and make perceived speed excellent even when the underlying query is not.
How many metrics should a business dashboard display?
As few as possible. Three to five primary metrics per view is a useful ceiling, because every additional metric dilutes the ones that matter. Depth is fine, but it should sit behind a deliberate interaction rather than sharing the first view with the headline numbers.
Why do internal tools get abandoned?
Usually because they were designed around available data rather than around a recurring question. When a dashboard shows everything equally, people cannot tell what to act on and stop opening it. The reporting then happens manually, in spreadsheets, alongside the tool rather than through it.
Should business dashboards be mobile friendly?
Yes, because most people will check one on a phone while away from their desk, often while stressed. That means designing for partial data, long labels, permission errors and empty states from the start rather than treating them as edge cases discovered after launch.
Written by Immortify Digital, product design team at Immortify Digital.
The designers who turn operational requirements into interfaces our clients' teams use every day.
