Building dashboards people check without being told to

Most internal dashboards get built, demoed once, and then quietly ignored — the ones that actually get used regularly have specific, identifiable design characteristics.

Why most dashboards fail to become habits

We audit a lot of client dashboard usage (via tool-level view analytics, when available) and the pattern is consistent: dashboards built to show everything technically available get used once or twice, then abandoned. The dashboards that get checked daily, without anyone being reminded to, share a common trait — they answer one specific, recurring question the viewer actually needs answered regularly, rather than presenting comprehensive data for open-ended exploration.

The design principle: one dashboard, one job

Rather than building a comprehensive "everything about sales" dashboard, we design around specific recurring decisions: a dashboard that answers "which accounts need attention this week" for a sales manager, versus a separate one answering "how did this campaign perform" for marketing. Each has a narrow, specific purpose tied to an actual recurring workflow, rather than being a general-purpose data exploration tool that requires the viewer to know what they're looking for.

The technical details that determine whether it actually gets checked

Load time matters more than most teams assume — a dashboard that takes 8+ seconds to load trains people to avoid opening it, especially for something meant to be a quick daily check. We optimize underlying queries and use appropriate caching/pre-aggregation rather than running expensive live queries on every page load. Push over pull also matters: for the most time-sensitive metrics, we build alerting or a daily digest that pushes the key numbers to Slack or email rather than relying entirely on someone remembering to open a dashboard — the habit of checking builds faster when the information sometimes comes to you.

A concrete example

A subscription business had a comprehensive analytics dashboard covering churn, revenue, acquisition, and engagement metrics across roughly 40 different charts — built by a previous consultant, technically impressive, and — by the client's own account — opened by almost nobody after the initial rollout. We interviewed the actual stakeholders about what decisions they made weekly and rebuilt around three narrow, specific dashboards: a customer success view answering "which accounts show churn risk signals this week," a finance view answering "are we tracking to this month's revenue target," and a growth view answering "which acquisition channel is performing best right now." Each loads in under 2 seconds and answers exactly one recurring question. Six months post-launch, usage analytics showed the customer success dashboard being opened by its target users an average of 4.2 times a week — a behavior that simply hadn't existed with the previous comprehensive dashboard.

Where teams get stuck

The instinct to add "just one more useful chart" is strong, and it's how comprehensive-but-unused dashboards get built in the first place. We push back on scope creep during design — if a metric doesn't map to a specific recurring decision someone makes, it doesn't belong on that dashboard, even if it's technically interesting.

How Ndakum approaches it

Dashboard design in our Data Engineering & AI work starts with interviewing the actual users about their recurring decisions, not with an inventory of available data.