TL;DR

I wireframed, architected, tested, and comped the experience of comparing products for JCPenney, a clothing and homegoods retailer with more than 100 years in business. My department, Omnichannel, was responsible for screens for all breakpoints - desktop, tablet, mobile (RWD, iOS and Android), point of sale, and in-store kiosks.

My Position

At its height the Omnichannel design department had fewer than 10 full-time employees. Every product owner and department in the organization needed work from this department, and with the precarious financial situation of all legacy brick-and-mortar retailers, demand was huge, retail time pressures were intense, and every project was underfunded and overpromised.

For Project Silver, the new top-secret product line, I was responsible for

• leading the project design team

• rolling my sleeves up to pitch in whenever anyone needed it

• usability and interaction design guidance

• ensuring designers’ work on tight timelines

• meeting and negotiating with developers, appliance manufacturers, and product owners

• information architecture

• prototype creation for usability testing

• protecting the design team from “the heat” and reflecting light

• making sure the team was motivated and productive despite the pressures placed on it

Appliances, as big-ticket items that were a natural match for the homegoods JCP is known for, was expected to help bolster the company’s bottom line, and possibly bring the company out of the red.

One of the features that was mine from inception to execution was product comparison. This simple-sounding feature is very difficult to design well, especially for mobile.

Comparison Design Challenges

Designing comparisons requires a lot of thought. The interaction design is critical for comparisons to be useful to customers, and many sites do it just a bit wrong.

It’s also not uncommon for companies to “give up on” mobile comparison design. During my research, Apple forced the user to switch to landscape to view product comparisons, and several sites simply didn’t offer comparison at all.

Part of my content philosophy is that whatever’s available on your desktop site should also have an equivalent mobile-optimized experience. Several times I have been stuck with just a phone in other countries (Canada, Korea, Taiwan) with a NEED for a website’s feature, only to find that the feature’s not available on mobile, sorry! Best of luck! Each time I had to go to an Internet cafe or other shop with a desktop machine, pay for time on that machine and then pay for a printed copy of whatever I needed. Not a good user experience (I’m looking at YOU, Ticketmaster).

Common challenges for comparison that my designs worked to mitigate are

• Displaying that an item is “selectable”

• Making selection easy (especially on mobile) without clicking through to the product page

• Showing products that have already been selected

• Disallowing selection of more items than the comparison is designed for (usually 3-4)

• Guiding users to the comparison page

• Showing the information on the comparison page that customers want to see

User Flows & Wireframes

I needed to first explore the user flows agnostically. I created flow diagrams for a few of the competitors, and noted where those did not work as I wanted them to. With the findings I gathered from those, I created a flow diagram for JCP products.

To make the interactions I’d conceptualized in the user flows into reality for all of the designers on this project, I made a paper wireframe with arrows to use to describe the design and interactions.

Page Designs

Gallery - Initial

The gallery page design kept the comparison interaction subtle - customers check the boxes to select which items they wanted to compare, but could still view all available products in their search.

Gallery - 1 Selected

With one item selected, the comparison interaction had been initiated. I chose a light, clean overlay with a simple way to remove an item from the chosen items.

I also included a disabled compare button. It gave affordance that this is a comparison interaction, and an instruction on what the user would need to do to enable the button (instead of making them guess or confusing them).

Gallery - 2 Selected

It was decided to keep product comparison to two items on mobile - this compromise would allow for a portrait AND landscape view of the same design without removing any of the usability, or requiring an unintuitive horizontal scroll.

With a second item selected, the comparison button would be enabled, and the instructive microcopy changed.

Not too many, though, OK?

I wanted to keep a customer from selecting too many items and getting an error for “overdoing it”. Good interaction design doesn’t punish users with errors - good design prevents errors.

To prevent over-selection, I implemented the following:

• Enable the bright red CTA to draw the eye from the gallery items to the comparison overlay.

• Disable the comparison checkboxes but not remove them - removing could cause confusion

• Making the compare checkmarks bright green so they could be easily spotted, even if the two items are far apart on long scrolling pages.

Comparison Page - Initial

A good comparison screen has the following elements:

• Photos, reviews, pricing for the items

• Item removal

• Back to the gallery page you’d just left

• A purchase intent CTA

• Add to Favorites

• Comparison facet labels (Availability, Capacity, Size, etc.)

• Comparison facet data ($399 delivery fee, 3.5 CU FT, etc.)

Check this out

An innovative feature I hadn’t seen anywhere else that I wanted to introduce was “see differences”. This would allow you to see where the two items differed - very useful in a comparison.

Comparison data is vast for each item, much of it irrelevant to one user, but critically important to another. The vast amounts of data are especially difficult to wade through in-app, and there could be critical differences that’re easy to overlook when all data looks the same.

My solution was to highlight the differences between facet data - this would not only help users see where these two products were distinct from one another, and possibly also to point out where an item was chosen for comparison in error. Nobody wants to buy a refrigerator that’s too tall for the space.

NOTE: This feature ended up not being developed. If API data from different manufacturers differed in so much as a single space, that data would be “different” to the comparison engine, even if 5’ and 5.0’ are the same numbers to humans. There are ways to resolve , but they are not easy or cost-effective to implement without an investment in AI or extensive programming, which was most definitely not in the budget.

Delivery Constraints

Another concern was the extreme variability in availability by zip code. State and local laws, warehouse locations, product distribution, and a host of other factors influence whether a particular appliance is available in a particular location.

In the event that a customer had not chosen a “home store” in the UI (which was not drawn from their “home address’), or wasn’t authenticated/logged in - which turns out to be a whole lot of people and not an edge case - availability to a particular zip code couldn’t be displayed. This required a request for a delivery zip code.

Unavailable Products

Unfortunately it was impossible to programmatically determine why a product was unavailable in the user’s area, as it wasn’t included in the API. A majority of the reasons for a lack of availability are out of the user’s control, since appliances are physical things going to physical places that are most often stationary.

In the event that an item was unavailable, I had wanted to disable the Add To Bag button, but a common belief in the organization was that that was “bad”. No one knew why, just that it was.

I was unable to disprove an anecdotal belief, so I compromised by disabling the item itself, and suggesting that it be removed from the comparison, along with an explicit notification in red under Availability that this product was not available.

Epilogue

See more of the mobile screens I worked on for this project.

Project Silver launched across Omnichannel, and this feature was included in V2. JCPenney no longer sells appliances, which is a shame for the Omnichannel people who worked so hard to bring the various stages of launch to fruition.

This project was one of the most stressful, difficult projects I have worked on. Emotions were high in every department and every meeting, the pressure to get it right and not cost more money than absolutely necessary was intense, and the regular cadences for our established Agile processes were thrown out to meet ecommerce holiday deadlines.

But I learned so much in that one project, met so many people, and performed every UX and UX Lead duty possible, and I am very proud of my contributions.