OpenSRP is a configurable mobile health platform used by frontline health workers, often operating in low-connectivity, low-resource environments.
My Role & Process
OpenSRP is implemented by in-country partners in their own health systems, so the platform had to support a wide range of use cases rather than one fixed workflow. I ran human-centered design sessions with the World Health Organization to ground the work in global health standards, and with in-country health ministries and NGOs such as Last Mile Health in Liberia, mPower in Bangladesh, IRD in Pakistan, and SID in Indonesia, to understand how those standards actually played out on the ground. We have iterated on the tools until they fit how their teams really worked and how health data systems have evolved in the 2010s.
I led the initial product vision and interaction models for the platform, working from the ground up with frontline-worker users rather than designing for them remotely, and designed for the realities of the environment. The primary design challenges were the realities of networks, users, and adoption. Technically, we had to ensure usability in low-connectivity conditions where a typical always-online pattern would fail, which impacted what we could do in the app.
Research started in 2012 as a small pilot project in Karnataka, India. We found outreach nurse midwives carrying stacks of registers and notebooks, which made health data inaccessible to health systems.
After the pilot in India, it was clear a digital system for frontline users had potential. We gathered partners from WHO with ministries and health experts from Pakistan, Indonesia, India, Bangladesh, and Kenya to set a vision for the app. As we designed, we were able to work with these partners to quickly validate solutions with real users in the field.
Because we were bootstrapped, we improved the product, project by project, as it was implemented in local health systems. It was used for solutions ranging from child vaccines, AIDS, and tuberculosis to logistics and refugee medical record tracking. During this time, I had a close eye on OpenSRP projects my company ran, and led my team to coordinate with partners running their own instances. This allowed us to prioritize features by looking at year-out needs.
Design
Skeuomorphism
Early on, many users had never touched a smartphone, so I designed around metaphors from their existing paper practice: a home screen built as a stack of books, since our users carried a literal stack of ledgers to record data. Opening a "book" revealed a tabular ledger, improved with color-coded flags, and medical records were visually modeled on the mother-and-child passport cards field teams already used. As smartphone use and digital literacy grew, I shifted the design language toward patterns people already knew from WhatsApp, Facebook, and YouTube — trading physical-metaphor familiarity for fewer taps and more direct value, once that tradeoff made sense.
Paper registers inspired the layout of the digital register in order to make onboarding easier for new-to-smartphone users.
Digital medical records mimicked the child health cards that mothers carried around.
Overcoming field constraints
Additional improvements were prioritized after watching people use the app on the ground. We saw nurses working in bright sunlight and often had use the app while holding other objects, so the team added large tap areas, high contrast colors, and focused input widgets.
Modular design system
The platform's flexibility came from a component system built directly on top of FHIR health data resources, rather than designing one-off screens for each country. My team, partners, and I collaborated on a shared set of view types any implementation could assemble differently — a landing register list, a profile view, a past-encounters view, maps, charts, and forms — held together by a general style guide and a consistent metaphor: a register of profiles you tap into, forms that collect the data, and a profile view that surfaces it back in whatever way a given health program needed. Flexibility wasn't spread evenly across those views: the landing view and profile view carried the most room to vary, since that's where implementation needs differed most from country to country, while forms and charts stayed closer to a standard pattern.
When a new implementation came in, we worked directly with in-country teams to build mockups from our design system's templates, which engineers then built out — so a person with design judgment was in the room for every new country, not just engineering assembling components on its own.
The design system is available in the Figma library.
Outcome
The platform reached 90+ implementations globally, recording 1.6M services and enrolling 235K patients across 3,500 frontline users. That reach came from building with local partners rather than shipping one fixed design to everyone. Our flexible technology and design gave us options to tailor implementations for each health system, shaped by the needs and constraints unique to it.
Countries where OpenSRP had an implementation or pilot
In 2023, we collaborated with Google on Open Health Stack and rebuilt OpenSRP from the ground up to be FHIR native. This modernized the app to more easily work with multi-stakeholder health systems and databases.
Google-produced looking at OpenSRP and Open Health Stack
Reflection
Ten years on OpenSRP taught me two things. First, a product like this only works if design, policy, and engineering solve the problem together. The tool supported a job far larger than what the app itself did, so understanding where it fit into that bigger picture was what let us set the right goals and constraints. Second, getting the launch right matters as much as getting the product right: buy-in from managers, a support plan, training, and providing incentives to reward users and beneficiaries were as much a part of the design work as the app UI.
Early OpenSRP partners meeting in Dhaka, Bangladesh
Role: Design Director and IC