Writing · Working notes

Dashboard delivery isn’t dashboard utilization

Most evaluations end at the moment the report is sent. The work I’m most often asked to do begins about three weeks later.

Apr 29, 2026 ~5 min read

A coalition director once told me, almost as an aside, that her team had four dashboards built by four different evaluators in five years and that none of them got opened more than once a quarter. She said this with no bitterness. The dashboards were fine. They had clean visualizations and reasonable indicators. They had simply, in the most practical sense, not become part of how the coalition made decisions.

That sentence has stayed with me. It is the cleanest description of a problem evaluators rarely name out loud: dashboard delivery is not dashboard utilization. The two are different operations. The first is what most evaluation contracts pay for. The second is what most programs actually need.

The hand-off, and what falls in the gap

Most evaluation engagements are scoped to deliver a product. A report. A logic model. A dashboard. A theory of change on a single page. The product is what the contract describes; the product is what the funder reviews; the product is what the invoice is tied to.

The problem is that the product is not the change. The change is downstream of the product, in the meeting where the program officer asks staff what the data is showing, in the budget conversation where the dashboard either shapes a decision or doesn’t, in the moment a frontline worker realizes a number on a screen is describing something they have been seeing in their own work for months. None of those moments live inside the deliverable. All of them depend on whether the deliverable was designed for them.

The hardest part of public health data, in my experience, is not the analysis. It is getting decision-makers to trust, interpret, and act on what the data reveals. The analysis is what an MPH program teaches you. The trust, interpretation, and action are what the evaluator earns or fails to earn during the engagement — mostly through small choices that don’t make it into the methods section.

The product is not the change. The change is downstream of the product, in the meeting where the program officer asks staff what the data is showing.

What the facilitation layer actually does

What I have started calling, somewhat inelegantly, the facilitation layer is the set of practices that sit between a delivered product and a usable one. It is not a separate methodology. It is a set of habits I try to bake into every engagement, and which I have come to think are the difference between an evaluation that changes a program and one that produces a beautifully designed PDF.

A short, partial list of what the facilitation layer does:

It treats the dashboard handoff as the beginning of the engagement, not the end. Every dashboard I help build comes with at least two scheduled walkthroughs — one with leadership, one with the staff who will use it — in which we read the dashboard together, in real time, while looking at last week’s actual numbers. The walkthrough is where I find out what the dashboard is missing. The walkthrough is also where staff find out that the dashboard is for them.

It builds reading capacity in stages. The first quarterly review with a coalition is rarely about the data. It is about giving everyone in the room a shared vocabulary for the data — what counts as a baseline, what counts as a meaningful change, what to do when an indicator moves in the wrong direction. The data review starts about six months in. By then the room has the equipment to read what it’s seeing.

It makes the invisible visible without making the invisible flat. There are things a community knows about itself that a dashboard cannot represent. The facilitation layer holds a place for that knowledge in the same room as the indicators, so that when the two disagree the conversation gets richer rather than thinner. The numbers do not get the last word. Neither do the stories. Both get to participate in the interpretation.

A short example, in concrete numbers

In Central Providence, the shared measurement system I helped architect spanned more than sixty organizations and tracked fourteen indicators across six health equity domains. The dashboard, by itself, was a useful artifact. The Data Academy that ran alongside it — co-designed with Brown University, conducted in English and Spanish, structured around the questions resident leaders were already asking — was the part that made the dashboard hold. Without the Academy, the dashboard would have been, at best, a quarterly compliance ritual. With it, partner organizations began bringing their own data to the meetings and arguing back.

That argument-back was the outcome. The dashboard was the occasion for the argument. The Data Academy was the bridge between the two.

What I have stopped pretending is optional

For a long time I thought of the facilitation layer as a value-add — the kind of thing a thoughtful evaluator brings to an engagement when there is room in the budget. I no longer think this is honest. The dashboard without the walkthrough produces nothing the program will remember in six months. The report without the staff briefing produces nothing the funder will reference at the next planning cycle.

If I cannot get the facilitation layer into the scope of work, I would rather not take the engagement. The deliverable, on its own, is not the work. The deliverable is the artifact that records the work. Dashboard delivery and dashboard utilization are different operations, and an evaluator who is paid for the first but expected to produce the second is being asked to do the harder job for free. I have done that job for free, more than once. I would rather, now, name it in the contract.