Comparing top android apps to understand how context influences design decisions.
Designing the search box experience is a critical component of the overall search experience on any app. In this post, I look at how the search box works across some highly popular apps, in order to distill learnings and identify areas where they could have made it better. Given that it is an in-depth dive into the subject, this study should be more useful to product managers and UX/UI designers rather than to business leaders.
The apps in the study have been deliberately handpicked across major categories to help develop an intuition on how to make design decisions depending on the context of the app. I have restricted the study to android apps. Here is the list of 7 apps that I have looked into.
- E-commerce: Amazon & Flipkart
- Social networking: Facebook & Twitter
- Video: Youtube & Amazon Prime
- Audio: Spotify
Let’s break up the user journey into five parts.
- Search type: voice / image / text search.
- Placement of the search box
- Activating the search box by tapping on it
- Typing the search query
- Executing the search query
Let’s dive in.
1. Search type: text / voice / image search.
The first step is usually to decide which type of searches will be supported. While text search is usually the default, supporting voice/image search can significantly enhance app engagement.
Voice search
Voice search has become par for the course as it improves not only engagement but even app accessibility. On android, the keyboard itself supports the voice search so whether to support within the app itself is an active decision. Facebook and Twitter don’t.
If enabling voice search within the app, should it be Google search or any other? Amazon prime is surprisingly still on Google voice search although Amazon expectedly uses Alexa.
Image search
The use case for image search is not equally strong across apps. One case where it can work well potentially is for e-commerce apps where it would allow users to take images of an object to buy it online or search for similar products online. While Flipkart does not search image search, Amazon does and the next section talks about this in more detail.
Visibility for the voice & image search icons
Should the voice/image search icon be visible inside the search box both before it is activated and after the user taps on it? The former is how Flipkart and Prime do it with voice search. Spotify, however, misses an opportunity to showcase the image search feature by displaying it within the search box only after the search box is activated.
The Amazon app example
Amazon has the most comprehensive implementation and incorporates both voice and image search pretty well & hence deserves talking about it in one go.
Voice search
Amazon leverages Alexa and there are two routes to it.
A. Voice as global search across the app: The app supports users searching by calling out Alexa (‘Alexa, help me buy jackets’) globally across from anywhere in the app which is quite powerful. This does not require the user to find & tap on the voice search icon but simply use her voice. A nice touch is the Alexa icon stays active in the status bar at the top & reminds the user of its possibilities as long as the Amazon app is the active app! (This makes me wonder if Google search can be integrated into a similar fashion into other apps that use it).
B. Voice icon-based search: The other more traditional option for voice search is to tap on the voice search icon. The icon is however placed outside the search bar and above it, which makes it possible that many users may miss it!
Image search
The search box features an image search icon which is retained even after the search box is activated by tapping on it. The image search gives two options to users
A. Search by choosing from one of the images available in the app itself to search matching products.
B. Search by using the phone camera to take an image of an object and search for similar products on the app.
The image search gave mixed results on testing. It is usually able to read details written on the product (brand name, model number..) and pull up the matching product. However, when the product details are not visible, it usually gets only the product category right (with ~60–80% accuracy) but not the specific product.
Integrating the voice/image search should help Amazon increase user engagement with the app & also improve accessibility though it is likely that it is a niche use case.
In the remaining post, we will mainly focus on text-based search box design.
2. Placement of the search box.
The importance of search within the app compared to navigation should influence both the placement & the appearance of the search box.
Which is more important for the app? Search or navigation? When the user is searching with a specific intent rather than a casual exploration, search becomes the primary feature. E-com apps usually fall in the first category & hence are likely to give higher weight to search. Social & entertainment apps, on the other hand, should have a higher dependence on suggesting curated content to the user (news feed, related videos, etc) making navigation more crucial.
Three approaches are visible across the apps in this study; I list them in increasing order of importance given to search.
A. Search icon (instead of a search bar) on the home page.
The search icon is squeezed inside a busy top bar & makes sense for apps where the search is a secondary use case.
- On Facebook, scrolling through the feed on the home page is the most common user behavior & hence fittingly, the search is only represented by the search icon on the homepage.
- For Youtube, while suggested videos is a major route to content discovery, one could have expected the search to get at least a search box than just a search icon, given that the user is often likely to use search to narrow down the array of recommendations (movies/songs / educational / news/celebrities..) being made before looking at recommendations. Bit of surprise here?
B. Search icon on home page navigating to a dedicated search page.
On Twitter, scrolling through the feed is the primary behavior and hence relegating search to another page seems justified.
On Prime & Spotify, while some visitors are likely to search for a specific movie/song, most users rely heavily on curate and personalized collections/suggestions to choose from, making the relegation of search to a secondary page quite expected.
Two reasons possibly further justify this approach
- the visual nature of the app making navigation extra easy &
- the relatively less number of categories (moot though!) on offer helps navigation win over search in terms of user preference.
C. Wide search box on the top of the home page.
As expected Amazon & Flipkart both use this approach, embedding a wide search bar on the top of the landing screen. Given that the users often have a specific target product they are looking for, & that there are hundreds of categories/subcategories, search offers a prominent shortcut to cut right through the maze. No surprises here.
3. Activating the search box by tapping on it
Once the user taps on the search box & even before the user starts typing, many decisions need to be made to design the search suggestions page. Let’s look at 4 considerations.
A. What to suggest?
Even before the user starts typing, making relevant suggestions can reduce the cognitive load on the user. What kind of suggestions should the user be exposed to? There are two decisions to be made here in terms of what to display.
- Recent searches by the user vs popular searches on the app.
- Only search queries suggestions vs unique search results themselves.
Interestingly, on both the points above, except for one app on each, all others behave uniformly. Pretty intriguing.
Youtube/Amazon Prime only displays a long list of user’s own recent search queries but no unique results. Also, no popular searches.
Amazon takes the same approach. The famous ‘users who bought this also looked at this’ on Amazon is restricted to the product pages only.
Spotify is quite unique in only displaying suggesting user’s own previous search results (and not previous search queries). Note that each of the suggestions is a unique & single search result and not a suggested search query suggestion. Spotify stands out from the other apps in this study on this aspect.
How do other apps behave? Twitter displays both i.e specific unique result (viz. recently viewed handles) as well as recent search queries but does not display popular searches.
Flipkart displays recent search queries but does not suggest unique search results. It, however, is the only one to display popular searches through a ‘discover more’ section.
So, on the choice between user’s recent searches vs popular searches by other users, all except Flipkart only display the former. Flipkart displays both. Why? This approach is likely to be ineffective for new users since their app history would be absent or limited. (It would be worthwhile to study the app behavior for new users, something this study has not covered). Further, it is a missed opportunity to highlight trending searches to the user.
Again, on the choice between displaying search query suggestions vs actual unique search results, all apps only suggest queries except Twitter which does both while Spotify only displays unique results. Why? Let’s revisit this in the next section after looking at a few more variables.
B. Navigation ease on the search suggestions page.
How do you navigate away from the search suggestions page if you want to? The previous set of screens also show that while Amazon retains the nav bar above the search box, the others instead offer a back button next to the search box. Both approaches seem ok though retaining the navbar gives more options to the user.
Only Flipkart does neither and it makes the user need two taps to get out of the search suggestions page; one to pull down the keyboard on the Android OS which switches the icon pointing down on the Android OS into a back button & then tapping the back button to go back.
C. UI changes.
Facebook, Twitter, Youtube, and Flipkart bring up a spartan & clean white backdrop on which search action is performed. On the other hand, Spotify & Prime retain the app colors on the search suggestions page giving it a richer look.
D. Privacy.
Amazon, Facebook, and Spotify allow previous search queries to be deleted individually through a ‘X’ button next to the suggestion. Is this really a needed feature on a music app like Spotify? On the other hand, it would be useful inside the Youtube app, given that out of all the apps, the need for privacy is arguably the highest for Youtube.
4. Typing the search query
Let’s now look at design decisions that need to be made when the user starts typing her query. 5 considerations stand out when studying this set of apps.
A. Search suggestions — search queries vs unique results?
In the previous section, we did not fully answer this question. Let’s attempt to tackle this now.
Why do apps like Amazon, Flipkart, youtube not suggest individual search results and only aim to suggest search queries? For e.g.,
- searching for ‘kindle paperwhite 10th gen’ on Amazon does not directly display the actual link to its product page.
- similarly, searching for ‘adele music channel’ on YT does not display a link to Adele’s own channel even though it has 228 mn subscribers. This is a missed opportunity to drive traffic towards highly popular in-app destination pages.
On the other hand, Spotify first displays individual search results & then allows the user to search more results within 5–8 subcategories (artists, songs, playlists…). There are 2 advantages of this approach by Spotify
- On one hand, displaying unique results reduces one step in the search funnel making it more efficient.
- If a user selects a song that is one of the suggested results, the song starts playing from within the search results itself without taking the user to the dedicated page for the song.
But this approach from Spotify also one major downside: autocomplete should help in the discovery of long-tail content where the app could suggest other similar search queries (for the search query ‘country music guitar’, suggesting ‘country music guitar female’ or ‘country music guitar from 70’s’ should help dig more music). The subcategories displayed at the end only partially mitigate this shortcoming.
B. Highlighting search query within the search suggestions.
To highlight why the search suggestion is being recommended, the user’s search query should be visually different from the rest of the search suggestion — it is usually recommended to have the latter in bold since that is what the user is interested in rather than reading her own query repeatedly in the search recommendations. Amazon does it perfectly.
A couple of apps in the study are inconsistent on this aspect. Facebook (search query ‘Kapil’ is sometimes in bold) & Twitter (search query ‘edwa’ is sometimes in bold).
C. Metadata in search suggestions for better comprehension?
Metadata makes it easier to comprehend the search results. The limited real estate is a challenge though apart from making the search indexing more complex.
Spotify — Each suggestion is accompanied by a visual and descriptor (artist, playlist, album…). Flipkart will often add a visual too & indicate within which category the suggested autocomplete query will be executed helping narrow the context for the search.
Similarly, Twitter displays handle icons and descriptions, while Amazon sometimes displays the category within which search will happen.
D. Are numbers and special characters supported by the search box?
The app should be able to appropriately handle search queries that include numbers & special characters. The user should get relevant search results or at least appropriate feedback if there are no relevant results.
Spotify supports most characters/numbers and is mostly able to offer a multitude of results for each one of them.
The experience is quite inferior across other apps with special characters often neither giving any search suggestions nor any error message. For e.g, users would expect that the symbols for the major currencies including the Indian Rupee would be supported but both Amazon and Flipkart don’t. And unlike Spotify, they do not even give an error message in such cases.
E. Enhancements/innovation: filters within search suggestion.
Amazon has an interesting enhancement where for some selected keywords, it provides filters within the search suggestions. This feature, however, is more relevant to apps where the attributes are a key part of search results e.g e-com apps. E.g query like laptops/smartphones suggests price filters at 25k, 35k, and so on.
Could music apps benefit from a similar innovation? E.g allowing the users to filter on the decade (80’s, 90’s) when searching for a particular kind of music. Ditto for movie apps.
5. Executing the query
At the final step, the user finishes typing the search query or selects one of the suggestions and initiates the actual search. What design considerations do we need to keep in mind now? Let’s look at 5 areas in this section.
A. Loading the search results.
Once the user finishes typing the search query and hits Enter, the challenge is to present the results as fast as possible. Pulling up the search results and then rendering/painting them on the screen quickly to minimize perceived latency is the most critical part of the search experience.
The usual optimization techniques include
- Motion to communicate that the results are loading: Spinners, waves or shimmer, etc.
- Lazy loading images (load only when in the viewport)
- Progressive loading: Skeletal screens, blurry low-res images before loading the final content.
Let’s look at some interesting examples from the set of apps in this study. The videos are a tad long at 30–45 seconds each because they have been slowed down to 25% of the actual speed so as to make it easy to see the various stages in the transition to the final screen.
Amazon
Notice the horizontal wave (instead of the spinner) at 5 sec & the progressive loading from 5 to 10 sec. Also, there is an avoidable layout shift at 15 sec due to the delivery-related information loading just below the search bar and pushing some of the content below the viewport.
Flipkart
Watch the search results load progressively from 21st sec onwards including the handling of the images. Did you notice that the search suggestions are not displayed till the second character in the search query is typed in?
The screen prominently sliding in from the right at 20 sec acts as a filler potentially helping improve the perceived screen load performance. Also, the progressive loading of the images is clearly visible from 25 to 30 sec.
It is fun to watch these videos closely. Did you notice the ‘No results’ error screen appear momentarily at the 26th sec?
Spotify
Watch this one very carefully. Spotify makes many false steps as it works to load the final search results making it very distracting.
Even before the user finishes typing the full query, did you notice the incorrect interim results at 5 secs when the user has just typed ‘John’? None of the results match the search query at this point!
Then, the search query ‘John Elton’ gives a search result at 19 sec only for the screen to be replaced by a blank screen; even the spinner disappears from here on. (In fact, if you notice closely, a search results screen flashes even at 17 sec!).
Next, there is a skeletal screen that appears at 27–28 seconds but again disappears to be replaced by a dark blank screen again. Furthermore, this skeletal screen does not even correspond to the layout in the final results screen.
Overall, a less than ideal experience as the user waits for the results. One can argue that most of the screens which appear momentarily are unlikely to be noticed by the user. That however is moot; further, it is likely to not be missed on slow connections.
Note the skeletal layout load from 18–23 sec before it is dumped and another layout loads progressively to deliver the final search results. While the interim skeletal layout fills up the waiting period, it is less than optimal motion since it does not correspond to the final layout.
Also, only 1 search suggestion is able to load until the full search query ‘magic’ is received by the search box.
B. Back button behavior.
Consistency between the app back button and the OS back button.
For amazon prime, when the user needs to go back from the search results page (screen below), he has 2 options: either to tap on the in-app back button at the top left or to tap on the android OS back button at the bottom left.
Both the options behave differently which is not ideal. While
- the left screen below: the in-app back button at the top left skips the search suggestions screen and takes the user directly back to the search home screen.
- the right screen below: the small back button at the bottom left only takes the user back to the previous screen i.e the search suggestions screen.
On Spotify too, the OS back button and app back button take back to two different screens! This is confusing for the user.
Back to where?
Let’s consider the scenario where the user has done multiple searches in sequence and then taps on the back button. Where should the back button take the user to?
- Previous search suggestions screen?
- Previous search results screen?
- Directly to the search home screen?
Different apps seem to behave differently.
On Twitter and Youtube, both the back buttons take the user back to the previous search results page.
On FB, both back buttons take the user back to the previous search suggestions screen (& not the previous search results screen). Tapping the back button again takes the user directly back to the app home screen irrespective of the number of searches done.
What is the ideal behavior?
Given that the search suggestions page is a full-screen modal across all these apps, the transition to the search results screen is a full-screen change for the user. She thus would expect to be taken back to the search suggestions screen when using the back button.
Also, in the case of multiple searches, the user should ideally sequentially thread back through all the previous searches. However, this makes direct access to the home page difficult if there are no navigation links apart from the back button (true for all apps except Amazon). Hence ideally, a navigation hook to exit to other parts of the app combined with the back button threading the user sequentially back through previous searches should work the best.
C. Filters on the search results page.
Filters need to adapt to the context of the app. While diving fully into the design of filters is outside the scope of this post, let’s briefly look at how different apps handle this.
Flipkart and Amazon have complex filters which are apt given the products on e-commerce platforms often have a lot of variables needed for comparison. Flipkart displays the filters in a full-screen modal, allows multiple filters to be selected before applying them simultaneously. Amazon places them on a horizontal scroll and executes the search every time a filter is selected. For multiple reasons, users should generally find filters on the Flipkart app much easier to use.
On the other hand, given the nature of the content, it looks appropriate that FB and Twitter largely depend on simple (i.e single attribute) filters displayed on a horizontal scroll.
Prime offers very basic filters (the only option is to search by movies or tv shows) on the search results page. It is possibly a missed opportunity (you just have to look at the advanced search on IMDB to get ideas!). Filters though can often expose the lack of breadth and depth of content so it may be a deliberate decision by Amazon to only provide basic filters.
Spotify is unique since it does not suggest queries but rather actual results on the search suggestion page — the user hence is forced to select any one particular search result and hence there is no scope for filters on the search results page!
D. Sort options on the search results page.
Amazon displays scroll options at the end of a long horizontal scroll (not ideal) while Flipkart displays it prominently alongside the filters icon. Youtube embeds the sort option within the filters modal. Again, Prime does not allow sorting of search results though it could have been useful (sort by release date, ratings). Twitter and Facebook do not feature sort options and it is difficult to think of meaningful reasons to justify sort on their platform.
E. Enhancements / innovations
Searching + listening in parallel.
Audio apps use the third sense — hearing, unlike most others which require us to use just our senses of sight & touch. This allows them to pull the user into an extra dimension of multi-tasking: a very useful enhancement that is visible on music & video apps.
On Spotify, suggested songs start playing from within the search screen even as a minimized song card becomes sticky at the bottom. This allows the user to quickly try other songs from within the search results. Unique — works because searching & listening can be done in parallel.
Similarly, on youtube, you can minimize the playing video to the bottom of the screen and look at other results or even initiate another search. The minimized video keeps playing while you figure out the next search to execute.
Featured results
While featured results hardly sound like an innovation (given how used we are to paid results on google search), and are usually a distraction, this is an example where the featured results look extremely native and aesthetic.
Spotify highlights the top result with an extra featured section below it — this is likely to be an advertised result + high search score match. E.g typing ‘Bl’ brings up ‘BlackPink’ as a top result + featured section while typing ‘blunt’ pops up James Blunt with a featured section. This is a visually rich approach promoting selected results with a very native look & feel while strongly promoting the featured result helping improve the ROI for the advertiser.
Visual effects
The screens above, also illustrate how Spotify switches the background colors of the screen with each search, an effect that goes very well with the visual appeal of the app.
To summarise
So there it is. And as you would have noticed, we haven’t even started covering the all-important topic of the relevancy, accuracy, and sorting of the actual search results which is where the back-end developers shine their magic!
But it does bring out the fact that a seemingly simple thing like the Search Bar has tons of details that go into designing it: the apps studied here clearly take decisions differently about those details, with each clearly doing what it thinks is best given the context it operates in.
This post, however, covers a host of decisions that need to be taken primarily on the front end when designing the search box experience. These include whether to support voice & image search, the placement of the search box, how the search box behaves on first being activated & then as the user starts typing the query, before finally looking into the experience for the user when the search query is executed.
Context is king. Decisions regarding any UX component have to always keep the business context in mind.
