In a recent project, the Android app team decided to improve one of their core experiences: searching for articles on Wikipedia. Community feedback and previous usability tests revealed, that the app’s search functionality was perceived as inconsistent. Our goal was to make the discovery process for readers more intelligent, personalized and efficient to present the right result at the right time.
With a market share of 72%, Android is by far the most used Mobile operating system worldwide. The Wikipedia Android app team builds features for more than five million active readers per month. And it‘s not a secret, that the majority of the next billion users are likely joining the internet on an Android device. What does that mean for the Wikipedia Android app? Uncle Ben from Spiderman said it best: “With great power comes great responsibility“.
To be able to make an educated decision about one of our app’s core features, we had to take a step back and understand how people are using the app.
The team collected usage data and insights from readers who had explicitly opted in to sharing their anonymized usage data. We wanted to understand how readers currently access Wikipedia articles in the Android app.
We discovered that the pageviews were almost equally distributed into thirds. At 33.7% the largest portion of readers, visit articles via links from other Wikipedia articles. This data supports the reader behavior known internally as the Wiki rabbit hole, where reader[s] travel by navigating from topic to topic while browsing Wikipedia. 30.7% of readers enter into an article via external links, these readers likely perform a search request via their default browser and are taken to the Wikipedia article in the app. Finally, 28% of all article visits (1.5 million readers a month) utilize the internal search bar for their queries.
We knew now that 28% of all page views derive from the internal app search. However, we wanted more insight on how the different internal entry points for search are used. To accomplish this, we had to dig deeper into the data. Together with our analytics team we explored how readers commonly used the internal search.
First, we examined how the search experience worked and looked like. There were two main entry points to perform a search:
First entry point: Search input field at the top in the Explore feed, the app’s home screen.
Second entry point: Search button in the form of a magnifying glass icon at the top of each article.
Data revealed that approximately 60% of all readers access the search via the first entry point, a search input field in the Explore feed. Around 35% of readers were searching via the search button at the top of article (second entry point). Since the majority of our user base uses Wikipedia to read articles, we expected that most readers rely on the search button at the top of an article – so this was a surprising insight!
At this point, we asked ourselves if the search button in the articles is not obvious enough, as our hypothesis was that people were navigating back to the home screen to make use of the first entry point.
To gain further insights about how search is used, our engineering team created three variants for a usability test. Each variant had a different design and position for the main Wikipedia search in the article. Our goals were:
Variant A: Full size search input field at the top of the article.
Variant B: Search icon at the top of the article.
Variant C: Search icon at the bottom of the article.