Educate Girls
Educate Girls
Project Pragati
Project Pragati
A "mentor/coach network" and a technology platform that has been deployed at a population level scale in India to enable permanently at risk adolescent girls and young women to achieve 10th grade certification.
A "mentor/coach network" and a technology platform that has been deployed at a population level scale in India to enable permanently at risk adolescent girls and young women to achieve 10th grade certification.
My Role
Lead UX Researcher & Designer
My Role
Lead UX Researcher & Designer
Overview of my Contributions
Overview of my Contributions
As the lead UX researcher and designer on the project, I was responsible for making design decisions that worked across three very different user groups, from NGO administrators in offices to volunteers in villages with patchy internet. A key reframe our team made early on was identifying the root problem as data integrity rather than just data visibility, which led to a structural solution that no amount of UI polish could have achieved. The final product gave Educate Girls reliable enrolment data at population scale for the first time, with user testing confirming an 80% task completion rate and every participant said they could use the app independently without any training or guidance.
As the lead UX researcher and designer on the project, I was responsible for making design decisions that worked across three very different user groups, from NGO administrators in offices to volunteers in villages with patchy internet. A key reframe our team made early on was identifying the root problem as data integrity rather than just data visibility, which led to a structural solution that no amount of UI polish could have achieved. The final product gave Educate Girls reliable enrolment data at population scale for the first time, with user testing confirming an 80% task completion rate and every participant said they could use the app independently without any training or guidance.
Methodology
Methodology
Field Research (camp visits + interviews)
User Ecosystem Mapping
Information Architecture
Paper Wireframing
Prototyping (Lo-fi to Hi-fi)
Moderated User Testing
Design System Development
Field Research (camp visits + interviews)
User Ecosystem Mapping
Information Architecture
Paper Wireframing
Prototyping (Lo-fi to Hi-fi)
Moderated User Testing
Design System Development
01 Context
A program built on human trust, trying to scale
A program built on human trust, trying to scale
In 2021, Educate Girls launched Project Pragati, a "second chance" initiative to help permanently at-risk adolescent girls and young women achieve their 10th grade certification. The model was compelling: recruit and train local community members (Preraks or Facilitators) to run teaching camps, supervised by Implementation Partners, all overseen by the NGO's program team.
In 2021, Educate Girls launched Project Pragati, a "second chance" initiative to help permanently at-risk adolescent girls and young women achieve their 10th grade certification. The model was compelling: recruit and train local community members (Preraks or Facilitators) to run teaching camps, supervised by Implementation Partners, all overseen by the NGO's program team.
Implementation Partner
Duplicate Data
Redundant Tracking
Preraks
Manual Work
Outdated Tools
AG Learner
Offline
Limited Resources
Program Owner
Scattered data
No Reliable Oversight
The network was growing. But growth was exposing a critical structural weakness:
The network was growing. But growth was exposing a critical structural weakness:
"Nothing today helps the NGO maintain visibility and gives access to reliable data. Scattered information, lack of local context, and redundancy are rampant - obstructing teaching camps and affecting administration."
"Nothing today helps the NGO maintain visibility and gives access to reliable data. Scattered information, lack of local context, and redundancy are rampant - obstructing teaching camps and affecting administration."
Solution and My Brief
Design a technology platform; a tool for field volunteers and a management dashboard for program administrators, that could be deployed at population scale across rural India for reliable oversight.
Design a technology platform; a tool for field volunteers and a management dashboard for program administrators, that could be deployed at population scale across rural India for reliable oversight.
Implementation Partner
Duplicate Data
Redundant Tracking
Preraks
Manual Work
Outdated Tools
AG Learner
Offline
Limited Resources
Program Owner
Scattered data
No Reliable Oversight
02 Research & Discovery
Going to the field before opening Figma
Going to the field before opening Figma
Rather than starting with wireframes, I prioritised understanding the ecosystem in its real environment. I visited 6–7 camps in rural Rajasthan, conducting group and individual interviews across all the user types, as well as observing AG learners in camp settings.
Rather than starting with wireframes, I prioritised understanding the ecosystem in its real environment. I visited 6–7 camps in rural Rajasthan, conducting group and individual interviews across all the user types, as well as observing AG learners in camp settings.
What I was looking for was not just a feature list, but the mental models, constraints, and trust dynamics that would determine whether a digital tool would actually get used in the field.
What I was looking for was not just a feature list, but the mental models, constraints, and trust dynamics that would determine whether a digital tool would actually get used in the field.
Camp Environment and Infrastructure
Camp Environment and Infrastructure
Program Owner
No single source of truth
Data was consolidated manually from multiple IPs, with no standard format. Decisions about resource allocation were made on intuition, not evidence.
Implementation Partner
Redundancy without knowing it
IPs sometimes trained and tracked the same girls as neighbouring IPs through preraks, wasting resources and inflating enrolment numbers invisibly.
Prerak (Volunteer)
Door-to-door, pen and paper
Preraks recruited learners manually and kept handwritten attendance. They had genuine motivation but no tools to match it.
AG Learner
Offline, and resourceful
Learners had limited smartphone access. Any system had to work for them, not require them to directly engage with technology.
Decision Driver
Decision Driver
Early research made clear that the biggest risk was not a bad UI; it was designing for the wrong user or the wrong environment. Preraks were operating in areas with patchy internet.
The tool had to work offline-first, on low-end Android devices,
and not assume digital literacy.
Early research made clear that the biggest risk was not a bad UI; it was designing for the wrong user or the wrong environment. Preraks were operating in areas with patchy internet.
The tool had to work offline-first, on low-end Android devices,
and not assume digital literacy.
Program Owner
No single source of truth
Data was consolidated manually from multiple IPs, with no standard format. Decisions about resource allocation were made on intuition, not evidence.
Implementation Partner
Redundancy without knowing it
IPs sometimes trained and tracked the same girls as neighbouring IPs through preraks, wasting resources and inflating enrolment numbers invisibly.
Prerak (Volunteer)
Door-to-door, pen and paper
Preraks recruited learners manually and kept handwritten attendance. They had genuine motivation but no tools to match it.
AG Learner
Offline, and resourceful
Learners had limited smartphone access. Any system had to work for them, not require them to directly engage with technology.
03 Problem Framing
The real problem wasn't missing data.
It was duplicated data.
The real problem wasn't missing data.
It was duplicated data.
After synthesising field research, a specific structural issue surfaced as the most critical: the same girl could be enrolled multiple times by different Preraks or IPs, creating phantom data that made the program look more successful than it was. Without a unique identifier per learner, deduplication was
impossible.
After synthesising field research, a specific structural issue surfaced as the most critical: the same girl could be enrolled multiple times by different Preraks or IPs, creating phantom data that made the program look more successful than it was. Without a unique identifier per learner, deduplication was
impossible.
Different volunteers could register the same learner under different spellings, with no cross-checking; making programme data meaninglessly inflated.
Different volunteers could register the same learner under different spellings, with no cross-checking; making programme data meaninglessly inflated.
The Decision
Aadhaar numbers as unique identifiers
Aadhaar numbers as unique identifiers
The Problem
Multiple enrolments, no way to deduplicate
Multiple enrolments, no way to deduplicate
Every Indian citizen has an Aadhaar ID. Using it
as the system's primary key meant no learner
could ever be double-enrolled, regardless of
who added her.
Reframed Design Problem
Reframed Design Problem
How might we build a platform that maintains data integrity across a fragmented, low-connectivity, multi-stakeholder operation; without adding friction that would cause volunteers to abandon the tool?
How might we build a platform that maintains data integrity across a fragmented, low-connectivity, multi-stakeholder operation; without adding friction that would cause volunteers to abandon the tool?
04 Information Architecture
Three IAs.
One mental model.
Three IAs.
One mental model.
The program structure involved three distinct user roles with very different workflows. Rather than designing a single app with role-based views, I mapped three separate information architectures; ensuring data entered by a Prerak in the field would flow correctly up to the Program Owner's dashboard, without any user needing to understand the full system.
The program structure involved three distinct user roles with very different workflows. Rather than designing a single app with role-based views, I mapped three separate information architectures; ensuring data entered by a Prerak in the field would flow correctly up to the Program Owner's dashboard, without any user needing to understand the full system.
1
Program Owner → strategic oversight
Highest-level view: targets, cross-programme analytics, and IP management. Designed as a desktop dashboard for data-heavy decision making.
2
Implementation Partners → regional management
Prerak pipeline, camp oversight, and learner distribution across blocks — a middle layer that surfaces what each IP needs without full programme complexity.
3
Preraks → field-level mobile app
Simplified, offline-capable, centred entirely on camp setup, learner enrolment, and attendance. Everything non-essential was removed.
Trade-off decision
Trade-off decision
A single multi-role app would have been easier to maintain, but risked exposing complexity to Preraks who needed a laser-focused tool. Scope isolation was a feature, not a constraint.
A single multi-role app would have been easier to maintain, but risked exposing complexity to Preraks who needed a laser-focused tool. Scope isolation was a feature, not a constraint.
3
Preraks → field-level mobile app
Simplified, offline-capable, centred entirely on camp setup, learner enrolment, and attendance. Everything non-essential was removed.
2
Implementation Partners → regional management
Prerak pipeline, camp oversight, and learner distribution across blocks — a middle layer that surfaces what each IP needs without full programme complexity.
1
Program Owner → strategic oversight
Highest-level view: targets, cross-programme analytics, and IP management. Designed as a desktop dashboard for data-heavy decision making.
3
Preraks → field-level mobile app
Simplified, offline-capable, centred entirely on camp setup, learner enrolment, and attendance. Everything non-essential was removed.
2
Implementation Partners → regional management
Prerak pipeline, camp oversight, and learner distribution across blocks — a middle layer that surfaces what each IP needs without full programme complexity.
1
Program Owner → strategic oversight
Highest-level view: targets, cross-programme analytics, and IP management. Designed as a desktop dashboard for data-heavy decision making.
05 Design Decisions
Designing for trust in
low-resource environments
Designing for trust in
low-resource environments
With hundreds of screens across three products, I'll focus on the decisions with the most significant design reasoning behind them.
With hundreds of screens across three products, I'll focus on the decisions with the most significant design reasoning behind them.
Aadhaar verification
The Aadhaar verification flow became the most scrutinised design challenge. Preraks needed to verify every learner's identity, but internet was unreliable and camera quality inconsistent. I designed three parallel verification paths - offline KYC via QR scan, manual Aadhaar number entry, and photo
upload; so the flow could degrade gracefully based on available connectivity and hardware.
Prerak App
The Prerak onboarding flow was intentionally light. Research showed volunteers had high motivation but low tolerance for administrative friction. The application was designed to feel conversational, not bureaucratic.
IP App
Camp management was structured around the physical reality of how camps run: set up, teach, take attendance, end camp. Every action had a clear next step, and the interface surfaced only what was needed at each stage, avoiding the dashboard trap of showing all data at once.
06 User Testing
What field testing revealed,
and what it changed
What field testing revealed,
and what it changed
I conducted moderated user testing sessions with 5 participants, observing them complete core tasks in the Prerak volunteer flow. Sessions were recorded and analysed to understand where the design held and where it failed.
I conducted moderated user testing sessions with 5 participants, observing them complete core tasks in the Prerak volunteer flow. Sessions were recorded and analysed to understand where the design held and where it failed.
The login failure was the most important finding. Despite 100% success on more complex tasks, users dropped out at the most basic entry point. Investigation revealed a credential delivery and association handoff problem between registration and authentication systems; invisible from within the UI design, but directly shaping the revised login architecture.
The login failure was the most important finding. Despite 100% success on more complex tasks, users dropped out at the most basic entry point. Investigation revealed a credential delivery and association handoff problem between registration and authentication systems; invisible from within the UI design, but directly shaping the revised login architecture.
What Works!
What Works!
All candidates enjoyed the flow and didn’t realise they were filling a form until the submit button was clicked.
The new Learner identification process felt easy and short compared to the Mform (Older Method).
Candidates were easily able to navigate through the application.
Candidates were able to complete 80% of tasks without any support.
All candidates said they would be able to fill the form without any supervision.
All candidates enjoyed the flow and didn’t realise they were filling a form until the submit button was clicked.
The new Learner identification process felt easy and short compared to the Mform (Older Method).
Candidates were easily able to navigate through the application.
Candidates were able to complete 80% of tasks without any support.
All candidates said they would be able to fill the form without any supervision.
We were able to identify the pain points in this flow through the User Testings, based on which we recommended a few more iterations of the current UX as future scope to streamline the process even furthermore.
We were able to identify the pain points in this flow through the User Testings, based on which we recommended a few more iterations of the current UX as future scope to streamline the process even furthermore.
07 Reflection
What I'd do differently,
and what I'd do again
What I'd do differently,
and what I'd do again
This project taught me that in civic and social impact contexts, the design problem is almost never primarily a visual one. The hardest design work happened in the weeks before any screen was made; mapping the ecosystem, identifying the data integrity risk, and deciding that Aadhaar-as-identifier was the right structural call despite adding onboarding complexity.
This project taught me that in civic and social impact contexts, the design problem is almost never primarily a visual one. The hardest design work happened in the weeks before any screen was made; mapping the ecosystem, identifying the data integrity risk, and deciding that Aadhaar-as-identifier was the right structural call despite adding onboarding complexity.
I'd push earlier for a prototype of the login and credential delivery flow, it was the one area where a system dependency wasn't surfaced until user testing.
Designing three separate IAs was right for the users, but added coordination overhead. I'd build in more explicit alignment sessions between the three product tracks from the start.
The field visits in Rajasthan were essential and I'd fight for them even harder. No desk research would have surfaced the offline-connectivity reality or the cultural context around how Preraks understand their role.
Thank you for reading:)
Thank you for reading :)
I'd push earlier for a prototype of the login and credential delivery flow, it was the one area where a system dependency wasn't surfaced until user testing.
Designing three separate IAs was right for the users, but added coordination overhead. I'd build in more explicit alignment sessions between the three product tracks from the start.
The field visits in Rajasthan were essential and I'd fight for them even harder. No desk research would have surfaced the offline-connectivity reality or the cultural context around how Preraks understand their role.
2026 Anoushka Sawardekar
2026 Anoushka Sawardekar