Fig 9.0 · 5 min
Voice search for users who do not type
A microphone on every search bar, on-device recognition, no server round trip. The small design decisions that made it usable.
- Mobile
- Inclusive design
- Speech
A large share of the users of one healthcare app we run read and type slowly, if at all. Speaking "Kailash Hospital" is the difference between using the app and giving up on it. So we put a microphone on every search bar. The interesting part was not the speech recognition. It was everything around it.
On device, not on our servers
We used the phone's own speech recognition: Android's SpeechRecognizer and iOS Speech. Nothing is sent to our servers, there is no per-use cost, and it works in Hindi and Hinglish because the platform handles the language model. For a search box, platform recognition is good enough and the privacy story is simple.
Seven places, one behaviour
The microphone appears on every search bar in the app: the home screen hospital search, products, products within a category, lab tests, doctors, and a hospital's doctor and package lists. Same icon, same panel, same behaviour. Users learn it once.
Prompt in the user's language, with examples
Tapping the microphone opens a panel that says, in Hindi, "Listening… speak", and then gives examples: say the name of a medicine, a test or a hospital. The examples matter. A blank "listening" screen leaves people unsure what is allowed.
Transcribe, do not search
What was heard is put into the search box. It is not searched automatically. The box stays editable, so the user can fix a mishearing before searching. Then the panel says "Done". Auto-searching on a misheard word would have sent people to the wrong results and taught them the feature was unreliable.
Why there is no demo video
We record a demo video for every feature we ship. For voice search we deliberately did not: an emulator cannot be driven by a human voice in a way that is honest, and a staged video would misrepresent how it behaves with real accents and background noise. We wrote the explainer instead and tested on real phones with real users.
What we would do next
- Offer a "say it again" affordance when confidence is low rather than silently inserting the best guess.
- Map common spoken forms to catalogue names, so "sugar test" finds the glucose panel.
- Keep the data on device.
The lesson generalises beyond healthcare: for a large part of India, voice is not a feature. It is the keyboard.
Written by the engineers at Software Muskets. Questions or corrections: contact@softwaremuskets.com.