Built for the requester, not the user
Most internal dashboards are specified by whoever asked for visibility and used by whoever does the work. Those groups want different things: one wants a picture of everything, the other wants to know what to do next. Serving the first produces something the second ignores.
1. Answer a decision, not a topic
A dashboard titled “Sales overview” has no job. One that answers “which deals need attention today?” has a specific one, and gets opened daily. Start from the recurring decision and show only what changes it — the same discipline as choosing one action per page on a marketing site.
2. Come to them
People do not habitually visit dashboards. The ones that get used push their conclusion into the place work already happens — a message, an email, a queue — and use the dashboard as the detail view when someone wants to dig.
A dashboard nobody opens isn’t an adoption problem. It’s a dashboard that asked the user to remember it exists.
3. Show the exception, not the aggregate
Totals are reassuring and rarely actionable. What changes behaviour is the short list of things outside normal: the stalled orders, the accounts that stopped, the jobs that failed. Lead with those and put the aggregate underneath.
4. Make the numbers trustworthy
One wrong figure ends adoption permanently, because people stop believing all of it. Show what the number counts, when it last refreshed, and what it excludes — particularly if it arrives through an integration nobody owns, which is where quiet data corruption usually starts.
Then watch whether it is opened
Instrument the dashboard itself. If usage falls off after two weeks, the honest conclusion is that it doesn’t support a real decision, and the fix is to talk to the people doing the work rather than to add another chart. Good internal tools are the highest-leverage software most teams neglect — but only the ones that get used.