How we transformed the product search for the better

A UX case study of how we built our new search and filter solution for eCommerce product catalog managers, by following a user-centered design approach The new Merchant Center product search and filter visual interface The product search functionality available in our Merchant Center lets merchants (and to be more specific, catalog managers) find products in […]

A UX case study of how we built our new search and filter solution for eCommerce product catalog managers, by following a user-centered design approach

The new Merchant Center product search and filter visual interface

The product search functionality available in our Merchant Center lets merchants (and to be more specific, catalog managers) find products in their product catalog.

Originally, we had a single search implementation catering to both catalog managers and shop customers. Over time, we noticed that their characteristics differed: storefront search queries are simpler and returning results super quickly is crucial. However, merchant searches are more complex. And optimizing for complexity and speed is complicated.

By using a brand new feature as an example, we would like to show how the product team follows a user-centered design approach to provide the best solution for all kinds of needs.

The challenges

Despite sharing the same goal of finding products, the two groups of users have different needs and intentions. The principal end-goal for storefront customers is to make a buying decision. Merchants can customize the storefront search to promote certain products. But their principal need in a catalog search is to find products to check the data quality or update it, publish new products or manage inventory.

The merchants principal need in a catalog search is to find products to check the data quality, publish new products or manage inventory.

The accuracy of results returned in the Merchant Center catalog search was also a concern from some merchants. This was not ideal for them, whose more complex search needs also led to slow performance and a decrease of productivity.

UX and UI goals

The existing visual interface in the product section of our Merchant Center was not suited for our heavy users (those that use it to a great extent). Some users even admitted they have never tried the built-in filters. For those using them, filtering by attribute data was especially cumbersome as they had to:

  1. Open a pop-up modal
  2. Find the filter attribute
  3. Search for or type the desired value
  4. Apply and close the modal
The more attributes a catalog contained, the harder the filter is to find.

In the most common screen resolution, 720p (1280×720 pixels), the results list would even move below the fold after applying a fourth filter. Definitely, the new filters needed to be more accessible.

Catalog managers with complex data models need to view loads of information in the product list. But those with simpler data models don’t need much data displayed in the product list. For them, the search and filter functionalities are more relevant. By decluttering the page and making it more customizable we can accommodate those two different usage patterns. This lets Merchant Center users focus on what’s relevant for them in the new list.

Research and initial solutions

Let’s say we have a product catalog containing a product called “Perfect Blue DVD” and another one called “Nike shoes”. The latter contains a searchable attribute “color” with the value “Blue” selected. With the existing implementation, both products will show up in the results when a catalog manager types the term “Blue” in the search input.

This behaviour might match the storefront customer’s intention. But the merchant doesn’t need to find all products that contain the term “Blue” on any field of their product information. Ideally, they would target which part of the product data they would like to look into (the product name OR the color field). This was the reason why some catalog managers reported inaccuracy of results.

Result list showing products from a brand called “Blue” among the results

Decoupling storefront and merchant search into two separate entities solves the problem: keep the existing search API for the storefront search and create a new search adapted for merchants needs. That would mean merchants could perform their tasks without affecting the storefront search.

By splitting the searches, we could now benefit from faceted search. The main search input would be the place to search for basic product data (names, descriptions or SKUs). For any other characteristic, we would provide with more advanced filters for each one of their attributes. For instance, if a catalog manager is looking for black accessories, the facets used are one in categories and another one in the attribute color.

This solution brought usability questions:

  1. How do we help users leverage the power of filters when searching for attribute values?
  2. How do we encourage them to start using the filters again?
  3. What’s more relevant for merchants, see their entire product list or have filters always visible and available? The use cases might differ from one company’s data model to another. A way for each merchant to choose among those two options would be the best solution.

Prototypes and wireframes

The decision whether to move the filter section (and if we did, where) was one of the first UX/UI decisions taken into the project. Filters work the same way and are always placed in the same area of the page throughout the whole Merchant Center platform. Moving them to a different place on this single page would solve some problems but it would break the consistency in our UI. Oh, the old battle between consistency (one of the 10 usability heuristics of user interface design) and efficiency that UX designers have been fighting many times!

