Best Buys Comparison Table
Project Overview
In my previous case study “An Evaluation of Best Buys”, when completing user research we identified a strong pain point of users, centred around the ability to compare products within an article. It was my role to take the insights I generated and come up with a solution.
The Problem
Currently, users are having to scroll the articles up and down multiple times to compare products. This creates frustration from the users as it causes friction in the research phase. Additionally, users are complaining that there are not enough details about the product itself. Users are having to go onto the manufacturer or retail website to gain this information. These insights were gathered via multiple user interviews.
Defining our Users
To help align all stakeholders on this project, I created personas based on the research to remind people who we are trying to design for. The personas were created to better align people who have not had time to read the research report. The first focused on users who are in the exploration stage. They are trying to gather as much information as possible to create a potential list of products/services. While the second persona focused on users who are in the evaluation stage. Where they have a list of products/services and are trying to pick one to purchase.
Discovering a Solution
Looking at competitors of Best Buys (Vergleich, Wirecutter & The Strategist) I noticed a common theme in how each business address this problem. Each competitor in one form or another had an area in the article with a table comparing specifications between products. This approach linked in with comments made by users during the research stage. A few of our users commented saying it would be easier to have the information in a table format. An example of this is “You're just seeing an image and it's hard to compare between them when they're not on a table. They just all listed one after the other. And there's no list they're not listed in terms of price. They're not even listed in terms of which one's the best. It's just a random list.”
Designing the 1st Draft
Before creating my 1st draft of how this table would work I wanted to gather some inspiration from third-party websites and read articles on how best to tackle this design. While I had the competitors to look at, I also investigated how retailer sites approach this option and how google compares products on their shopping pages. Additionally, I found articles from NNGroup, Medium and Baymard helpful resources to look at.
Once looking at the resources, I took to Figma to sketch out how I envisioned the table working. My first draft split the table into three sections. The first is to display the name and product images, the second to house the price, CTA links and consumer ratings and the last to present all the product specs. The user could filter out products that didn't concern them and they could navigate left to right similar to a carousal if products were hidden by an overflow.
The 1st Stakeholders Workshop
Once I was happy with the first draft, I ran the first feedback session. I tend to have a limited amount of stakeholders in the first workshop. In this instance, this was the wider product team.
Over my years of being a product designer, I have honed the skill to run an effective feedback session. During my early years as a Product Designer, feedback sessions tend to focus too much on one section of a feature or product, while not looking at the proposal as a whole.
The way I now run stakeholder workshop is I present my proposed design to the audience and then set a timer for them to add sticky notes on a Miro board. The sticky notes tend to be coloured to categories them between feedback and questions.
I then take the feedback offline and sort out what stakeholders have posted on the sticky notes. From the first session, the most common feedback could be categorised into three sections.
- Including product badges. These are badges we place on our product card component to highlight a featured product.
- Including different cell types in the table to visualise data in more than one way.
- Questioning how we would have a consumer rating feature that kept up-to-date on users' ratings.
Addressing Feedback
Adding in the product badges would be the easiest feedback to address. We could readily convert a badge into a cell and use the same icons to represent a featured product. However, to take it a step further I added new badge types to highlight other products that would assist a user that's in the evaluation stage.
To add more cell types, I looked at the type of products we tend to recommend in our articles from technology to skincare and then assessed what type of product specs they have. From this, I deduced we can add an icon type cell (mainly for ticks and crosses), text cell and hyperlink cell.
Lastly, when adding in the consumer rating during the 1st draft I did investigate how this would technically be done. We would pull through data using an amazon API. As a large majority of products we recommend are sold on Amazon, it would suit our needs. This resulted in not needing to change the design but just explaining this during the next feedback round.
The 2nd Stakeholders Workshop
My second stakeholder workshop was with a wider variety of team members. We had stakeholders from sales, management, editorial and product. As before I had the same set-up of explaining the designs and giving a set amount of time to provide comments with a feedback sticky note or a question sticky note.
After collating the feedback, the comments I got were the following;
- The first release of the comparison table will only compare up to 3 products. Therefore focus on optimising for fewer products than I was designing for.
- Move the table higher on the page, to allow users to discover the table quicker.
- Having the function to enlarge the product image, as they can be small to see.
The feedback above was easy to implement within my design. I was able to get this signed off and moved to the next step.
Developer Specifications
Once the design was signed off I then worked on getting this added to our Figma design system known as Pico and getting all the documentation needed for our developers.
In Pico, we provide the different states as variants. We supply the designs on how they work on different device viewports and then annotate them to provide supplementary information to our devs.
