The field you type twice
Your banking app asks for the account number twice. Most of us were trained to see that as friction, the kind of thing a UX review flags and removes.
It isn't. It might be the most honest design decision in the whole app. Somebody decided that ten seconds of your attention is cheaper than money landing in a stranger's account, and they were right.
That trade sits at the centre of high-stakes UX. I recently ran a session on it for our Product Experience Guild, built around a small model from aviation called PEAR. This is the written version, for anyone who wasn't in the room.
What makes UX high-stakes
High-stakes UX isn't a separate discipline. It's standard UX with the tolerance for ambiguity removed. You're in that territory if any one of these is true:
- A wrong action can't easily be undone.
- Errors land on other people, not just the user.
- The system runs in a regulated environment.
The person using your product is tired, under time pressure and only partly trained. Not because they're bad at the job, but because that's what real shifts look like.
Aerospace, nuclear, heavy industry. A UI error can mean physical harm or loss of life.
Money, medical records, legal duties, regulated data.
Enterprise tools where an error stops production or costs customer trust.
The AI recommends, a human acts on it, often with the clock running.
Everyday UX vs high-stakes UX
Same craft, different tolerance for error. Most products don't sit at either extreme. They sit somewhere on a line, and it's worth knowing where yours is.
The two rows that matter most are friction and errors. Everyday UX teaches us to smooth everything. High-stakes UX asks you to put a speed bump in exactly one place, and to know why it's there.
Where PEAR comes from
“Human error” is where the investigation starts, not where it ends.
THE SHIFT AVIATION MADE, AND WE STILL HAVEN'T
When Air France 447 went into the Atlantic in 2009, investigators didn't find one bad pilot. They found iced sensors, an autopilot that handed control back at the worst possible moment, a startled crew and stall warnings that made little sense in the moment. Calling it "human error" would have closed the case without fixing anything.
Aviation learned that lesson over decades, and PEAR is one of the tools it left behind. It came out of maintenance, not the cockpit.
- 1972 to 1975SHEL / SHELL
Edwards, then Hawkins at KLM. How people fit with software, hardware, environment and each other.
- 1990Swiss cheese model
James Reason. Accidents happen when the holes in many layers of defence line up.
- 1993The Dirty Dozen
Gordon Dupont, Transport Canada. Twelve common causes of maintenance error: fatigue, pressure, complacency and friends.
- 1990s to 2007PEAR
Michael Maddox and Bill Johnson. A simple memory jogger for all maintenance work, not just for explaining error after the fact.
- TODAYFAA & CASA
Part of FAA maintenance human-factors guidance and handbooks, and Australia's CASA engineer training.
Each letter translates cleanly into product work. It also lines up almost one-to-one with the "context of use" in ISO 9241-11, the standard behind human-centred design. So PEAR isn't a new process. It's a quick way to hold the whole context in your head.
The same user isn't always the same person
We draw personas as if people were fixed. They aren't. The confident expert on a quiet Tuesday is a different user at the end of a double shift with three alarms going off. Map experience against mode and you get four people who might all be the same human.
Learning the ropes. Reads every label.
Fast, fluent, knows every shortcut.
Tunnel vision. Freezes or panics.
Calm, but runs on habit and memory.
Under stress, attention narrows to one thing, short-term memory drops, reading slows, and people fall back on habit, even the wrong one. So each quadrant asks something different of the design:
- Lakshyaguidance, plain labels, and the "why" behind each step
- Rohanshortcuts and density. Stay out of his way
- Aaravone clear next step. Hide everything else
- Sameerflag what's different from normal, so habit doesn't win
Design for Aarav first. Then add shortcuts for Rohan. Most products do it the other way round, because Rohan is the one in the demo.
The room changes what the screen can say
Submarines switch to red lighting at night, "rigged for red", so the crew keeps its night vision. Good for eyes. Terrible for any warning that relies on red, because it disappears into the room.
The same thing happens on screen. An "alert mode" that tints the whole display red hides the red alarms at exactly the moment someone needs to find them. Try it:
Never rely on colour alone. Add shape, icon, text and position. Then test the interface in its real lighting and noise, not just on your monitor.
When the dangerous action is as easy as the safe one
On 13 January 2018, phones across Hawaii lit up with a ballistic missile warning. There was no missile. It took 38 minutes for a correction to go out.
BASED ON THE MOCK-UP RELEASED AFTER THE INCIDENT
BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL.
RECREATION OF THE ALERT TEXT
Early reports blamed a menu mix-up. The FCC's investigation later found the drill recording itself wrongly said "this is not a drill", and the operator said he believed the attack was real. Either way, the design lessons hold: the live alert sat one click and one generic "Are you sure?" away, drill and live options lived side by side in the same plain list, and there was no ready-made correction to send.
Separate live from test, visually and physically. Make the confirmation state the consequence, not "Are you sure?". Build the undo path before launch, not during the incident.
Spend the user's effort where an error costs the most
Back to the field you type twice. Resources in PEAR means everything that helps someone get it right: information, checks, training, help, time. It also includes the user's own time and attention, and that's the resource we spend here.
About ten seconds of the user's time and attention.
Money in the wrong account, and a slow, uncertain recovery.
Friction is a resource. Spend it only where mistakes are expensive.
The flip side is what happens when a resource is missing altogether. Pilots of the Boeing 737 MAX weren't told about MCAS, the system that kept pushing the nose down. When it misfired, they didn't have the knowledge to diagnose it in time. 346 people died in two crashes.
PEAR isn't a designer-only tool
The best part of the guild session was watching product owners, engineers and QA pick it up faster than the designers. Each role asks the same four questions and walks away with something different. Pick yours:
Prioritise for the stressed or new user, not the demo user.
Capture context in the backlog: shift, device, noise, pressure.
Tag irreversible actions as high-risk stories.
Budget training, help and docs as scope, not extras.
Stress-mode personas: fatigue, startle, overload.
Observe in the real setting. Design for glare, gloves and noise.
Separate dangerous from routine. Confirm with the consequence.
Put guidance in context. Show what the automation is doing.
Assume users get interrupted. Save state, fail safe.
Handle bad networks, small screens and alarm floods.
Build undo, two-person approval and rate limits.
Expose system state, logs and explainable outputs.
Test with new and time-pressured users, not just happy paths.
Test offline, in low light, with many alerts firing.
Try to trigger the wrong action on purpose.
Check that error messages and escalation paths actually work.
Not a phase. A question you keep asking
PEAR doesn't need its own workshop. It shows up at every stage of delivery, with different letters leading at different times.
- Discover
Watch real work in the real place. Who, where, under what pressure?
P · E - Define
Write PEAR into stories and acceptance criteria. Mark high-risk actions.
A · R - Design
Design normal and stress states. Protect the critical actions.
P · A - Build
Guardrails, undo, visible system state, safe defaults.
A · R - Test
Test in bad conditions and try to cause slips on purpose.
E · A - Operate
When something goes wrong, review it with PEAR, not blame.
P · E · A · R
PEAR in a user story
Same story, two versions. Every line in the second one exists because of a failure mode above.
- Block button on the case page
- Confirmation dialog
- Account status changes to "Blocked"
- PA junior analyst at the end of a shift can see why it's high risk at a glance: score plus top three reasons.
- EWith 200+ open alerts, the queue doesn't reorder under the cursor and the block action stays put.
- AConfirmation names the customer and the amount frozen. Unblock is one click for 30 minutes.
- RA linked playbook step and a one-tap escalation to a senior analyst.
The four questions
If you remember nothing else, ask these before you design anything where a mistake costs more than a retry.
- Who is the person, and what is their worst-case state?
- What surrounds them: light, noise, alarms, pressure, culture?
- Which actions can't be undone, and how easily could they slip?
- What help do they have in the moment, and where is extra effort worth it?
PEAR tells you where to look. The High-Stakes UX Framework describes what good looks like once you get there: error prevention, error recovery, situational awareness and human-system trust.
SOURCES & CREDITS- FAA, Human Factors Guide for Aviation Maintenance and Inspection (opens in new tab)
- SKYbrary, PEAR Model (opens in new tab)
- AviationPros, Two countries apply trusted human factors model to manage safety (opens in new tab)
- ISO 9241-11:2018, Usability: definitions and concepts
- FCC Public Safety and Homeland Security Bureau, report on the January 2018 Hawaii false ballistic missile alert
- BEA, final report on the accident to Air France flight AF447 (2012)
- Photo: Air France 447 wreckage recovery, NTSB, public domain, via Wikimedia Commons