The journey from Search Scope to Search Unified for LBB (2/2)

Sharing with you all what I have learnt while working on search for LBB. Check out the first article in the series here to get a better context.

The Problem

The search was scope based and not unified

The major issue being people were searching for Places/Products/Events thinking it was a unified search and were not able to get the correct results. Since it was scope based it took few searches before people realised which tab to search for item they were looking for.

The two sections mentioned above had their respective search bar, thereby creating a confusion in user to decide where to search. Adding to this there were multiple UX units and analytics to be handled and maintained on our end.

The Challenge

The main aim of the research was to come up with the design solutions that will impact the search usability and accessibility to the people. It was important for the team to revamp the search funnel i.e. moment the user starts to type till the landing on relevant result. Thus the problem was to have an impeccable search that helps user to easily discover and reach the exact item they were looking for.

The Process

  1. It all started with understanding how search works for different platforms and how using those existing behaviours we can work backwards to create a better search experience for people.
  2. We conducted user interviews to understand what was working and what didn’t. For this prepared a list of questions relevant to us and recorded answers of different active users of our platform.
  3. The iterations were made and the prototypes were tested with our team and a closed group of our LBB Insiders.
  4. Even after being confident about of final design which went live the numbers didn’t go up as expected. We had our analytics telling us something was going wrong.
  5. We again went to our whiteboards and started with putting up all the funnels and functions along with the screens using them.
  6. We realised people were not able to distinguish results on pressing enter and also were looking for results for all in case they didn’t know about a brand/place. Our query result was not working as we expected it to be.
  7. Queries on search bar of Place section had many queries that were related to Shop. Eg: Users were typing ‘Casual Shoes’ in search bar of Place section. This was resulting in drop-offs.
  8. Open searches (search that is not triggered by using autocomplete suggestion) were very high as compared to the autocomplete searches, showing scope of improvement in the autocomplete suggestions.

9. Unified search also need a common autocomplete framework that not just handle results from both the sections but also help user easily distinguish between them.
Eg: Query like ‘Casual’ can have Place results (Casual Dining) and Shop results (Women’s Casual Shoes, Mens Casual Shoes, Women’s Casual Shirt etc.)

10. Now unified search was solving first part of the problem of triggering one common search across all sections, but there was a second part in the search funnel i.e. channelizing the search to the relevant landing page. This becomes important in case of open searches where we don’t know the intent of the user.
Eg: Open search like ‘Coffee’ can be triggered to see results either in Places(coffee shops, coffee makers etc.) or in Shop(Coffee printed shirts, coffee coloured dress etc.)

11. To handle this problem, we introduced a new page — Disambiguation Page which was missing previously. This page handled cases specifically for open searches. As user is able to search all the sections across platform, any open search takes the user to the disambiguation page.

12. The page helped user to channelize their intent of search to a particular section. What looks like a mere choice to select the section in app, triggers the type of search indexing(Place or Shop) in the backend.

11. This is how we catered the needs of our existing and new users in searching anything they want from the platform.

The Solution

Better the results → Faster the user reaches the item searched → Better user experience.

Since search funnel is a type where users want to spend least time and land to the relevant result as soon as possible! Hence to make it further clear and fast, a glimpse of top 3 results with images are shown in the disambiguation page. Our users love images! They could access either directly the result or see the list of results related to the query search.

As mentioned above there are two different search indexing that we use, one for each section- Place and Shop. Indexing used depends upon the user’s type of selection in the disambiguation page.

Search autocomplete → Disambiguation Page → Place/Shop Results

Each of the indexes has a list of attributes and each attribute has a defined score depending on the priority. As the user searches a query, these attributes with their respective score provide a sum of score called as relevance score. We use this score to rank the results.With all these iterations, testing and processes, unified search was introduced to refine the search funnel.

This was a team effort where Designers/PM’s/Founders/Users together helped in building the product. As LBB further grows in conjunction with rapidly changing market, feature like search serves as an integral base to the whole ecosystem to evolve further.

If you are here and reading this you people are awesome🙌🏻👏🏻🥳. Looking forward to keep sharing my experiences and crafting great products in my journey ahead.

Want to meet me socially? Connect here 👉🏻 LinkedIn | Dribbble | Twitter

Creating stories, experiences & games. Currently @ Hike.in | Ex- @ lbb.in | Writes about • Design Updates • Knowledge Sharing • Life in between