Search & Discovery

Focusing on the user; Inspiration comes from anywhere

Background

"Finding a screw is a pain in the [explicative]. Is it Mil-spec? What drive system, head style, diameter, and thread? Machine screws are not all the same. What material? Oh, and what if I need 5,000 of 'em? Sometimes, if they don't have enough, I'll get something like it, like with a different length, but same diameter...it depends if they have a CAD file I can use to test it first."

- Quote from interview (2013)

Most of my work is covered by non-disclosure agreements (NDA). What I am sharing is just the tip of the iceberg.

Contextual interviews, modeling, rapid iteration, HTML, jQuery, CSS, illustration

Summary

As Senior UX designer, I worked closely with stakeholders and peers in Search, Detail Pages and Photography to create an experience unlike any other at Amazon.

Time constraints & resources

Because search & discovery were key to our expanding selection, we had less than 2 months to develop the UX for each component:

  1. Search results
  2. Search refinements
  3. Parent / child detail pages
  4. Variation tables

One size does not fit all…

Shortly after joining Amazon, I was asked to decrease search-related customer service calls. The calls revealed the buyer was often not the end-user and unfamiliar with the product. Realizing the problem began upstream, I sought to better understand the following:

  • How does the requester identify the part they need?
  • How is this need communicated to the buyer?
  • How are details communicated to the buyer?
  • How does the buyer, if not a subject matter expert, assess if the part matches the request?
  • How does the buyer identify workable substitutes from a pool of potentially 3000 nearly identical options?

Communicating our findings

With help from industry representatives, customers, and customer service reps, we created stories addressing each question, which I sketched as a series of storyboards that we printed and shared with others (see example below).

Sketch of process flow

Turning problems into solutions

The epic of "fixing search results" was broken into 5 tasks:

  1. Improve the usefulness of photos and titles
  2. Surface relevant categories
  3. Surface appropriate search refinements
  4. Enable customers to scope their results and compare scoped results
  5. Enable customers to identify and evaluate options within a family of results

Task 1: Improving photos and titles:

  1. We created a hi-resolution photo studio and photography style guide. The photos were so effective that, on occasion, manufacturers asked to replace stock after discovering imperfections visible in our photos.
  2. We rewrote item titles so comparable attributes appeared in search and personalization widgets.

Task 2: Surfacing appropriate categories:

Working with Amazon's search service, we re-prioritized the results to return matches in business-relevant categories.

Tasks 3-5 required additional UX invention…

Example of high-resolution photo
Example of high-resolution photo
Example of high-resolution photo

Examining how needs are communicated

To understand what constituted relevant results, we needed to understand what drove customers' choice of keywords. Examining the steps by which needs were translated to orders revealed how businesses relay, prioritize and optimize sharing product details. Our findings included:

  • Engineers requiring fasteners for an engine extracted the dimensions from CAD diagrams and pasted these into emails
  • In instances where the relationship with the buyer was less formal, a stickie with details and sometimes a sketch was stuck to the EA's monitor
  • In many instances, teams used spreadsheets of vetted parts for reordering
  • Attributes and images were the primary and secondary means of communicating details. When participants were asked to identify industrial products; the names varied by industry, brand and even by region
Example of Post-Its on buyer monitor

Example of stickies used to convey information to a buyer.

Helping customers think faster

Images vs. text

Guerrilla tests revealed the efficacy of visual or textual refinements depended partly on whether the initiating requests were visual or verbal, and to what degree the buyer was familiar with the product:

  • EAs familiar with products did not require images
  • EAs unfamiliar with products did not require images, however, they felt more confident with choices using images when the request included a visual element (i.e. a sketch)
  • In both cases, images reduced time spent refining results and improved discoverability

Combining a simplified image and text, reduced required time and errors for 100% of interviewees.

A new visual language

To design the refinements, I tested 2 hypotheses:

  1. Processing visual information requires effort. Each visual element increases cognitive load and decreases the speed with which individuals can assess differences.
  2. Most engineer-buyer stickies are sketches - a distilled visual language; the further our refinements deviate from these simplified shapes, the more variables buyers must process.

I guerrilla-tested 12 drive style selectors comparing simplified iconography and high-quality photos, asking participants to identify an attribute and timing their response. All participants performed better with iconography, especially when the request included a sketch.

