Redesigning error messages for M&S self-service checkouts

Team

I worked as one of two UX designers on this project, collaborating closely with a product manager and an engineer throughout research, design, and handoff.

The problem

Roughly 20% of all transactions at M&S self-service checkouts required a colleague to step in and assist. The root cause: error messages that were unclear, inconsistently designed, and often failed to tell customers what to do next.

Error messages ranged from generic system codes to yellow full-screen takeovers, with no unified design logic governing when each type should appear or what language to use. The result was customer frustration, slower transaction times, and avoidable stock loss.

Research & discovery

Understanding the full scope

My first step was to audit every existing error state and map them by where they occurred in the customer journey. This gave the team a shared picture of the problem before any design decisions were made.

I also reviewed prior in-store research from CLX identifying hardware and interface pain points — small fonts, confusing amber light states, tagged items causing transaction stalls — and conducted a heuristic review against Nielsen Norman error message guidelines.

Research methods

How I gathered insight

Desk research — Nielsen Norman

Used NN/g error principles as a framework to evaluate existing copy: explicit, human-readable, polite, precise, and constructive.

Heuristic review

Evaluated SCOTs UI against usability heuristics — particularly visibility of system status and real-world language match.

In-store observations (CLX)

Reviewed existing store observation reports capturing real customer behaviour and confusion points at self-checkout.

User testing — Zoom & in-store intercepts

Tested prototypes with real customers end-to-end. Participants showed a noticeably higher understanding of redesigned messages vs. existing designs.

Design thinking

Building a system, not just screens

Rather than redesigning individual error states in isolation, I focused on defining the logic that would govern all of them — a taxonomy where each error type had clear behavioural rules, so future messages could be placed into the right pattern by default.

• →Full screen / critical: Fills the entire UI, yellow background signals urgency. Used when the system fails to complete an expected action. Dismissible only by CTA.
• →Pop-up alert: Overlays current content with a grey mask. Used when M&S needs to interrupt the customer with an instructional message mid-flow.
• →Interrupter: No on-screen buttons — requires a physical action. Auto-escalates to a colleague request after one minute of inaction.

Each error state was documented with explicit trigger rules — the exact condition under which it appears — to remove ambiguity during engineering handoff.

Outcomes

Skills & tools