Search is instrumental on the internet. Voice as a medium of interaction with it has grown significantly. Mobile and web apps too have many similar search characteristics, that would benefit from in-app Voice Search and improve overall customer experience.
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.
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.
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 -
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.
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.
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.
The common theme among all these above search touchpoints can be summarized as below —
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.