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.
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:
- Defined the problem we were trying to solve
- Defined the desired outcome — what success would look like
- Sketched options for a new layout to address some known issues with the current design
- Built a coded prototype and iterated through a bunch of interaction design details
- Added some helpful cues to the visual design
- Supported our team’s lead developer to implement
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.
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.
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.
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.
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.
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.
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!
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.
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.