In this article, I will initiate a discussion about filter design on mobile devices. It is based on my experience designing the core customer journey for Chinese users at Booking.com.
Hick's law presents a challenge between the time it takes to make a decision and the number and complexity of choices. Filters, when applied, not only mitigate overload by reducing thousands of products into a manageable amount but also surface choices tailored to users' interests and needs in a straightforward way.
Therefore, a sound filtering experience is key to simplifying or moving the decision-making process. It allows users to find what they are looking for effectively and efficiently.
Given the importance, I started researching our current solution to understand the main customer pain points and size our business opportunities.
The research aimed to translate quantitative and qualitative evidence into strategic and tactical insights regarding
The first step was justifying business impact by investigating the correlation between converted users and their filtering habits.
As shown in the graphs, filtering behaviors from non-converted and converted users were not the same. Users with stronger motivations were prone to interact with filters. On the other hand, for groups where people applied any filter, the conversions were at least 20% higher.
It proved the business value of filters since they kept high intent users in the converting funnel.
I moved on to creating indicators that measured filter performance.
Two fundamental indicators were sr_filter_shown and sr_filter_usage. One recorded how many users opened up the filters page while the other recorded how many users ended up applying filters. Furthermore, I considered the difference between the two as a signal that captured the friction users experienced during the filtering process. The larger the difference, the worse the usability.
Another metric to look at was the distribution of different amounts of applied filters, e.g. sr_applied_1_filter and sr_applied_2_filters. Increases in average and slope may inform better ease of use.
I checked the applied frequency of various filter options. Undoubtedly the data was influenced by user persona and design solution, but it still inferred a general preference for price, location, rating, and property type.
The distinction regarding priorities of location and facility reflected how Chinese user base differed from the global.
On the qualitative side, I ran a street testing on a sample of 10, asking the participants to choose a stay for the forthcoming trip. Merely interrupting, I was able to observe the most authentic user behaviors and evaluate usability closest to real situations.
I grouped the perceptions into three aspects, namely, discovery, understanding, and use, with a particular focus on effectiveness and efficiency.
I saw findability and usability issues out of the notes, hurting the effectiveness and efficiency to filter out preferable stays.
As a next step, I conducted a lab study where participants performed filter-related tasks, compared with competitors, and gave their thoughts about the overall experience. Users were encouraged to think aloud and provide the most meticulous feedback.
Here is an excerpt of their comments:
Lastly, I carried out a survey that asked people to rank the filter criteria according to their preferences. For each criterion, I calculated its average and standard deviation of the ranking scores. Therefore, by picking ones with higher means and lower standard deviations, I identified the most popular decision-making factors, that were, location, price, rating, and review.
After a comprehensive analysis of research data, I extracted the insights at different levels.
Combining all the outcomes, I was able to uncover the top three pain points.
The pain points showed three improvement directions, that were, ease of filter discovery, ease of filter selection, and validity of filter information.
Therefore, I mapped our pain points to correspondent design concepts.
The concepts were carefully defined to make sure that 1) they were well-aligned with the nature of filters; 2) they shared the same vision to enable an effective and efficient look-to-book experience for local users.
Booking.com uses hypothesis-based A/B testing and its statistical outcomes to measure the effectiveness of any design change. For the sake of data credibility, I decomposed the revamp into a list of optimization design stories, with each one of them tackling a focused problem and getting measured by specific metrics.
I wanted to identify and surface the most valuable filters directly as quick filters. They were grouped into a new sticky section under sort/filter bar. Users could perform selecting, deselecting, and multi-selecting actions. Meanwhile, the section was horizontally scrollable to accommodate more options.
① sr_filter_usage ② sr_clicked_after_filtering ③ sr_booked_after_filtering ④ net_conversion
Due to the general preference and the contribution to filter usage, I separated filter options of price and ratings from the rest and bundled them into a new module. Users could quickly access to the module via its entry point in the new sort/filter bar. Besides, it helped release space for the original module to ensure more efficiency and scalability.
① sr_filter_shown ② sr_filter_usage ③ sr_clicked_after_filtering ④ sr_booked_after_filtering
I wanted to simplify page hierarchy and information architecture using a simple and straightforward user interface. The exquisiteness of Chinese characters, luckily, allowed me to organize filter information into a flat view. I placed filter categories on the left and filter values on the right. With sufficient white space and little overflow, this view helped users browse, select, and apply filters effortlessly.
I also used the dropdown and overlay to keep users in the context of the search results list.
① sr_filter_shown ② sr_filter_usage ③ sr_clicked_after_filtering ④ sr_booked_after_filtering ⑤ sr_no_results ⑥ net_conversion
While users selected their preferable options one by one, our current filters, either their existence or counts, got automatically updated according to the inventory availability. In short, they were dynamic filters. From user research, I knew that this feature led to a lot of confusion and misclicks. Therefore, I wanted to switch to the static mechanism such that filter options would not abruptly change on the fly.
For users who preferred seeing the results change, I provided a number indicator to let them know when they were done selecting. And to ease the anxiety during the loading, I introduced an animated spinner in the transitional state.
① sr_filter_shown ② sr_filter_usage ③ sr_clicked_after_filtering ④ sr_booked_after_filtering ⑤ sr_no_results
A truly usable filtering experience provided filter categories and filter values that were appropriate, predictable, free of jargon, and prioritized. However, it was never one-stop to achieve information validity. Instead, I refactored the information step by step and mainly examined four dimensions along the way: 1) Common sense, 2) Users’ preferences, 3) Data readiness in terms of completeness, accuracy and granularity, 4) Business needs.
① sr_filter_usage ② sr_used_popular_filters ③ sr_clicked_after_filtering ④ sr_booked_after_filtering
We learned that users wanted to find a nice location. When they started searching for accommodations, they did not have enough knowledge to choose based on the district name only. Therefore, I offered them additional descriptions in the forms of two: 1. Inventory facts; 2. X% of users’ choice serving as social proof.
① sr_filter_usage ② sr_used_location_filters ③ sr_clicked_after_filtering ④ sr_booked_after_filtering
There are three topics worth highlighting of filter design.
While filters look similar in many products, their behaviors vary widely. Can users adjust multiple filters before the results of the compound query are returned, or are the results returned after each filter value is specified? Answers indicate two filtering mechanisms: batch filters and interactive filters. Choosing between a batch and an interactive implementation mainly depends on user intent and site speed.
Exploratory users who do not have a clear search goal need to learn about the search space and the possible options. These users will benefit most from interactive filtering. Alternatively, determined users who already have multiple criteria in mind will benefit from batch filtering. But how to predict users’ mindsets while they are filtering? In this case, one solution is letting users tell us when they’re done selecting filters. It means to include an apply button in the filter design. Users can click on that button once they’ve indicated all the preferrable filter values.
Site speed is a much obvious factor. If we expect the queries to be instantaneous, then interactive filtering will be less offensive. If the product is likely to be slow, then batch filtering can save users some waiting time.
To summarize, knowing when to stop and apply filters allows users to smoothly progress towards their goals while maintaining a sense of UI stability and user mastery.
A powerful feature usually improves capability and flexibility from users. However, the most advanced filters do not necessarily guarantee optimal user experiences.
The first example is about dynamic filtering, being popular among e-commerce giants like Taobao and JD.com. The reasons why they stick to this pattern are 1) they have thousands of commodities 2) commodities are mainly tangible 3) servers are robust and reliable. Compared with them, 1) accommodations form a relatively small inventory 2) accommodations are intangible, heavily influenced by seasons 3) servers are remote and slow. In this case, if I appled the same solution, users were more likely to see drastic filter shifts and page re-structures, which severely disrupted their filtering process.
Another example is about separating the location filters. Due to the immaturity of current geographical information and the misplacement of map feature, I proposed to defer this separation.
To summarize, when designing for filters, we should consider
I found that the more I encouraged people to use filters effectively and efficiently, the more they would encounter the empty state of search results.
I believe that instead of preventing overfiltering, a better solution is to build an informative, robust, and scalable empty state as it ensures better flexibility and guidance to users. When users get zero matching properties,
Outcomes had two parts: deliverables and relevant design validation.
Our developers, the back-end and the mobile, need to sync up closely to build a robust and scalable system. Therefore, in the interaction document, I not only listed the interface specifications but also the interactions and their underlying logics .
Booking.com uses Randomized Controlled Trials (A/B Testing) to understand the causal inference.
To confirm causation and eliminate coincidence, we want to reject the null hypothesis that assumes any difference observed is simply by chance. We compute a p-value indicating the probability of seeing a particular result or more extreme, assuming there is no effect. Given sufficient power, results under the threshold where p-value < 0.05 are called statistically significant and we are confident that the variant is better than the base.
Take certain design stories as examples, I found the conclusiveness of results below.
I also tracked the distribution of average time users spent interacting with filters. It turned out the filter redesign reduced the interaction time from 7900ms to 6800ms for the representative population.