Search Autocomplete

Research

To begin the project, I worked with a user researcher to built a plan for initial user testing to benchmark the current experience.

We ran an unmoderated think aloud usability test with a small number of participants, giving the users tasks that had the potential for them to use the search autocomplete function. For example:

"You want to search for the brand 'Dr Organic'. Please show us how you would do this, noting anything you find easy or difficult about the process. Click success when you have gone through to a search result. Click abandon if you cannot complete this.

We wanted to understand whether participants used the search autocomplete to improve their search efficiency, and if there were any usability issues in doing so.

On the whole, participants did interact with the search autocomplete, but many seemed hesistant to scroll, which we felt indicated that it was important to keep the most relevant suggestions above the fold. Most participants found using the search easy enough, although testing did reveal a bug which prevented two users from searching successfully.

While there weren't any red flag usability issues, I also compared our current experience with Baymard guidelines and competitor analysis, to see if there were any ways we might be able to improve the user experience and provide additional efficiencies for users. This found that there were several areas with room for improvement, and this formed the basis of my UX explorations.

Ideation

From the research I conducted, I was able to create a list of design patterns and features for consideration, which helped me to organise my thoughts before wireframing.

One of the first idea which I was keen to explore was the concept of taking over the page with the search autocomplete, to make it easier for users to focus on the task at hand.

On mobile, this operated similar to our native app experience, which uses a seperate tab for search, which I felt was important to consider in order to ensure parity in our omnichannel experiences.

On desktop, the search overlay would be shown clearly while the rest of the screen was darkened.

This generated questions I wanted to test in usability testing, such as ensuring that users could exit the overlay easily, and that they didn't find it disorientating.

This initial wireframe also brought up questions around how the search results should be displayed. From my research into Baymard guidelines, I knew that it was important to make it clear what types of search result were that were shown, however from our own research we knew that it was important to have as much relevant information above the fold as possible.

As such I wanted to experiment with some ideas for conserving space. The first was merging the search results, so they were no longer split out by product, brands, and articles. This would ensure the closest match was able to be surfaced most highly in the search results. In order to provide clarity to users, the type of search result would be shown alongside the search term. When user tested, this performed well and shortened time taken to find a result.

My second idea for conserving space was using a tab mechanism to allow users to quickly choose between products, brands, and articles; and also help users understand the different options available, as my initial research showed users rarely found articles within the search autocomplete.

To tests these concepts, I engaged in usability testing.

User Testing

Tabs vs list for search suggestions

Between the tabbed and long list variations, there were no significant usability with either version; in both instances users were able to quickly find what they needed. However for the tabs version one user had a very negative reaction to the tabs and didn’t find it obvious that you had to select the type of search result you wanted. One other person didn’t go to the tabs as her first instinct, but did subsequently find them quite quickly.

In contrast, the long list variant had no issues from a usability point of view, but several people noted their frustration at the amount of search results there were to scroll through, making it harder to discover products and articles successfully.

While this test was relatively close in terms of overall usability, the strength of the negative reaction that the user had to the tabs left me with concerns about how well it would be adopted, and I felt that there was less opportunity for frustration with the long list.

In order to make the list less unwieldy and mitigate some of the frustrations raised for this variant, I suggested we impose limits on the number of search results, as per the guidelines from the Baymard Institute.

Full screen search (mobile)

To test how mobile users responded to the full screen display of the search autocomplete, I ran an unmoderated usability test. Participants were split into three groups and shown a seperate version each. The first version used a dropdown style search autocomplete, where the search content would just appear underneath the search bar, leaving the rest of the page visible. to close this, users would need to use the 'x' button to clear their search.

Note, this first design was the original design proposed in the new navigation project, but hadn't gone through any previous testing.

The second two options utilised the full screen search window, with the first of them using a back button at the top for users to close the window, while the second used a more explicit cancel button.

The dropdown version tested most poorly, with users finding it unintuitive to close the search window to get back to the homepage.

There were no significant usability issues discovered for the other two options, and as such I decided to go ahead with the back button option, as I felt like it was the more accessible choice, as it provided a search label to provide context once the placeholder text had disappeared.

Full screen search (desktop)

For desktop, I wanted to test two options, one where the search bar expanded to fill most of the width of the page, enabling a wider search autocomplete window, the second where the search autocomplete was the width of the original search bar.

My hypothesis was that the wider version would be more efficient for users, as they would be able to see all the options more clearly without needing to scroll.

However, my results were surprising. Participants seemed to ignore the left column where the search suggestions were housed, and focused mainly on the products section on the right. Many participants clicked straight on the 'search for xxx' button rather than viewing any suggestions.

In contrast, in the narrow design the participants found the results very quickly and accurately, with no usability issues.

When asked to score how easy they found the tasks, the average for the wide design was 4.5/5 (where 5 was very easy), whereas the narrow design scored 4.73/5, showing a clear improvement on the wide design.