Can I Have That in Coastal Cedar, Please?

An Interface for Exploring Complex Products

At Home Depot, our associates are constantly working with customers to determine which products they need, assess their options, and make informed decisions about what to buy. It’s a very busy environment and time is precious for both the customer and the associate.

The QuoteCenter application gives associates access to a vast catalog of products — both stock and special order. Some of these products have a number of options like color, length, and edge type. For these more complex products, we needed an interface that would simplify the process of exploring and selecting options so that our store associates could focus their attention on selling stuff and serving customers.


The Project

I was given the responsibility to redesign our interface for exploring product options, handling the interaction design (which included a significant amount of prototyping) as well as the visual design.

Here’s how I went about it:

  1. Defined the problem we were trying to solve
  2. Defined the desired outcome — what success would look like
  3. Sketched options for a new layout to address some known issues with the current design
  4. Built a coded prototype and iterated through a bunch of interaction design details
  5. Added some helpful cues to the visual design
  6. Supported our team’s lead developer to implement

The Problem

Home Depot associates need to be able to freely explore all of their product options as they reconcile what their customer is asking for with what is actually available.

This is the interface I started with. There were some glaring problems with the layout, interaction design, and visual design.

This was the design of the product information page at the time. The vertically-stacked layout for the product options made poor use of screen real-estate.
In the left-hand image, the 12' option looks disabled but is actually clickable. When you do click 12' (see the right-hand image), your selected color does not persist and the interface appears to be in an error state.

The Solution

After defining the problem, I envisioned what a successful outcome would look like: an associate should know what their options are and be able to confidently select a valid combination.

Sounds simple, right? Read on.

1. Layout

We needed a more condensed layout that made the best use of screen real-estate, and enabled users to take in the whole “landscape” of product options at a glance.

Sketching lets me fly through concepts without investing too much time.

I narrowed my ideas down to 3 different concepts, weighed the pros and cons of each, and settled on concept C, seen below — a series of horizontal button groups. It not only maximized vertical real-estate, but was also well-suited for our responsive layout, allowing us to maximize horizontal real-estate by using an overflow menu. Most importantly for our users, it makes their options visible at a glance.

Concept A did a decent job of showing the categories of options, but could only display one option within each category. Everything else was hidden behind a click. Concept B could only display the categories, which meant clicking was unavoidable. Concept C allows all categories and most of their options to be visible at a glance.

2. Interaction Design

Having searched and landed on a product page, associates’ next step is to inform their customer of their options, and then select a valid combination of those options.

Designing for Exploration

Associates needed an experience that would build their confidence in what was available so they could have a natural conversation with their customer.

Imagine you’re the customer in this scenario:

Customer: I need some composite deck boards for an upcoming job…
Associate: We carry those. Any specific brand?
C: I usually buy Trex.
A: Looks like there are a whole bunch of colors — Brazilian Walnut, Coastal Cedar… 
C: Some kind of gray. Seaside Gray looks right. Those should be 16' long.
A: Okay, I selected Seaside Gray but it’s not letting me click 16'… 
C: Really? You don’t carry 16 footers?
A: I thought we did, but my system isn’t letting me do that length. Hold on, let me try something else…

Notice what happened. Everyone’s attention switched from the sale to the system. This is a common occurrence for our store associates.

Everyone’s attention switched from the sale to the system.

My design helps to prevent this by first allowing an associate to select whatever the customer is asking for, and then explore what their other options are given their past selections.

There are no dead ends and no prescribed sequence. It’s a non-linear workflow.

Creating a Coded Prototype

It didn’t take long for me to realize that written descriptions, sketches, and static mockups wouldn’t suffice for designing more complex interactions, so I created a coded prototype using HTML, CSS, ReactJS, and MeteorJS.

This means that I can actually experience the interactions for myself, and effectively explain them to development, product management, and the broader design group.

I often turn to code for interaction design projects like this. There are few other prototyping mediums that get me highly realistic results faster than code.

Designing for Confident Selection

Shortly after I settled on a non-linear, exploration-friendly workflow, a variety of questions arose:

  • How should the interface handle the selection of invalid combinations?
  • How should the interface convey which combinations are and aren’t available?
  • Should the interface attempt to communicate the reasons why a combination is invalid, or simply that it is?

After a series of iterations, I landed on the following design.

This is my prototype in action.

I decided we would allow users to select invalid options, and that their past selections would persist. This means they could end up in an invalid state. To explain this state, I designed a simple message for this state — “Your selected combination is not available” — because it seemed like the most natural way to let users know what was going on.

3. Visual Design

This interface required some thoughtful visual cues. There were four primary problems I tackled in the visual design:

  • Which attributes should be shown as invalid?
  • How do we acknowledge user intent when they select an attribute?
  • How do we prevent it from feeling like a dead end when their selected combination is invalid?
  • Where should labels like “Color,” “Length,” etc. be placed for maximum usability?

The “Glimmer of Hope”

The three concepts below portray different visual approaches to the same underlying logic. In all three concepts, 16' was selected last.

Notice how only the third concept (on the far right) makes it feel like you have a path forward. We called this our “glimmer of hope” style, because it makes you feel like the system is moving you forward with each subsequent selection, instead of making you feel like you’ve reached a dead end.

I felt like there was a relationship between recency and intent: the more recent the action, the more likely it is to indicate user intent. That being the case, the design should put more weight on recent actions than on older ones.

The system is moving you forward with each subsequent selection, instead of making you feel like you’ve reached a dead end.

Emphasizing Invalid Options

While I had already designed some simple messaging for when users are in an invalid state, I thought it would be desirable to help them steer clear of that state altogether, or at least set the expectation that if you click this option, your selected combination will be invalid.

I did this by adding a subtle diagonal line to the button’s background. This was pleasantly easy to do with CSS!

Label Placement

Finally there was the issue of where to place the labels (e.g. “Color,” “Edge,” etc.). Should they be inline with or above the button groups, aligned left or aligned right? I ended up following the recommendations in this eye-tracking study by Matteo Penzo, placing the labels above the button groups, left-aligned, small, all-caps (for readability), and non-bold.

I settled on the design in the lower right.

Conclusion

On its face, this sounded like a relatively simple problem to solve. I had been involved in at least two previous design iterations on this exact interface but this time I dove deeper than ever before, and in the process discovered a level of depth and nuance that I had not expected.

My attention to detail and thoroughness in thinking through both the system’s logical states and associates’ real-world needs paid off big time here.

I’m also glad I invested in a coded prototype. Having one isn’t always worthwhile or necessary, but in cases where the details of the interaction design matter so much and where the logic is relatively complex, it’s a big time-saver. I was able to work much faster in CSS, ended up making better decisions and was able to foster team alignment on the design more quickly.

Show your support

Clapping shows how much you appreciated Ben Berkompas’s story.