Key points
- Monitoring products sit between data entered by many people and decisions taken by a few. Designing them well is a discipline in itself, not a matter of adding charts.
- WHO's digital health classification describes four groups of primary users. In many health systems, new tools join existing apps and reporting processes, so good design starts from each user's decision, information and working day.
- Paper, review meetings and printed reports are part of how the system works. Products should fit that process, and should expect to keep changing after launch.
Designing a product is a discipline in itself. Designing a product that helps a health system monitor itself is a particular kind of that discipline, and in my experience it is often underestimated.
A monitoring product sits between two groups of people. On one side are the many people who generate the data, such as frontline workers recording visits, facility staff entering stock, data entry operators compiling monthly reports. On the other are the people who use it to decide something, such as where to send supervisors, which facility needs supplies, which district to discuss at the next review. The product has to be trusted by both. It has to be timely enough to act on and stable enough to compare over time. And because what gets measured tends to get attention, it quietly shapes behaviour across the system.
Unlike most consumer apps, its users rarely choose it. They are asked to use it as part of their job. That makes design more important, not less.
I have spent the last few years designing digital products for public health, from facility assessment apps and state dashboards to decision-support prototypes, including support for AI-assisted prototyping. This piece sets out how I now think about that work, including who the users are, a few principles that have held up, and two lessons that took me longer to learn.
A crowded landscape
WHO’s Classification of digital interventions, services and applications in health organises digital health around who the primary user is. It describes four groups, persons (members of the public, including patients and caregivers), healthcare providers, health management and support personnel (the people who administer and oversee the health system, from supply chains to finance and human resources), and data services, the cross-cutting functions that collect, manage and use data.
It is a useful lens because it reminds you how crowded the landscape can be. In many health systems, users already work across several applications, portals and reporting channels. A frontline worker may record visits on one application, check a beneficiary list on another and send reports through a third. In other settings, paper records and shared devices remain important. Either way, a new product does not arrive in empty space. It arrives into an existing way of working and a working day that is already full.
So design starts from the people, not from the data. For each user, I try to write one sentence: When [moment], [user] needs to decide [decision], and today they rely on [current source]. If I cannot write that sentence, I do not yet know enough to design.
Here is a simplified map for a programme like maternal health or urban primary care, using WHO’s user groups. It is my own application of the classification, and the rows are starting points drawn from common programme workflows, to be tested with users in each setting. Each row is effectively a different product, even when they share the same data.
| WHO user group | User | Typical decision | Time and setting | What they need |
|---|---|---|---|---|
| Health management and support personnel | National and state leadership | Where to put money and attention next quarter | Review meetings, minutes per state or district | A few trends, outliers and comparisons, and trust in the numbers |
| District programme managers | Which facilities and blocks need a visit, which supplies to move | Daily, often on a phone between field visits | Exceptions, meaning what is off track today, with names and numbers to call | |
| Pharmacists and supply-chain staff | What to order, what to redistribute, what is expiring | Weekly ordering cycle | Stock levels, consumption trends, stock-out warnings | |
| Healthcare providers | Medical officers | Who among today’s patients needs what care | Between patients, in seconds | The patient’s history and risk at a glance |
| ANMs (auxiliary nurse midwives) | Which women and children to see this week | Field days, low connectivity | A due list of names, what is due and what is overdue | |
| ASHAs (community health workers) | Which households to visit and what to tell them | Village visits, local language | Simple lists, pictures and voice, reminders, and acknowledgement of work done | |
| Data services | Data entry operators and data managers | Getting this month’s reporting done correctly | Month-end, desktop | Fewer fields, validation at entry, no double entry |
Look at the last column. In my experience, many of these users need an actionable list more often than a summary chart, such as people to see, facilities to call or stock to move. WHO’s classification even names this function for providers, identifying persons in need of services (2.7.1). Others need trends and comparisons. Charts and lists are complementary views of the same information, each suited to different decisions.
Principles that have held up
There is good writing on dashboard design, and I would rather build on it than repeat it. Stephen Few’s work on information dashboards remains a sound guide to visual clarity. More recently, Benjamin Bach and colleagues reviewed 144 dashboards and described recurring design patterns, grouped by what a dashboard contains and how it is composed, including its layout, use of screen space, structure across pages, interactions and colour. They also describe dashboards as coming in different genres, and show that design is largely about trade-offs, such as how much information to fit into limited space. Taken together, this supports a practical point. A state review dashboard and a frontline due list serve different purposes, and a single interface may not support every decision well.
With that in mind, these are the principles I return to. They come from my own experience and the reading above, not from a formal study.
- Give every screen a clear purpose. If very different users need very different things, separate views for each role usually work better than one screen for all. The same platform and data can sit underneath.
- Show exceptions, not everything. A district manager does not need 200 green indicators. They need the five red ones, with the facility name and the phone number.
- Design for the real device and connection. A frontline worker’s phone and network are not a state office laptop. Where connectivity is patchy, screens are small and users work in a local language, the product needs offline use, simple layouts and the right language.
- Give something back to the people who enter the data. Frontline workers often enter much of the data without seeing much come back. Returning useful information, such as next week’s due list, can make data entry more meaningful and help people spot mistakes. In my experience that can help data quality, though it is worth checking in each programme.
- Keep the definition one tap away. Every number should say what it counts, from which source, and as of when. Trends can mislead when a definition, denominator or reporting completeness changes, so it helps to show that too. Many disagreements in review meetings turn out to be about definitions, not performance.
- Prototype with real users before building. A clickable prototype shown to a few district managers in their own offices can reveal problems and wrong assumptions early. Watch where they hesitate.
- Measure more than the launch. Launching a product is not success. Depending on its purpose, useful measures include whether people keep using it, whether data quality and reporting burden improve, and whether follow-up actions are completed on time.
The most important design work often happens between users rather than within one screen. A high-risk pregnancy flagged by an ANM needs to appear on the medical officer’s list at the next visit, and on the district manager’s exception list if a follow-up is missed. A product can serve each user well and still lose the woman at the handoff. So I map the journey first, from first contact to safe delivery and beyond, and let the products follow from it. Digital visibility is only one part of that pathway. A flag on a list does not mean care was received. Clear responsibility for follow-up, clinical assessment and the capacity to provide care still matter most, and a product should support clinical judgement, not replace it.
The printed copy
The lesson that changed my thinking most came from a request I did not expect.
We had built a set of charts and dashboards we were genuinely proud of. They were interactive, filterable and carefully designed. We presented them, they were well received, and then came the request. Could we please send a printed copy?
My first reaction was disappointment. It took me a while to understand that the request was not a rejection of the product. It was information about how the work actually gets done. Many review meetings happen around printed tables. Officers annotate them, mark districts for follow-up, sign them and carry them into the field. A printed report needs no login, no connection and no charged battery. It can be passed across a table, and it leaves a record of what was discussed and decided. For an experienced officer running a review, paper is not a step backwards. It is a working tool, chosen for good reasons.
That changed how I design. I stopped trying to replace the existing process and started designing for it. A clean print view became a feature, not an afterthought. Tables were laid out to fit a page and to be read in a meeting. The most important numbers went where a pen would naturally mark them. The digital product and the paper report became two faces of the same thing.
The broader lesson is respect for the whole process. A health system has ways of working that have evolved for reasons, often good ones. Products are more likely to be used when they take those ways of working into account. Where a workflow does need to change, the change works best when it is designed with users and supported with training and clear responsibility.
A product is never finished
The second lesson is about time. In my experience, a monitoring product in a public programme keeps changing after launch. New indicators arrive with new schemes or guidelines. A review cycle shifts its focus. A feature that seemed essential at launch turns out to be opened by nobody, and something nobody asked for becomes the most-used screen.
So I now treat change as part of the design. That means building features so they can be added and removed without disrupting everything else, keeping indicator definitions versioned so that comparisons over time stay honest, and watching usage so that unused features can be retired rather than left to clutter the screen. Removing a feature is as much a design decision as adding one.
Designing for the people in the system
A monitoring product is most useful when people across a health system, from the ASHA planning her week to the officer chairing a review, can see what they need in order to act, in a form that fits how they work. That takes more than good charts. It takes an understanding of users, workflows, data quality and the handoffs through which information becomes action.
Views are my own.
Sources
- WHO, Classification of digital interventions, services and applications in health, 2nd edition (2023)
- Bach B., Freeman E., Abdul-Rahman A., Turkay C., Khan S., Fan Y., Chen M. Dashboard Design Patterns. IEEE Transactions on Visualization and Computer Graphics (IEEE VIS 2022). dashboarddesignpatterns.github.io
- Few S. Information Dashboard Design: Displaying Data for At-a-Glance Monitoring. Analytics Press, 2nd edition, 2013.