A common design pattern for filtering a list is a filter sidebar. Many online shops and travel websites (e.g, Amazon or use that UI solution to accommodate their large number of filters (catalog manager’s situation as well!). The benefits we see implementing a sidebar in the product list for our particular case are:

  • Have all filters in a single place (no more pop-ups needed)
  • The applied filters won’t push results below the fold

To cover the needs of every merchant, and by taking into consideration the progressive disclosure pattern, we came up with the idea of showing and hiding the filter sidebar on demand. The sidebar is hidden by default, so it does not overwhelm the user. When users don’t need to filter products by attributes, they can hide it and focus on their product list.

As Katie Sherwin describes in her article User intent affects filter design, there are two dimensions to take into consideration during the design of filters: when to apply the filters to the result list and when to scroll to the top of the result list.

There are two dimensions to take into consideration during the design of filters: when to apply the filters to the result list and when to scroll to the top of the result list.

If the user’s intention is to start scanning the result list right after applying a filter, refresh the result list and scroll back to the top provides the most useful experience to the user. But what if the user is still browsing and applying filters? Taking them back to the top of the page would force them to scan the sidebar again, to find where they were before the disruption. We needed a way to keep the filter sidebar untouched when the product list refreshes. Independent scrolling was the answer.

A filter sidebar with independent scrolling allows users to put focus on their current task.

Once we figured out the page structure, it was time to focus on the sidebar content. Some stores have huge data models with hundreds of product attributes. Showing all these attributes in the filter sidebar by default would not be too useful for them, as the sidebar will become too cluttered and filters hard to find. They needed a way to edit the sidebar: choose what filters they need in that sidebar and remove what they don’t need.

The first sketches included a filter sidebar with two tabs:

  • We would put the basic filters in the default tab: those that any product catalog would contain.
  • The second tab would contain the attribute filters (color, size, brand…), which were previously hidden in the pop-up.

By initial interviews and shadowing some Merchant Center users, we found out that each catalog manager uses different types of data to find their products. Thus, we assumed first and by user testing then confirmed that the distinction was not even needed. Putting all filter attributes together in one place will improve their discoverability.

different states of development of the merchant center filter sidebar
The first wireframe (left) containing the filter sidebar with two different tabs and how the sidebar concept changed throughout the research process.

Each type of filter required a different user interaction depending on the type of data merchants were looking for:

  • Filters where the data is a list of items could be easily applied to the list by clicking on the item.
  • Filters that allow any text or numeric value would need an input where merchants could submit any value and press enter to submit the filter.
  • Filters for date and/or time ranges would contain two inputs to submit either a single value or a range.

In some cases such ranges, submitting by pressing enter might not be intuitive for those less tech savvy users. We added a button for better usability instead.

Despite the difference, we needed a standardized, easy way to apply and remove several filters from the list. Let’s imagine that a merchant needs to find all products from the category “accessories” created last month and today. This merchant would need to search for a date range and for a specific date in the “creation date” filter. The solution was to display any applied filter with a checkbox, allowing users to apply and remove each filter with one click.

Last but not least, we wanted to take advantage of the information that facets provide. Airbnb’s use of facets in their price filter makes for a good example and source of inspiration for us. They use them to visually display the amount of places available by price range. This information can give Airbnb users a sense of what’s the average price in a location. But let’s not forget that these users are looking for one single item (in this case, accommodation), while the merchants need is quite different as explained before. Showing the average number of products per filter is not that relevant for their usual tasks.

price filter airbnb
Airbnb price filter

A solution found often in e-commerce is the use of numbers that represent the amount of products containing that filtered value. With this visual hint, merchants don’t even need to apply the filter to know how many products they will get. With this usage of facets, we follow the Poka-yoke principle and prevent them from getting zero results.

Suggested values represented as checkboxes, ready to be applied as filters

Depending on the merchant’s need, suggesting values into each filter could be helpful. But for now, the only data we could get was the value included into the biggest amount of products. Without applying machine learning on each project, these suggestions might not be useful for merchants. As this thought was only an assumption, We still wanted to get feedback from real users about it.

We decided to check if we were on the right path before implementation as the change in both page structure and functionality were too broad. The most effective way to do so is by testing prototypes with real users.

Usability tests and results

Five product catalog managers, real users of the Merchant Center, were subjects taking part of the usability tests. There are many studies (like this one) that prove that with five subjects you get close to user testing’s maximum benefit-cost ratio. With me in the role of the facilitator and a fellow UX designer as a note-taker (so we did not miss our user’s reactions), we visited them at their workplace. In order to replicate the user’s usual scenario, the product data we used was part of their own product catalog.

The 15-minute test consisted of a short interview and a task using a clickable prototype. The three-part task was the following:

  • You need to perform an update in all the antifreeze products under the “Kitchen and household” category between 2 and 5 liters.
  • You have just realised that you just need to update the antifreeze products that are smaller than 2 as well.
  • There are too many filters on your list that you no longer need. Is there any way to solve that?

We asked participants to express their thoughts while performing the task. This method, called thinking aloud, gives qualitative feedback as the thoughts are shared in real-time.

The goals of the usability test were the following:

  • Learning if the filter sidebar is discoverable
  • Verify if the visual representation of facets is understandable
  • Follow the actions that users will perform to find products of a specific product type and from a certain attribute value range
  • Confirm whether the “edit sidebar” feature was easy to discover and use.
The more low-fidelity your prototype is, the less afraid participants will be in communicating the problems they encounter.

Our findings after testing the prototype were:

  • 2 out of 5 test users tried to use the search input in order to fulfil all the tasks, dismissing the filters. They typed all the possible values that the task provided and tried to submit the search query.
  • 1 out of 5 test users mentioned that they rarely need to search for product types or categories. This catalog manager focuses on filter attributes instead. Not distinguishing between basic filters and attribute filters was a good decision.
  • None of the test users found helpful the suggested values on filters. We decided not to implement that as it would not bring any value for them.

Beta release

Launching a new interface, especially with a completely new API behind is always risky. Our team decided to release this new functionality as a beta to a select group of users first as well as those who participated in the usability tests. The usability tests provided good input, but we wanted to get feedback on the initial implementation, to learn and improve.

Concurrently, a different group of UX/UI designers tried to replicate usual catalog managers tasks first and then ranked the usability breaks found as high, medium and low risks. Thanks to those, we were able to improve both copy and usability prior to the open release. This process is called UI risk analysis.

A different group of UX/UI designers tried to replicate catalog managers tasks first and then ranked the usability breaks found as high, medium and low risks, following a UI risk analysis approach.

After a few days, we had the chance to go through the new product search with some of these users. With their questions and their feedback, we were able to understand if the new solution fulfill their needs.

If the users of your interface need to complete some training to start using it, it means that interface is not intuitive enough. We needed a way to highlight the new features in order to encourage all users to interact with them and become aware of their value added. Based on the previous feedback, this was especially applicable for filters. We added a quick “what’s new” message that pops up during the first time that a user visits the page.

If your app’s release notes are not integrated into your platform yet, “what’s new” messages are a great way to communicate big changes.

By monitoring the first few weeks of usage, we found that users were divided into two groups:

  • One was using purely the search input without filtering their list.
  • The other had a more balanced usage in both search input and filters applied.

The investigation led us to the reason: it had to do with the demos we conducted. All users from the first group did not participate in any demo. Users from the second group took part of at least one of them. This meant that the “what’s new” message was not enough to change user behavior.

To improve awareness, we targeted new places in the UI where we could inform users about it. A good place to start was the “no results found” message. If that group of users were performing so many searches, they were landing on that page often. We substituted “Try reducing your search term and apply less filters to get better results” to what you can see in the screenshot below:

No results message
Use the “no results” message to help your users to recover from their possible errors

Within 3 months, we’ve launched our new product search, available for all our users. This release is a great symptom of the maturity that the Merchant Center is approaching. And that would not be possible without our users’ help. Thanks to the input and user’s feedback we collected throughout the process, we are confident the new search will improve the search experience for every catalog manager.


Thanks to our testers, beta users, designers, developers, product owners and anybody who helped building this feature. And special thanks to Andrea, Brad, Freddie, Adnan and Yann for their contributions to this article.

How we transformed the product search for the better was originally published in commercetools tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source: Commercetools