MalaDost — Malaria Monitor
A disease-tracking app built not for hospitals, but for the people between patients and hospitals.
Client
AIIMS Hyderabad & ICMR
Scope
Branding, UX/UI, Full-stack Android
Impact
60% reduction in manual data entry
Background & Context
The healthcare system had data problems. The communities had awareness problems. The field workers had workflow problems. One app had to solve all three — without asking any of them to do more work than before.
India's malaria problem isn't a knowledge gap. Everyone in an endemic zone knows what malaria is. The gap is between a symptom appearing in a village and that information reaching a health system that can act on it — a gap measured not in distance, but in paper forms, low-literacy barriers, and field workers carrying clipboards through monsoon season.
AIIMS Hyderabad and ICMR came to IDC with a mandate that was deceptively simple: build a mobile app to help track malaria in high-risk communities. What that actually meant — once we understood who would be using it — was something far more complicated. The users weren't tech-forward urban patients. They were ASHA workers in remote districts, primary care clinicians juggling caseloads, NGOs coordinating across regions with no shared data infrastructure, and patients with limited digital literacy trying to understand their own risk.
Research & Insights
The core insight was this: the people most important to malaria control — ASHA workers, community health volunteers — were drowning in paperwork that never reached anyone in time to matter. By the time a cluster of cases was recorded, consolidated, and escalated, the window for early intervention had closed.
We also found that multilingual access wasn't a feature request — it was a fundamental prerequisite. A form a field worker can't read is a form that won't get filled. An alert a patient can't understand is an alert that won't change behavior. The interface had to earn trust before it could transfer information.
The Design Problem
Three user types. Three entirely different mental models of what this app was for. For the patient, it needed to answer one question: am I at risk, and what do I do? For the ASHA worker, it needed to replace a paper trail with something faster and more reliable. For the public health system, it needed to surface patterns — real-time, geospatially — not individual reports.
Designing for all three without letting any one group's needs collapse the experience for the other two was the central tension. A clinical dashboard optimized for a district health officer would be completely alienating for a 50-year-old field worker logging a case in poor network coverage. An over-simplified citizen-facing UI would strip out exactly the structured data the system needed to build its risk maps.
"The interface had to be as usable in a village with patchy 2G as it was in a research office. Simplicity wasn't a design preference — it was a functional requirement."
How we solved it
We built role-based flows — patient, ASHA, clinician — each with its own entry point and task logic. An ASHA worker signing up sees a different onboarding path than a patient, and a different dashboard entirely. This wasn't just UX segmentation; it was the only way to make structured data collection feel like a natural workflow rather than a bureaucratic burden.
For the patient-facing screens, we stripped language to its minimum — iconography-heavy layouts, multilingual toggles prominent at sign-up, AI-driven symptom check flows that returned plain-language guidance without requiring a clinician in the loop for routine triage. Healthcare connectivity features — nearest diagnostic centers, pharmacies, emergency contacts — were designed as one-tap actions, not buried navigation.
The geospatial risk layer was built using GIS and live public health data feeds, rendering malaria heatmaps at the district and block level. This gave health officers something they'd never had: a live picture of where cases were clustering before an outbreak was formally declared.
The approval flow between ASHA submissions and clinical review was built as a lightweight asynchronous queue — cases submitted offline would sync when connectivity returned, flagging urgency levels so clinicians prioritized without manually reading every entry.
Result
60%
reduction in manual data entry across patients, ASHA workers, and NGOs — bringing real-time disease tracking to the frontline for the first time.