Using these results, I created a detailed style guide that reduced visual variables for comparison while retaining sufficient context for identification.

Additional research

Several articles I have found since then provide additional insights include:

Building a better visual picker

In 2010, visual pickers consisted of a sprite with 5 variants, one for each state: default, active, focused, disabled, and visited. Consequently, 4 visual pickers required 20 images! (see example). Our refinements had upwards of 50 variations; we needed a scalable approach.

Starting with the tenet that content is separate from function, I created one image per refinement, then used HTML and CSS to support all 5 states.

The result was a patent pending concept that sandwiched a PNG in HTML layers, allowing backgrounds, overlays, and borders to convey the visual picker's state.

Results

When implemented for fasteners on SmallParts.com (precursor to Amazon Business), the result was 85% lighter than other Amazon visual pickers and helped reduce customer service calls for fasteners by nearly 60%. It was so successful that the solution was rolled out across all industrial categories.

Adoption

Initially, the Amazon.com search team was reluctant to adopt the new solution, citing the additional work needed. To show how easy it was, I built a prototype using their existing HTML, CSS, and JavaScript, and presented it to their product manager and principle designer. Before I could finish demonstrating the prototype, the principle designer interrupted, exclaiming, "This already works? I say we adopt this now!"

And they did. It is now used across Amazon (see example).

Common sprite with images for each state - note, only 4 variations
Sprite for head styles - note, 25 variation, including a zero state
Schematic explaining architecture of visual picker code
See example of visual pickers in the left refinements of search on Amazon.com
Visual Pickers on Amazon.com

Helping customers pick the right one

Dimension-driven products, can have over 2,000 variations, while consumer products may have 20. The "twister" solution, used for consumers, could not scale, and instead resulted in a "whack a mole" experience when the number of variations exceeded 5. A new solution was needed, so I turned to our customers for inspiration.

After a few site visits and lengthy phone calls with customers, I laid out a storyboard showing how engineers, EAs, and professional buyers navigated options. Their tools included spreadsheets, 5-inch thick catalogs, websites and technical publications.

Laying these all out on the floor, I realized a common thread; they all used tables!

Cross-referencing our customers' tools, I created the following tenets:

  1. The table is a reference; it doesn't need all product information
  2. The table must be malleable; customers need to filter and sort to "build" a comparative subset
  3. The table must reflect search-refinement choices (i.e. length) made upstream
Example of catalog used by buyers
Example of catalogs used by buyers

Building an Amazon-worthy table

Amazon is regularly touted as the model others follow. Knowing this design could end up influencing UX across the industry, I wanted to make sure it was worthy of emulation.

Referencing the work of Edward Tufte and sites such as ESPN and NYSE, I developed a table based UI:

Component Benefit
Variations Sortable and filterable, allow customers to identify a single or range of solutions
Price Indicates that each row is an offer; also allows price comparison
Part number Ideal for part-matching and referencing
Availability Controversial at first; allows buyers to determine if sufficient quantity is in stock for bulk purchase

Further examination of our customer data revealed roughly 20% of our customers purchased 2 or more variations during the same session. Storyboarding their tasks revealed users wanting to purchase more than one variation would click at least 6 times (see comparative storyboard).

To reduce the path to one step, I designed a mini detail page with an "Add to cart" button that did not leave the page. (see example).

Implementation

After testing the designs with EAs and professional buyers, I built and tested the front-end HTML, jQuery and CSS for the experience.

Example of ESPN data table
Comparison of effort required to purchase multiple items

Setting the standard

The tables were a success (see example). Not only were the number of calls to customer service reduced, but the tables were emulated across the industry. My concept of a parent detail page with a table of variations, part number, quantity selector, and in-table purchasing can be found in leading sites such as Grainger and Fisher Scientific.

The tables are so well-received that a few years ago, we ran an experiment to replace the tables with a smarter "part-lookup." The overwhelming feedback? "BRING BACK THE TABLES!"

Further work

In 2014, the tables matured through the work of Ajay, a UX intern on our team. Working with myself and others, he evolved the concept of the "mini-detail" page, with great success on Amazon Supply. Unfortunately, before the UX could be implemented on Amazon.com, Amazon Supply was rolled into Amazon Business, and the improvements were deprioritized.

Example of variation table appearing on Grainger Example of variation table appearing on Fisher Scientific