In Depth analysis of Voice Search in Mobile Apps

Search transformed the Internet as we know it. Made it accessible to one and all. It was the same entry point to an otherwise chaotic universe. What started as a predominantly keyword-driven activity (“Rajinikanth 2020”, “Bangalore restaurants vegetarian best”), has evolved into more complex natural style queries (“most recent Rajinikanth movie”, “restaurants near me that serve best vegetarian food”). Over time search also became multi-lingual. Over 40% of all websites visited are non-English.

‍

‍

‍

A key driver for this is that keyboard-driven searches have started transitioning into a voice-driven search. According to a research done by KPMG and Google, over 28% of all searches are now done via Voice and growing briskly.

‍

What about Apps?

‍

As people shifted towards mobile apps, the responsibility of search moved from the generic search engines to the actual app itself. For a lot of apps, the entry point to the customer journey starts with Search.

‍

‍

Just as customer behaviour is changing in the Google search world, it's important to handle this trend inside apps too.

Different types of Search

Catalog Search

This is the obvious one, especially for OTT or e-commerce apps. The user is interested in some specific content or item and they want to get to it quickly. Traditionally one would type in the item in the search bar. But this has the following problems -

• They might not know the spelling of the item or content. Auto-suggestions could help, but the user should still at least be able to type in a few correct characters related to their intent. We have all been there, struggling to type out that exact spelling.
• They might not be comfortable with English. Most apps are not multi-lingual and so the user might not be comfortable in writing in English. Most of us in India are bi-lingual. But how many of us can write in our native language, even if we are comfortable reading it? Similarly, even if a lot of users could consume the content of your app in English, expecting them to type it in English would be a major deterrent.
• Hinglish recognition is missing. Because of the bi-lingual nature of Indians, we typically are comfortable in writing our vernacular words in Roman (English) alphabets. But the spelling variants are so many when we transliterate. “Thakali” or “Thakkali” or “Thakaali” all refer to Tomato in Tamil. Most searches will fail to understand their variants, even if your app technically supports “Hinglish”.  
• Vernacular typing is even harder. Even if the app has vernacular/multi-lingual support, typing in vernacular is hard, unless you are used to it. Vernacular and transliteration keyboards certainly help, but its still heuristic-driven and not accurate.
• They might not be comfortable typing on a mobile phone. Finally typing, in any language for that matter, on that small virtual keyboard on your phone is tough. We have all been there struggling to hit the right keys.

Search and filter

The next most popular search that people expect is the ability to apply filters in search. Something like “blue jeans below 2000 rs”. But most apps don't allow this, as their search is not backed by any NLU (Natural Language Understanding) system. Instead, the user is expected to set complex filters using the UI. Most users might not even be familiar with the filtering mechanism as its typically hidden and needs a separate click to open up the page/fragment with filters.

‍

‍

Feature Search

This is a “manual search” that a user does to discover a feature by clicking through nested menus and screens. Remember searching though settings for how to reset a password or trying to find the page to reorder a chequebook in your banking app? That could easily have been avoided if the user could have actually just “searched” for it.

‍

‍

Some apps like Google Admin console have added this ability but its not common yet. But even if this provided, the search is typically keyword driven. Users might not always refer to the feature the same way as the designer intended to. For eg, if you search for “signout” you will not get “logout” if that's how you labelled your feature.

FAQ Search

The help section of an App is another place that benefits by Search if it even exists. Most apps have a dedicated Help page that the user typically needs to switch over to explicitly (leading to context switches and potential drop-offs). The help section is also a monotonous page that is bulleted and meant to be browsed than search.

Some apps have a keyword-based search added to it, but again it suffers from not being smart about recognizing how a user would label his or her own problem and matching it with how the app categorizes it. For eg in Rapido, they call their drivers as Captains. But not everyone is going to be using that term. They might search for “driver” but the search does not take care of it.

‍

‍

Voice Powered Smart Searches

The common theme among all these above search touchpoints can be summarized as below — 

• Searching for something should be easy
• Search should not be rigid
• Searching should feel natural
• The ability to search should be available all the time

The easiest way to fix this would be to power your search by Voice. There are three ways to make that happen typically -

Add a basic “Voice to text” convertor localized to the “text box” that is powering the search.

‍

‍

This would help the user speak instead of type, typically used to help users entering content into a “text box” style UI elements.

Add a smart Voice Assistant specific to the context which needs Voice. E.g. adding the Voice Assistant to the “train search section” of a booking app. This would allow users to speak complex sentences that can be used to perform filtered searches. “Show trains for second class A/C ticket from Bangalore to Chennai two days from now”.

‍

‍

Add a global smart Voice Assistant that is available to the user at any or most points in their journey. They can use it to navigate to various sections of the app from anywhere or trigger searches from anywhere.

‍

‍

So how does one go about adding these various Voice capabilities in their apps? What are the pros and cons of the various approaches? We will discuss that in the second part of this blog series. Until then would love to hear your thoughts on the above problems and the various use-cases for search in your own apps and how you have solved them.

‍

‍