Every health department I’ve worked in has had at least one dashboard nobody looks at anymore. It probably looked great at launch, with clean charts, live data feeds, maybe a demo for leadership. Six months later it’s a browser tab nobody opens.
The technology is rarely the problem. The design is, and it’s one of the most common ways public health data teams waste effort.
The dashboard is not the goal
The most common mistake is treating the dashboard as the deliverable. A KPI framework exists to change decisions. If a metric doesn’t connect to something a program manager, bureau director, or field team will do differently, it doesn’t belong on the dashboard, however easy it is to chart.
I’ve built dashboards for immunization coverage, COVID-19 response operations, and vaccine data quality. The ones still in use after the first quarter had one thing in common. Before anyone built a chart, someone had decided what action each number should trigger. If coverage drops below a threshold in a ZIP code, outreach moves there. If the data entry error rate climbs, retraining gets scheduled. Without that link, a metric is decoration.
Governance comes first
The second place dashboards fail is data governance, which gets skipped because it’s slow and dull. A dashboard is only as trustworthy as the process that feeds it. That means standard definitions, clear ownership of who validates what, and written rules for how corrections are made.
Skip that, and you hit the failure every data team eventually meets: two people pull “the same” metric, get different numbers, and from then on nobody trusts the dashboard, including the people who built it. I’ve seen data quality projects produce measurable gains in accuracy just by standardizing error checks and naming owners. It’s slower than building a chart, but it’s what makes the chart worth reading.
Design for ten minutes, not two hours
A dashboard built by an analyst for analysts tends to show everything. One that an operations team will actually use shows only what changes a decision, placed so a director can act on it during a 15-minute morning huddle.
So 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 is the smallest set of numbers that would improve it?” The tool, the refresh schedule, and the colors all come after that.
Start upstream
My advice to any program starting a new data project: the dashboard is the easy part. The hard part is agreeing on definitions, assigning data owners, and deciding how problems get escalated, before anyone writes a query. Programs that do that work end up with tools people open. Programs that skip it end up with a polished chart nobody trusts.
Data can improve public health decisions, but people have to trust it before they will use it.