My Work | E-Commerce Search
E-Commerce Search Experience with Vehicle Fitment
NAPAOnline.com implemented a natural language search engine which guide users to find a more narrow and refined results set based on what they searched for.
Tool I Used: Paper and Pencil, Sketch, Invision
At the time, users were performing searches that yielded large results set. Users were also struggling to find what they were looking for, and NAPAOnline had a large number of ‘No Results Found’ pages occuring because our search experience was not successful in helping users narrow their results correctly. Users were including vehicle information in their search term and being presented irrelevant results to what they entered since the current search engine had not been identifying the vehicle.
It was important that the search experience tailored to the retail customers and helped them identify what they were looking for.
We began the project with a discovery phase to help us understand the capabilities of the new search engine. I worked closely with the business analyst and the dev architect to begin defining the requirements of the new search experience. We analyzed types of searches that could happen and how to present and communicate the results on the page.
In order to map out the user flows and scenarios, we had to identify areas that would be impacted by the new search experience. We began by outlining the basic happy path flow that we had defined. We listed the components and functionalities that we needed to address at each step.
Whiteboarding sessions helped us identify areas of impact for the new search experience.
We determined two main scenarios to address:
1. Search with a full vehicle
2. Search without a vehicle
Each scenario had multiple conditions and paths it could take. I started to develop the user flows based on these scenarios. The earlier iterations of the flow helped us establish the templates and different states of components that would need to be created in the search flows.
This is an early version of the screen flow. I was begining to define the logic for different searches and the templates that would result in each search case.
This is a later iteration of the screen flow. At this point, we had identified additional subcases for searching with a vehicle.
Our biggest challenge was how to represent the vehicle. Because users could now incorporate vehicle information in their search term, it was important to communicate their vehicle entry on the page. This was a change from the current search experience at the time on NAPAOnline. Now that users could have part or all of a vehicle filled out, there needed to be a way to display all these different states.
I began by defining the vehicle as an object and identifying the attributes and actions associated to the vehicle. Each state of the vehicle would display certain actions and attributes. Defining the vehicle helped keep its behavior and treatment consistent across all pages, no matter what state it was in.
There would be cases when a user's search will identify multiple vehicles. The user would have to select from the list to confirm their vehicle. These are different version of how multiple vehicles could be shown.
This was an earlier iteration of how the vehicle selector could look if none or part of a vehicle were selected. During our discovery phase, we had also considered adding functionality to save vehicles to a user's garage.'
This was an earlier iteration of how the vehicle selector could look if a full vehicle is identified. Users could edit the vehicle and add additional vehicle attributes if needed.
The vehicle selector went through multiple iterations. My biggest challenge lied in communicating all the attributes tied to the vehicle identified across the search experience.
Another challenge in our ideation process was defining all the scenarios of the Part Type Landing Page (PTLP). This page was a new step in the search flow that would be getting implemented, and would be allowing users to refine the search by selecting from part types relevant to their search term. Since our catalog is mainly differentiated based on applicated parts or not vehicle-specific parts, we carried this logic onto the PTLP to distinguish each section. Depending on the vehicle state or search results returned, we built out the templates to represent all the scenarios.
These are some examples of the templates that would be yielded from search scenarios for the Part Type Landing Page.
I went through multiple iterations and reviews that allowed me to arrive at design decisions. I delivered my wireframes to the visual design team for final designs and developed a deck of the templates to explain each of the scenarios. Once the development was underway, I conducted design QA to ensure the behaviors and functionalities defined were implemented.
We monitored user behavior and feedback closely in the following weeks of the release. Overall, there was a positive result, with an overwhelming less number of ‘No Results Found’ pages happening.
Even today, we are still iterating and enhancing the new search to continue improving the experience.
Overall, the project was successful - however, it wasn’t without its challenges. Initially, when we began the project, we didn’t realize how largely it would impact NAPAOnline.com. The scope kept increasing with each new finding on impact, thus delaying the timeline. We also had a large knowledge gap on the search engine that would be used, which caused us not to realize many of the cases that would happen until later on. Looking back now, scoping the project into multiple phases could have helped streamline the process and teach us about the search engine along the way.
Sarah Musa