Published on | Prototyping: From UX to Front End — Medium graceychen

The search box — it’s the first thing many of us turn to when we can’t find information we need on a website or app. In some cases, it is the only way to navigate to specific information, such as when looking for someone on social media who is not within your network of connections.

When designing for an effective and efficient search, we can ask ourselves two questions:

What is the user’s purpose for using the search functionality?
Within a set of search results, would the user prefer to see any particular subset over others?

CASE STUDY: AIRFROV

The following views and wireframes of the redesigned search feature are my own. They do not necessarily reflect the views of Airfrov.

A daunting search?

Airfrov is a platform that connects travellers to people who want to buy products from overseas, which are either not available online, or would incur exorbitant delivery charges.

The platform allows users to post requests for items from any country, as well as travellers to post recommendations of items they could help purchase. With the large (and growing) number of posts, a search functionality would likely be useful.

Airfrov’s search feature currently has four layers of filters

The Airfrov website has a dedicated search page where users can:

Filter using Category tags
Apply search filters to limit keyword search within a specific set of data (requests, recommendations, users, or countries)
If looking under Requests or Recommendations, apply or change filters (request/recommendation, country, or category)
If looking under Requests, filter by Status (open, offered, accepted or completed)

Users are faced with four layers of filters at once, making Search seem unnecessarily complicated. Can Airfrov’s search feature be designed in a way that is more intuitive and effective?

1. Search has to be purposeful

What is the user’s purpose for using Search?

Let’s begin by examining the motivations of two user groups* on Airfrov — ”travellers” and “potential requesters”, using the Jobs To Be Done framework.

* “Active requesters” have to wait for travellers to make an offer — the platform currently does not allow them to invite specific travellers to fulfil requests, hence I did not consider active requesters as a target user of the search feature.

In the job personas illustrated above, Mich and Lil represent “travellers”, while Zee represents “potential requester”.

From the job personas, we can identify the following purposes of Search:

Mich’s purpose is to find an Open Request in a specific Country.
Lil’s purpose is to find a Request or Recommendation in a specific Country.
Zee’s purpose is to find a Request or Recommendation.

The user flows can be visualised as zooming into different data sets (diagram below). This would help us organise and prioritise the data sets when we redesign the search feature.

Zooming into data sets

2. After identifying purpose, consider user preferences

Within the search results, would the user prefer to see any particular type over others?

Filters allow users to narrow down their search and zoom in to what is most relevant, according to individual preferences. Take Mich for example: if Mich was a single guy, he might not be so keen to help purchase items in categories like “Ladies’ Fashion” or “Mums and Babies”. But it would be a different story if Mich was a middle-aged woman. Category could be a useful filter for all three personas — if all items fit nicely into one category or another.

In additional to Category, other preferences that we might consider are*:

Country — Zee may not be travelling anywhere, but they might have preference for items from only certain countries.
Type of post — As Lil is interested in the latest products, they might want to look at Recommendations by travellers who might have first dibs on what’s available around the world.
Status of Requests — After looking at Open Requests, Mich might want to check out Accepted or Completed Requests for the same item, to decide how much they should offer to buy an item for.

*As this is only a design exercise, user interviews were not conducted to discover real user preferences.

FILTERS COME IN MANY FORMS

To design the filters for efficiency, it is useful to consider the types of data sets involved in the search functionality: Are they finite or infinite? Is a finite set small enough to fit onto a mobile screen, or will users be forced to scroll through a list that seems to go on forever?

Examining the data sets involved in Airfrov’s search functionality

What are some forms of filters we could consider for finite and infinite sets, and for finite sets of different sizes?

“Invisible” filters

A search box can be smart enough to have filters applied automatically to search queries, showing results only from the most relevant data set(s). An example is LinkedIn’s mobile website , which allows you to search for “people, jobs, posts, and more…” in one search box.

This removes the need for users to apply a search filter first, in order to search within a specific data set, as what is happening on the Airfrov and Couchsurfing websites.

LinkedIn’s smart search box (left), vs Couchsurfing’s search filters (right)

Smart search boxes can also come with auto-complete or auto-suggest, making it especially useful for very large or infinite sets of data (such as countries or unique items), as users would not have to manually select from long lists.

“Checklist” filters

Checklist filters are what we commonly have in mind when we think of filters — a list of options that we can select from. They are useful for small to moderately-sized, finite sets with non-mutually exclusive choices.

“View” filters

Modes function like “view” filters since they allow users to toggle among different subsets of results, without having to input anything different. They commonly appear as tabs in search features on mobile apps.

Search feature with tabs: (left to right) Airfrov app, Instagram app, LinkedIn app

“Mode tabs”, as I shall call them, is most suitable for filtering a set when:

Number of subsets is fewer than five
Subsets are mutually exclusive

So looking at the data sets again, we could possibly apply the various forms of filters as shown below:

Putting it all together

Taking into consideration business impact, we would design for Mich as the primary user of the search feature, since Lil is using the platform for their own research, and Zee is only browsing.

The following wireframes show a proposal for the Airfrov website’s search feature, designed with all three user flows in mind, with Mich’s as the priority.

Left to right: Results of search query, checklist filters, and results of applying a checklist filter

What will help Mich achieve their purpose:

Tabs to toggle between Requests and Recommendations, with “Requests” as the default mode
A smart search box that allows them to search for an item or country directly

What will help Mich satisfy their preference:

Lightbox with checklist filters that appear only upon clicking on the Filter button (Status of Requests only appear under “Requests” mode)

Thank you for reading

Feel free to leave some thoughts on how to design for a better Search experience 🙂

Designing for an effective, efficient Search: consider user purpose & preference was originally published in Prototyping: From UX to Front End on Medium, where people are continuing the conversation by highlighting and responding to this story.

Designing for an effective, efficient Search: consider user purpose & preference

Cool stuff, every week

More Articles