Every health department I’ve worked in has had at least one dashboard nobody looks at anymore. It was probably impressive when it launched — clean charts, live data feeds, maybe even a leadership demo. Six months later, it’s a tab nobody opens.
This isn’t a technology problem. It’s a design problem, and it’s one of the most common ways public health data teams waste real effort.
The dashboard isn’t the deliverable
The most common mistake is treating the dashboard itself as the goal. A KPI framework’s job isn’t to display data — it’s to change a decision. If a metric doesn’t map to something a program manager, a bureau director, or a field team will actually do differently, it shouldn’t be on the dashboard, no matter how easy it is to visualize.
I’ve built dashboards for immunization coverage tracking, COVID-19 response operations, and vaccine data quality programs, and the ones that survived past the first quarter had one thing in common: someone had already decided, before a single chart was built, what action each number was supposed to trigger. Coverage drops below a threshold in a ZIP code → outreach gets prioritized there. Data entry error rate climbs → retraining gets scheduled. If that “if this, then that” doesn’t exist, the metric is decoration.
Good governance is invisible until it isn’t
The second failure point is data governance — and it’s the part that gets skipped because it’s slow and unglamorous. Every dashboard is only as trustworthy as the process that feeds it. Standardized definitions. Clear ownership of who validates what. Documented protocols for how corrections get made.
Skip this, and you get the failure mode every data team eventually hits: two people pull “the same” metric and get different numbers, and now nobody trusts the dashboard — including the people who built it. I’ve seen data quality initiatives produce real, measurable improvements in accuracy simply by standardizing error-detection protocols and defining ownership clearly. That work is slower than building a chart, but it’s what makes the chart mean something.
Build for the team that has ten minutes, not the one that has two hours
A dashboard designed by an analyst, for an analyst, tends to show everything. A dashboard that survives contact with an operational team shows only what changes a decision — and puts it where a director glancing at it during a 15-minute morning huddle can act on it immediately.
This is why the most useful KPI frameworks I’ve built didn’t start with “what data do we have.” They started with “what decision does this team make every week, and what’s the smallest set of numbers that improves it.” Everything else — the visualization tool, the refresh cadence, the color scheme — is implementation detail that comes after that question is answered.
The real work is upstream
If there’s one thing I’d tell a program standing up a new data initiative, it’s this: the dashboard is the easy 20%. The hard 80% is agreeing on definitions, assigning data ownership, and designing the escalation path before you write a single query. Programs that invest there end up with tools people actually open. Programs that skip it end up with a very polished chart nobody trusts.
Data can absolutely drive better public health outcomes. But only if the infrastructure underneath it is built to be trusted first, and impressive second.