Self-service checkouts and lessons in UX
“UNEXPECTED ITEM IN BAGGING AREA!”
I hate self-service checkouts. Well, let me rephrase that. I love the idea of them: being able to move at my own pace, able to bag my items in the order I want, able to enjoy an illusion of privacy as I handle my own groceries. I even like the novelty of using the new technology. What I don’t love, though, is their UX. Slow machines that interrupt me with unexpected queries, failing completely the moment I deviate even slightly from the predefined workflow. Machines that force me to find an assistant the moment I do anything even slightly out of the ordinary, like rearrange my bags – assistants who are typically overstretched and otherwise preoccupied.
Why did it turn out like this? Why is it that, in the second decade of the third millenium, consumers are still facing systems with interfaces lifted straight out of the early 1990s?
I think there are a few reasons, and each lies behind at least one of four major issues auto-checkout systems suffer.
Issue 1: Rigid Workflows
Problem
The machine doesn’t make smart decisions, or let me short cut its workflows – e.g. if I’ve entered a debit card, I automatically want to pay by card, but the machine insists I remove the card, press ‘pay by card’ and try again. Users approaching terminals with expected workflows suffer a learning cost and lose confidence in their knowledge of how to handle the transaction.
Possible cause?
Designers who take for granted the workflow the supermarket imagines users will take rather than practical insights into the ways shoppers actually work. Lack of attention to the ‘NATty principle’ (‘Never Ask Twice’). Assumption that users will read instructions rather than proceed on the basis of their existing expectations.
Lesson?
Users don’t think about tasks in the ways we hope they do, and if there’s a mismatch, help text will not guide users into your ways of thinking – they just don’t bother reading. Instead, study your users and see how they mentally group and divide certain kinds of tasks into stages of a process. And always, always allow for deviation.
Issue 2: Reliance on Store Staff
Problem?
Autocheckouts rely too much on human supervisors arbitrating decisions, when assistants are usually in short supply and often busy directing customers to terminals. Users feel bad for having to demand the attention of visibly strained store staff. Customers feel helpless if staff are unavailable.
Possible cause?
I’d guess a miscommunication about the context of the product. I strongly suspect that whereas the designers were assured that supervisors would always be on hand to help, supermarkets have ‘sold’ the service internally as a way to reduce supervisor workload. That would mean staffing managers under-resourcing autocheckout lanes, yet designers assuming a supervisor will always be able to help.
Lesson?
When your application makes a request of the user, be very diligent in investigating the costs of those requests in real-world deployments. Be realistic about the contexts your solution will be delivered to, and be frank with stakeholders about the situations where your product just won’t perform well.
Issue 3: Impatient Timeouts
Problem?
Task timeouts are completely unrealistic. If I’m having trouble bagging something, and I take a little too long, the entire terminal closes down, and I can’t continue without a supervisor – even if I do eventually bag the item in question. Unconfident users feel they’re treated as being slow and incapable. Low-literacy users who typically read instructions repeatedly suffer a visible, social embarrassment as they repeatedly stumble on tasks.
Possible cause?
This could be simply a lack of practical research, combined with hasty assumptions about how long something ‘should take’ – when research will indicate something very different.
Lessons?
Give users the chance to recover, or the ability to call an assistant without locking the entire terminal. Alternatively, subtly request the attention of the assistant without necessarily informing the user – so the assistant can judge the situation from afar and approach troubled users naturally.
Issue 4: Bag Panic
Problem?
Autocheckouts don’t allow me to rebag items. If I have more than one bag, and try to take some off the scales before closing the transaction, the application locks down – even if user replaces item.
Possible cause?
Naive assumptions that users would always have one small basket, and that they would always work to the supermarket’s imagined workflow.
Lessons?
Observe your users. Allow the application to fail gracefully – ideally, still allowing progress whilst assistant is being called. Research your users and test your assumptions with real-world usability testing. Treat workflow assumptions with healthy scepticism.
I have a love-hate relationship with those things. I like that I don’t have to make small talk with a cashier, and the lines are usually shorter. But I hate the ‘rigid workflow’ that you mentioned – it drives me crazy!
On an unrelated note, I found your blog through your profile on ux.stackexchange.com. Your profile says that you are a ‘help strategist’. What does that mean?
I didn’t really feel the term ‘technical author’ was sufficient, because in practice, what I do involves planning and conceiving user help as part of broader UX and project activities. “Help strategy” means looking at project goals, identifying business-critical user behaviours and analysing likely pitfalls in the interface. In practice, most tech writers do this anyway, but the term “technical author” suggests a people crafting a very certain kind of deliverable – the monolithic manual – when in reality, modern user help can mean creating forums for user-generated content and engaging customers through social media.
Still, it’s not the best term, because it is rather vague. The cynic in me immediately thinks “snake oil salesman” when I hear people calling themselves ‘strategists’ or ‘consultants’, and I wouldn’t be surprised if others shared my attitudes. But “technical writer” just doesn’t describe what we do any more.
Although most people, like me, probably don’t grok ‘help strategist’ without the explanation, I do like that it suggests something more than creating a manual. It’s a good way to prompt a conversation.
By the way, I sent an email to you at jimmy@breck-mckye.com to see if you would be interested in doing an interview for my blog. I hope we can make that happen, if you like the idea.
I think the problem with self-service checkouts is a very fundamental one of requirements: The business requirement of reducing in-store staff has taken the driving seat in the development of these devices.
This seems to have been further compounded by the manufacturer of the terminals (there is only one) realising that they could re-use the platform already used for regular POS terminals. This platform is laughably obsolete (the terminals are very slow embedded PCs running Windows NT 4 and Terminal Services with the application running on server), and nobody has an real incentive to upgrade it. I guess this will finally happen when the software becomes unavailable.
There are other regulatory requirements that make ruin the user experience even further – not least the supermarkets’ overly cautious attitude to age-restricted products.
It’s fairly apparent that neither the supermarkets for suppliers have any experience in HCI – otherwise they’d have performed user testing and quickly found all the faults listed above. The software running on the terminals is also buggy – obvious bugs seen by users are still not fixed some 10 years after the first appearance of these machines.
The user of these systems simply doesn’t get a look in. It might be that the supermarkets simply don’t care – although they really ought to as the usability faults are in fact increasing the levels of staff needed to supervise the machines.
And finally, the dirty secret of the supermarket industry is that self-service terminals facilitate various kinds of theft by customers. Is it possible that ‘anti-usability’ requirements are coming into play? Perhaps the minimum level of staffing of terminals is driven primarily by theft and that the many excuses for staff to be involved supervising the process is deliberate?