Sainsbury's Self- Checkouts
Overview
Goal
Role
Our goal is to develop an internal checkout solution to:
-
Reduce dependency on legacy systems
-
Gather comprehensive data on SCO (Self-Checkout) usage (currently unavailable)
-
Respond rapidly to evolving customer and colleague needs
-
Deliver a flexible, cross-device solution
-
Foster innovation in the checkout process and gain full control over the user interface
Launch a fully operational self-checkout with the following features:
​
-
Scan items
-
Add loose items
-
Process card payments
-
Add items via barcode
I led design, research, and testing, collaborating with developers, UI designers, and researchers. I gathered insights, refined concepts, and iterated on feedback to ensure the product was thoroughly tested and optimised.
Journey mapping
Creating an up-to-date journey map was one of my priorities. I wanted to ensure we captured as much information as possible before moving forward with other aspects of the project. This process not only helped identify gaps in our research and data but also highlighted key areas of the business where further collaboration would be necessary.
Research & Discovery
To kick off the project's research phase, we collaborated with internal teams and external partners to conduct comprehensive customer research. This included a mix of user interviews and in-store observations. Our primary goal was to gain a deep understanding of customer behaviour around self-checkouts and identify any pain points. User interviews proved especially valuable, providing insights into general shopping habits and specific challenges and expectations regarding the checkout experience.
I value store observations as a powerful research method, allowing firsthand insight into customer behaviour and pain points. During this project, I frequently conducted observations and spoke with customers and colleagues to identify key issues, particularly around interventions. The chart above captures the type of intervention, its impact on customers, and potential effects on colleagues.
60%
Of customer observed
needed help from a colleague
Running themes...
From research and discovery, we learnt the following from our customers:
-
Lack of control over their shopping experience.
-
Little seating around UK supermarkets
-
Interventions (Think 25, scales etc)
-
Little feedback to the customer e.g. not clear when a customer has qualified for a promotion
-
Self-checkout environment & signage (Unclear when SCO’s are free, little space in-between SCO’s)
Intervention discovery
Interventions at self-checkouts are complex, so I created a system map to track when they occur, how they affect customers, and how colleagues respond. The map also shows the “tri-light” status—red for urgent help, green when the checkout is running smoothly. Contrary to common belief, the tri-light is for colleagues, not customers, and this misunderstanding often contributes to congestion in the self-checkout area.
​
A common misconception is that the tri-light shows checkout availability for customers. In reality, it’s for colleagues only; green simply indicates the checkout is running without errors. This misunderstanding often causes congestion in the self-checkout area.
Using this map, we could identify which intervention could potentially be self-corrected by the customer. To do this, we could review what feedback we are giving to the customer, and could we improve the feedback to help customer correct their mistakes.
Findings on customers with accessibility needs
62%
Would use a self-checkout
Why?
​
-
It's quicker
-
They can go at their own pace
-
Avoid interactions
38%
Wouldn't use a self-checkout
Why?
​
-
58% - lack of space around the SCO
-
52% - difficulty calling for help
-
51% - difficulties filling the bag
We found that our customers with access needs want to use self-checkouts; however, in their current state, it proves incredibly difficult for these customers to do so for the following reasons:
We knew when designing the new self-checkout, we'd have to collaborate with our accessibility specialist to ensure that we were using correct font sizes, contrasts and optimising the screen's touch points to make sure all CTA's were in reachability. It also meant we would need to look at developing some features for our SCOs that we currently don't offer, such as dark mode, font scaling, etc. However, by doing this, we would put ourselves ahead of competitors, as very few retailers provide any accessibility features for their customers.
Current UI
Welcome screen
-
The background image is too chaotic
-
50/50 pathway creates doubt
-
unclear for SmartShop
-
Small copy
Basket screen
-
Product tile is inconsistent with SmartShop
-
subtotal and savings are very small
-
grey CTA's fail accessibility
Payment screen
-
Savings are too small, loses value perception
-
amount due too small
-
payment icons outdated
Fail fast
Wireframing
Design phase 1
Design phase 2
During this design process, I aimed for the team to fail fast through user testing. I broke up the screens into areas and tackled them separately, i.e Promotions, product tile, interventions, product look up & value perception. By breaking up the screens this way, it allowed us to focus on the customer experience based on goals we wanted to achieve for the user, i.e, customers understand when they have scanned an age-restricted item, and customers understand how to add a loose item.
We used UserZoom to conduct fast testing and validate any hypothesis we might have.
Hypothesis validation
As mentioned, we broke the screens up into themes & experiences. An example of how this worked well is the product look-up menu. This menu is where customers would add their loose items, i.e fruit and veg.
To improve the PLU menu, we first mapped its journey and structure—similar to a website sitemap—due to its many layers. From this, I ran “how might we” sessions and hypothesised that making loose items easy to find would speed up checkout. While we assumed an A–Z listing might work, we needed to validate it.
Card sorting
We set up a userzoom test that tasked our participants to card sort loose items into categories they felt fit right. Lo and behold, we found our users carding sorting into single categories such as "Apples" ", Bananas", rather than "exotic fruits". This started to validate our theory
Peppers
Potatoes
Tree Jacking
Confident in the A–Z approach, we ran a test with three categories—Fruit, Vegetables, and Bakery—listing loose items alphabetically. We compared this to the current PLU menu and found customers located items much faster using the A–Z format.
Implementing the experience
Existing UI
Design concepts
Testing the experience
Through testing, I validated that users were able to find where to add loose items from the basket screen, and then successfully add the items I was tasking them to look for. We planned to test this further once the designs have been developed and released onto a working prototype.
Collaboration & Stakeholder Management
Working with the product manager, we highlighted who our key stakeholders were and ensured we were working with them to deliver expectations for the project. I value working in the open and believe this to be the best way to be completely transparent about the progress of a project, not only transparency, but it's also important to value stakeholders' ideas and feedback. To achieve this, we would send out regular newsletters and also invite stakeholders to collaborative workshops.
Collaboration was something I wanted to be consistent with throughout the process; this involved lots of design pairing with other designs and developers. Building relationships with those close to the project was really important and the best way to stay on a happy path. I would often arrange ideation workshops and involve product and developers; this allowed for ideas to be generated from all sorts of backgrounds.
Design pairing
Design pairing is one of my favourite things to do when working on a project; it allows designers to work in an open way and have their opinions and ideas listened to. Not only that, it helps build a respectful and creative relationship, and often allows you to take a step back when you feel stuck on something. Pairing with the UI designer was a daily occurrence, and not only did it allow me to develop my own skills, but it's meant we were constantly working in a fast, fluid way, and working towards the same goals for our customers
​
What about the colleague experience?
Existing UI
Design concepts
Overview
Colleague mode allows staff to correct interventions, fix hardware or pricing errors, issue receipts, and more, but it’s highly complex and varies across SCOs and software versions. Through store visits, we observed that colleagues were comfortable using it and had developed shortcuts to complete tasks efficiently. However, customer research revealed that seeing colleagues in this mode caused anxiety, as the interface appeared technical and made them feel they had done something wrong.
​
We hypothesised that redesigning colleague mode to match the customer-facing UI would reduce this anxiety while also making it easier for colleagues to use. I took prototypes into stores and conducted user testing with colleagues, which allowed us to iterate quickly, adapt to their feedback, and demonstrate that we valued their experience and insights.
Hardware & formats
As we were starting from scratch, this allowed us to look into new hardware for our self-checkouts. This involved meeting with third parties and trialling their equipment. This would range from various screen sizes, scanners, tri lights and payment units. Not only did we need to look into new hardware, but it also posed the question of the self-checkout formats and environment. We'd already highlighted through research that the format and hardware weren't working in many ways for accessibility, so how might we tackle these issues? ​
Landscape
vs's
portrait
The hardware we were considering meant that we could explore designing the self-checkout in portrait orientation. This is something we were excited about, as it's something we are currently unable to do. We decided to make core screens in portrait orientation so that we can test between the two. We had a hypothesis that portrait orientation would be better for accessibility, and also would allow for more scanned products to be visible to the customers.
The build
Getting the build onto the hardware was challenging, taking months to connect to the network, which initially prevented item scanning. Once connected, we tested the self-checkout in the lab and identified areas for improvement, such as font sizes. This also highlighted the lack of a design system or guidelines for digital screens, which would help ensure accessibility and reduce back-and-forth with development.
TO BE CONTINUED...