Designing a search experience

Lucy Lee
Lucy Lee
Nov 1 · 6 min read

Background

My company has a renowned and extensive database of classic cars and their values, but didn’t have a search feature that allowed users to quickly find their vehicles. This meant that users had to go through a cumbersome selection process in order to find a vehicle, whether they were searching for the value of their car or getting an insurance quote.

A talented engineer had created a working proof-of-concept using SOLR, an open source search tool, and I was asked to flesh out the experience and design.

Goal

Design a search and browsing experience to use across a variety of products that require selecting a vehicle.

Role

UX designer, with support from UX researchers and a visual designer.

Summary of design process

  • Stakeholder interviews
  • SWOT analysis
  • Use case analysis
  • Review of design principles
  • Competitive analysis
  • Protopersonas
  • Interviews with car enthusiasts
  • Task flows
  • Prototypes (html/css/js, sketch, axure)
  • Usability tests

Details of each step below.

Stakeholder interviews

Based on the information I learned from stakeholders, I determined ways to leverage strengths and mitigate weaknesses of our existing database using SOLR’s features through a SWOT analysis.

Product strength and weaknesses hidden

Use case analysis

Based on the various products search would be used, I determined which design features would be important for each product. For example, while getting an insurance quote, a user doesn’t need to explore or organize information, whereas selecting the right car quickly has high priority.

Product details hidden

Design principles

I reviewed existing best practices for search design:

best practices for search design

Competitive analysis

I reviewed 3 categories of competitors to find common patterns for search, autosuggest, filtering, search engine results page, and mobile experience

  • Vehicle valuation tools (NADA Guides, Kelley Blue Book)
  • Vehicle purchasing tools (Edmunds, Truecar, Autotrader, Trovit, Cargurus, Classiccars)
  • General search tools (Amazon, Ebay)

Competitive analysis takeaways

  • Search input is rarely presented by itself; users can still browse and select from options
  • Help text provided on make/model/body etc. for novice users
  • Ability to save searches or filters
  • Filters show as breadcrumbs / back button leads to last filter
  • Show relevant content related to search (i.e. articles)
  • Pictures help in identifying correct vehicles

Proto-personas

To understand the spectrum of users, I created proto-personas, with the understanding that the tool needed to be credible to an enthusiast but understandable to a person who is new to classic cars.

example of expert enthusiast persona

Interviews with internal car enthusiasts

I met with internal car enthusiasts, database specialists, call center agents to learn common information needs and to review early-stage wireframes.

Findings

Users have difficulty finding correct vehicle due to differences in model/submodel names

“Sometimes people will get hung up on some of the submodels. Kind of a commonly accepted term for a car but we don’t list it that way bc that’s not how manufacturers did. 1965 pontiac gto: you can see here there is not 65 pontiac gto in the model. a lot of people don’t realize that it’s actually a 1965 pontiac lemans gto. so we do get some questions of why don’t you list that vehicle? it’s very common.”

Users have difficulty identifying correct engines.

“We have calls from widows who don’t even know what they have. even guys oragents will call? I’ll ask what hp? what motor? and they have no idea.”

Even when users know their Vehicle Identification Number (the unique number for their type of car), they might not always find the right car.

“The problem is that Chevrolet until 1973 didn’t encode what their engine was in the vin…so even in these really valuable cars, there’s nothing in the vin decoding that this is what the engine is.”


Based on the discovery work conducted so far, I narrowed my design goals for the two main products I was designing for.

Design goal for quoting (vehicle selection)

Primary design goal

How might we help users quickly search for their vehicle using commonly known attributes like year make model, or more specialized attributes like Vehicle Identification Number(VIN)?

Secondary design goal:

  • Help users navigate technical information such as VIN, body type, and engine type

Design goal for valuation tool (vehicle browsing)

Main design goal

How might we help users easily find the value of their car?

Secondary goals

  • Allow easy comparison of values
  • Promote browsing
  • Promote email account creation
  • Promote discovery of our company’s content and services (ex. Articles, drive sharing service)
  • Promote membership

Task flow

I created task flows to understand how the user would interact with the database.

example of task flow for search input

Solutions

I created two main prototypes, focusing on:

  • Vehicle selection, important for getting a quote on a vehicle
  • Vehicle browsing, important for engagement with the valuation tool

Solution for quoting (selection)

Happy state flow
Edge cases

Solution for valuation (browsing)

html protoype

Challenges and what I learned

  • I had to quickly learn 3 completely unfamiliar domains for this project — classic cars, databases, and search tools, which was interesting but a lot of information to digest.
  • This project never received dev resources, so it was doubly difficult during the research and design phase to not have ready access to developers who could provide more technical knowledge, and to prototype a complex interaction like search without dev resources. With the search input, I ended up faking a basic search in Axure, while for browsing I coded an html prototype. Although I was able to use these prototypes for usability tests, I found that the Axure prototype wasn’t accurate enough to be of value, and that the html prototype was unwieldy to update.
  • I split up my time in between designing the browsing feature as well as the search input feature, but looking back I would have focused more time on the search input feature, since it was both less complex and provided more value to the business.

Outcome

This project didn’t receive dev resources, and I ended up handing off design documentation to a hired agency. Ultimately, I believe a complex interaction such as a search requires close collaboration between design and dev, as well as user validation, and that design without dev or user validation is at best a hypothesis. However, whatever the outcome, through this project I learned a lot about the company I was working for and created artifacts of how users interacted with an important product of the company.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade