What if every small interaction with an AI assistant chatbot was seen as a skill in itself? From a frontline worker deciding what to ask. Choosing whether to speak, type, or tap an example question. Checking whether a voice query was understood correctly. Reading or listening to an answer. Trying again when the system cannot answer. Each of these moments reveals something important: what users are able to do, where they hesitate, and where they quietly succeed.
For Health Vaani, these small moments became central to understanding adoption.
What’s Health Vaani — India has ~2.5 million frontline health workers (ASHA workers, ANMs), but much of their training content is buried in lengthy documents, limiting their quick access to vital information that is curated for their specific questions.
Health Vaani is an AI-powered conversational assistant designed to support them in-service by delivering pre-validated, role-specific knowledge via mobile. It has in-app support for being able to hear an answer and speak a question. It aims to boost their efficiency, effectiveness, and confidence — ultimately strengthening capacity-building efforts.
What is Health Vaani?
Health Vaani is an in-service digital assistant for frontline health workers, including and Anganwadi Workers. Trained strictly on official government manuals, it helps workers ask questions through voice or text in supported regional languages and receive verified, audio-enabled answers with source citations. As a Progressive Web App, it can be saved to a phone’s home screen and used on basic smartphones without a heavy download.
Health Vaani has been piloted with Anganwadi Workers across multiple districts and states to understand both usage and adoption patterns. In the pilot phase, Health Vaani reached 628 AWWs across 6 states, over 2 months in 2025, generating around 8,000 user queries.
The pilot showed us that access to an AI tool is only one part of the story. Meaningful use depends on a set of often invisible competencies: knowing what to ask, framing a clear question, choosing between voice, text, or suggested prompts, interpreting the answer, and trying again when the system does not understand or cannot answer.
These competencies are often not explicitly taught. Yet they strongly shape whether a user continues engaging with the system or drops off after friction.
What if AI engagement is limited not by access, but by hesitation, discomfort, or low confidence with technology?
As end-users increasingly become humans-in-the-loop themselves, design must do more than enable access. It must build confidence. Usage patterns during pilots can reveal where different users struggle in different ways, what skills they are still developing, and where thoughtful design can support them without overwhelming them.
Not all ASHAs are at the same level of Digital confidence, digital literacy and motivation. One Anganwadi worker reported –
“अगर हमें (लिखते वक़्त) थोड़ी गड़बड़ होती है तो हमारी बेटी एक्सपर्ट है, कभी स्पेलिंग में गलती हो जाती है, पढ़ाई छोड़े कुछ समय हो गया है”. (If we make a mistake (while writing), our daughter is an expert, sometimes there is a spelling mistake, it has been some time since I left studies.)
The relationship they share with the digital tools is that of ‘all work and no play’, a relationship riddled with hardships, need for a community for query resolution, and small successes that boost confidence. It was clear to us — all our Anganwadi Workers will not display equal motivation, comfort and confidence with the system during the pilot. This is why we began mapping competencies. We wanted to understand not just whether Anganwadi Workers were using Health Vaani, but what it took for them to use it well.
Two kinds of competencies became important.
The first is inherent user competence: what users bring to the system. This includes digital confidence, literacy, domain knowledge, motivation, comfort with speaking or typing, and the ability to frame a question.
The second is system-imposed competence: the extra work the AI system asks users to do because it is still evolving, bounded, or incomplete. This includes rephrasing unclear queries, correcting voice transcriptions, recovering from “no answer” moments, understanding what the system can and cannot answer, and trying another input mode when one fails.
This distinction matters because a failed interaction should not automatically be seen as a user gap. It may also reveal a system demand that has not yet been designed for.
How to go towards understanding the data to building personas:
We combined usage data with qualitative research. We looked at interaction patterns, query quality, input choices, use of example questions, ability to rephrase, response comprehension, and recovery after “no answer” moments.
We also conducted interviews and used a NASA-TLX inspired workload assessment to understand mental demand, effort, frustration, time pressure, response comprehension, and difficulty in reformulating questions.
This helped us treat everyday interactions as signals of competence, rather than just clicks, sessions, or queries.
Influencer Persona
This user persona is confident and engaged, able to articulate complete and coherent questions. They effectively use both typing and voice input, though they show a preference for typing. When the system fails to generate a useful response, they are comfortable rephrasing or re-articulating their queries. They also make use of the in-app support features, such as example questions, to better interact with the system. This persona is enthusiastic about exploring the tool and actively seeks information across a wide range of topics relevant to their work.
Believer Persona
This user persona is able to articulate complete questions and uses both typing and audio input effectively. When the system does not provide a satisfactory answer, they are willing to rephrase their queries and explore in-app support features, such as example questions, to improve interaction. However, their engagement remains task-specific — they focus on immediate information needs and do not explore the system beyond the scope of their current questions. For Believers, it can provide better recovery after failed answers.
Observer Persona
This user persona can articulate questions, but often in an incomplete or fragmented manner using long sentences, missing interrogatives, or unclear phrasing. They primarily rely on audio input and depend heavily on in-app support, especially thematic example questions and have very few custom questions. However, when faced with “no-answer” scenarios, they struggle to recover or rephrase effectively. This often results in frustration and eventual disengagement from the system. For Observers, it can support question framing and build confidence.
Onlookers Persona
This user persona asks very few to no custom questions and relies heavily on the thematic in app support of example questions. They do not use the system extensively and engage with the system the least out of all 4 personas.
The personas helped us ask sharper product questions by showing how pilot data could identify which persona a user aligns with, and potentially what kinds of nudges and in-app support might help different personas engage more confidently.
This translated into features and design directions such as expanded topic chips, sample questions, “how to ask” guidance, transcript editing, clearer no-answer recovery, nudges like “try this question today,” and language that reassures users they can ask repeatedly without judgment.
The larger lesson from Health Vaani is that equitable AI adoption is not only about whether a model works. It is also about whether users are supported to work with the model.
