In part 1 I made the case that search UX on mobile is a pretty complex topic, from limited screen real estate, to mobility and pesky connectivity – there are a lot of traps that need to be avoided. In this post, I’ll demonstrate exactly how we can avoid these traps by taking an analytical approach to UX. We’ll deconstruct all the moving parts that comprise Mobile Search UX, and further down the road we’ll see how we can act and be impactful on mobile.
Show Me That Text Input!
Step one is simple but crucial: you’ll need to decide where in your app your users will get introduced to search. There are, for the most part, three options: Full search bar, Tab bar, Icon.
Full Search Bar
The full search bar approach typically appears on the main screen, giving instant access to the search feature. If your product or app revolves around giving your users quick and easy access to a lot of content, then it’s the way to go. Search becomes the center of interaction to your content that would typically populate the page below in an “as you type” fashion.
When search is not the main access point of your content but you still want to give users a easy access to search throughout the app then a tab bar icon is the way to go. Spotify favors suggestions of albums, playlists or songs on the home screen, and when I want a specific tune I have quick access to the search screen with the tab bar icon no matter where I am in the app.
The contextual search icon is among the least intrusive options. It’s easily the most flexible approach – you can display the button only in determined parts of the app that make sense for searching. For Gmail, the main use case is browsing unread mails in the inbox. Then, by order of importance in the UI, creating a new mail would come second with the large icon on the bottom right corner. Finally the search icon in the navigation bar on the top right corner enables users to search through all my emails.
Once you’ve determined where search starts for the user, the next UI element to analyze is the search screen. This element is mainly a transition between the main ‘non-search’ view and the result page that we’ll describe right after. The search screen is displayed as soon as the user taps the text input search field or the search icon. This action already shows an intent -”I’m looking for something-” and that should be rewarded with useful information. As we saw earlier, each tap is painful, so we must gratify each effort. Instead of a default empty table-view waiting for the user’s query to fetch and display content, let’s guide them!
Here are a few options:
- Recent searches enables fast back and forth between new searches and previous ones. When a user searches for a product, it’s handy to give a quick glance at previous searches for comparison.
- Trending searches guides the user by showing what other users are most looking for in your app. This helps an uninspired customer to discover your content easily by clicking a suggestion.
- Categories guide the user with a number of filter options to start with giving a scope of themes that are searchable, refining directly to a scope of interest and speed up the search process.
Result Screen & Result Display Strategy
The final component of Search UX on mobile is the result screen. Here, there are two prevailing strategies: query suggestions & instant results. They both serve a specific purpose and I’ll explain where & when they are the most relevant.
Before diving in, it’s important to discuss an overarching concept to search results: the as-you-type search experience. Today’s users expect search to be instant, not only with respect to how fast results are fetched, but how frequently they are updated. Instead of waiting for the user to hit enter to to type a certain number of characters before displaying results, Algolia encourages product builders to display search results from the first key stroke. Users today expect instant feedback from their inputs, hence “as-you-type”.
Typing a query won’t immediately show results on the screen but instead a series of more complete queries based on the input. Let’s say I’ve typed “iphone” in the search box, the suggestions displayed will be more complete queries that are known on the product side to be popular or relevant for that given query. I’ll end up with a list of suggestions such as: “iphone case”, “iphone cable” etc…
Given that it is an extra step between the user and results, the perfect use case for query suggestions is searching through a huge data set – Amazon is a great example. The user might feel overwhelmed by the volume of possible results and not be sure where to search, what to search, what is available. Query suggestions are an effective way to guide the user and help him quickly access what they’re looking for in a large volume of possibilities by suggesting the complete query of what they had in mind. The added benefit is a much faster time to actual relevant content as the user gets relevant suggestions after only a few characters.
Those query suggestions are most often based on popular queries, an analytics solution behind the search will keep track of what query resulted in a purchase, and with a high volume of uses an index of potential queries can be built.
Another option is to fetch actual results with each keystroke and display them on the result page. This approach is most effective when the data set is either more limited or the user might have a more defined idea of what they’re looking for. In the Spotify example we clearly understand, because of the product’s nature, that search will be limited to the realm of albums, songs, playlists and artists. When looking for “beatles” having suggestions of albums containing “beatles” could be adding an unnecessary step between my query and the actual result (e.g. The Beatles). When the scope of search is well defined and well-known by your users, providing instant search results is the shortest path between them and your content. One approach, as in our example, is to show a limited set of hits per type of content (5 artists, 5 bands etc…). The most relevant results will appear in the 5 firsts allowing the user to have a quick overview of matches on different types, and you can add a ‘show more’ button to allow the user to dive in by category.
An alternative of displaying limited results per type would be to have a segmented input right below the search box, enabling you to show more results of a specific type at once.
For this instant result strategy to provide good user experience, very fast response time is required, to allow results to be refreshed “instantly” at each keystroke.
Suggestions + Instant Results Combination
The last option to consider is a combination of both strategies. When you have a very large dataset and want to guide your user but are also able to determine if a good match has occurred then mixing both can work. On the google play store we see an actual app result above multiple query suggestions. That’s a great strategy here, as there are millions of apps but it is also possible to be confident the query “airbnb” matches very well with the app airbnb, so displaying the app here has a great chance of being the result the user is looking for.
That wraps up part 2 of our mobile search UX series. We’ve covered the most important components in mobile search today – From text input placement, to search screen and results. The decision for how you guide your user through the mobile search experience depends on a lot of factors – the size & complexity of your data set, the knowledge that you expect your user to have about the data set they are searching through, and your desire to balance discovery and intent in the search experience. With a good overview of the structuring elements specific to search on mobile, we’re ready to go even deeper to provide best practices based on those components.
Big thanks to Lucas Cerdan: this series relies a lot on the research into search and mobile UX that he has done at Algolia.