Policy maker persona

People who hold formal authority to set policy and allocate public resources, especially within LMIC governments.

Who they are

Ministry of Health officials, regional health authorities, and national program managers making high-stakes decisions about strategy, budgets, and regulations.

IDM doesn’t often interact directly with policy makers. Instead, policy influencers use the output of IDM models to make policy recommendations to policy makers.

What they do

Approve or reject policies, define national plans and guidelines, allocate budgets, and take responsibility for outcomes; they rely on evidence from model builders/extenders/users and policy influencers but are accountable for final decisions.

Skills/tools

Strong domain and systems expertise, but limited time and often limited tolerance for technical detail; prefer synthesized evidence—dashboards, short briefs, and clear options with trade-offs and uncertainty explained.

Key needs

Locally relevant, validated models; interpretable outputs mapped to policy levers and budget lines; support in understanding implications, risks, and equity impacts of different choices.

Decision-making context

Policy makers operate under high public accountability — decisions affect national programs and budgets, and mistakes are visible. They work within annual or multi-year planning cycles, so modeling evidence needs to arrive at the right moment to have influence. By the time output reaches them, it has been filtered and interpreted by policy influencers and technical advisors; policy makers rarely interact with models or modelers directly.

Key decision constraints include political feasibility, available budget, existing program commitments, and equity considerations across populations. A model showing an intervention works in theory may still be rejected if it isn’t implementable within these constraints. In LMIC contexts, policy makers may also face donor-driven priorities and pressure to align with international guidelines even when local conditions differ.

For code: Design outputs and dashboards to support comparison of options rather than presenting single results. Policy makers need to see trade-offs clearly — cost, feasibility, equity impact — not just efficacy. Outputs should map to recognizable policy levers (coverage targets, budget lines, program timelines) rather than model parameters. Uncertainty should be communicated in terms of decision risk, not confidence intervals.

For docs: Since policy makers are unlikely to read software documentation, writing that targets them belongs in dashboards, briefs, and the idmod.org website rather than technical docs. When writing for intermediary audiences (policy influencers, model users) who will communicate to policy makers, emphasize how to translate outputs into decision-relevant language and how to convey model limitations without undermining confidence in the results.

Targeted content

It’s important to address policy maker needs primarily in dashboards and in policy recommendations. They will likely not interact directly with software documentation. On the idmod.org website, the focus should be on conveying that our models can be trusted and have been applied to policy decisions in real-world contexts.

In software documentation specifically, this means at most one or two sentences on the landing page or top of the README acknowledging real-world policy relevance — not a dedicated section, case study, or reframed landing page.