What is needed to make a self-checkout that isn’t awful? (Redesigning Self-Checkouts, Part 2)
Welcome to Part 2 of Inktrap’s self-checkout case study. If you haven’t read part one, you can do that here. Before we get stuck into Part 2, let’s have a quick summary of Part 1.
Everybody seems to hate self-checkouts, and here at Inktrap, we wanted to know why and how they could be made a little more bearable. In order to find out a bit more, Liz and Rachel went out into the world and did some guerrilla research, watching people use self-checkout machines and interacting with them themselves to see where the pain points occurred. We went over our assumptions and the reasons we found people do and don’t use self-checkouts.
Taking a look at the user flows
After getting a basic understanding of what draws people to the self-checkout machines and what puts people off, we decided to take a look at each different shops flow to see what are the necessary screens in the flow and what some stores think are optional.
What do all self-checkouts have in common?
We wanted to know the common screens so we could see what would be needed in our own flow, but we also wanted to see the extra ones certain stores added in and to think how these extra screens could improve (or worsen) the flow. We wrote each step of the flows onto post-its and stuck them on our whiteboard. Here we could see that all stores have the basic core screens in common, which are:
- Start screen
- Scan items screen
- Select payment
Around these three points, other supermarkets added in some extra screens, with most adding a “number of new bags” screen and a “thank you” end screen. Waitrose added in a screen asking customers if they had a loyalty card, Tesco and Waitrose had a “payment instructions screen” and Sainsbury’s and Tesco avoided paper waste by having a “would you like a receipt?” screen too.
Pain points…
After we had a clear understanding of the screens in most self-checkout flows, we took a moment to plot pain points we had observed in our research. After doing this we could clearly see that there are three major areas where pain points occur: with the layout of the store itself, whilst scanning and searching for items, or whilst paying.
Shop layout
- The shop layout again and again confused users and made the general experience more unpleasant, no matter how good the machines themselves are.
Scanning and searching
- After scanning items, a number of people were lost as to how to proceed.
- Others were frustrated with the responsiveness when scanning items.
- A fair amount of people were confused when searching for items that needed to be weighed.
Paying
- Customers wanting to pay with vouchers had an issue attempting to use these with the machines and had to seek help from a member of staff in order to use them, which negates the usefulness of the machines themselves.
- A number of people had problems paying with smartwatches.
Coming up with a spec
Now we had a clear understanding of what screens were needed and where pain points occurred we could make a specification for our own self-checkout. We separated this into 3 elements to give us a clear idea of what we were doing — how we would reduce pain points, our flow’s must-haves and the screens we would include (and a very brief outline of what would be on them.)
Reduce pain points
- Unhelpful error messaging blocks the user. We will offer a solution and clearly state that help is on the way.
- A lack of guidance means users can get lost. We will provide a suitable amount of guidance, helping the user without patronising them.
- It can be unclear when/how to pay. We will ensure this element of the flow is clear and simple.
Must-haves
- Consistent UX and messaging.
- Efficient, responsive and quick.
- Plain English.
- Minimal UI.
- Cater for people who have their own bags.
- “Finish” confirmation before payment.
- Discounts applied instantly.
- Accessibility.
- Summon assistance.
Screens
We considered the screens that each supermarket included in their flows and worked out a suitable set of screens for our flow. On one hand, we wanted to cut out the screens which felt like unnecessary additions. On the other hand, we didn’t want to reduce the flow so much that it would feel rushed and therefore more confusing for the user. Our final flow was decided as:
- Start screen. With an “own bags?” option.
- Scanning. A receipt-like list of products and “search”, “assistance” and “finish” buttons.
- New bag. A screen where customers can add 5p plastic bags as needed.
- Select payment. This screen will be optional, meaning users can simply tap their card or put cash in and the machine will accept payment, but there will still be buttons for “card”, “cash” and “other” to make the payment options clear.
- Receipt. To avoid waste we will ask users if they would like a receipt. This screen will be on a timer so if they don’t select either option it will time out to allow the next customer to start.
- Finish screen. Thanking the user and reminding them to take their bags.
Wireframes
Now we had a clear idea of what we needed for our flow it was time to draw it up. We began with some really simple wireframes to visualise our ideas. We decided to experiment with a number of different ways to structure our flow — one option with each screen separate, one by one, another option with a split-screen structure so the receipt section is always visible, and a final option with all steps on one screen, revealed through progressive loading to reveal the steps gradually.
Once we were satisfied with the user flow options we had created, we drew up the wireframes in Sketch (using out Blueprint wireframe kit) and brought them into InVision so we could test them with other members of our team to work out which would be the best solution. Come back for Part 3 to hear about our testing, UI work and final designs.
If you’d like to keep up-to-date with what we’re up to and our future freebies at Inktrap, follow us on Twitter and sign up to our weekly design newsletter Minimum Viable Publication.
