Stress testing product design: Lessons from emergency rooms

Imagine this: you’re in a product design meeting. The room is calm, the flowchart looks tidy, and you imagine your users happily clicking through the journey exactly as you mapped it. Easy, right?

But now let’s take off the halo and look at the actual truth. Real life almost never looks like your wireframes. People are tired, distracted, juggling five things at once, and sometimes working under crushing pressure.

Nowhere is that gap clearer than in healthcare. Emergency rooms are the ultimate crash test for stress testing product design. For ER nurses, digital tools aren’t just conveniences. They’re lifelines. And when those tools don’t work? The fallout isn’t a little frustration or a lost task. It can mean dangerous errors, burnout, and in the worst moments patient harm, according to a Utah Health study.

Emergency rooms are the ultimate crash test for product design. They show us what happens when linear systems meet chaotic environments. And they carry a blunt reminder for product leaders everywhere: if your product only works when everything goes smoothly, it doesn’t really work at all.

The ER as the ultimate stress test

Walk into any ER at the start of a shift, and the pace hits you like a wall. One nurse is handed four patients right off the bat. A 91-year-old woman in respiratory distress rolls in by ambulance. Within minutes, the nurse is juggling oxygen, an IV, lab draws, and documentation when a cardiac monitor down the hall erupts in alarm.

She has no choice but to sprint out, log off her workstation, silence the alarm, and then hustle back to pick up where she left off. By the time she’s back, the flow she started is already broken (Source: Denver College of Nursing – “A Day in the Life of an ER Nurse”).

And here’s the kicker: this isn’t a rare bad day. This is the job. ER nurses live in constant motion, pulled in every direction, and they are forced to make split-second calls while being interrupted over and over again.

But the systems they depend on? They’re often designed as if the work happens in neat, step-by-step order. Log in. Do one task. Complete it. Move on. That’s unrealistic and dangerous.

For product leaders, the lesson is simple: stress testing product design means building for the world as it really is. Your users will be forced to invent workarounds, or the system will fail them the moment reality gets messy.

When two John Does become one

One of the most chilling examples of system failure comes from a real-world ER incident involving two unidentified trauma patients. Both men were admitted at the same time under temporary names: “John Doe 1” and “John Doe 2.”

The more critical patient was rushed into surgery. But somewhere between the ER and the OR, the electronic health record system fumbled. His chart got mixed up with the other John Doe’s, and orders were logged under the wrong name.

The mistake was only caught because an OR nurse noticed that a transfusion order didn’t match the surgical schedule (Source: Agency for Healthcare Research and Quality case study). It was a near miss, but it could have been deadly.

This wasn’t just miscommunication. It was a design failure. The system didn’t have guardrails to prevent identity mix-ups, so the error spread unchecked.

They’re everyday realities, and they show why stress testing product design is critical.

When the alert bell won’t shut up

Here’s another example. In this one, a nurse administered pain medication. Hospital policy required her to reassess pain within 15–30 minutes. The EHR enforced that rule with strict timers:

• ~30 minutes for IV meds,
• ~60 minutes for oral medications

and flags her if she doesn’t document within the window.

Sounds reasonable in theory. In reality? It doesn’t work. ER nurses are constantly being pulled into urgent situations. Sticking to an arbitrary 30-minute deadline means she has to stop using her professional judgment just to appease a piece of software (AMA – “EHR usability, safety challenges”).

This is what alert fatigue looks like: systems that flood users with rigid reminders until the noise drowns out the signal.

That’s not just a problem in healthcare. In SaaS, stress testing product design means pushing past rigid rules and testing how your system holds up when chaos hits. If your app pings for every little thing, don’t be surprised when users start ignoring the notifications that matter most.

The click fatigue spiral

Ask any ER nurse what drains their energy fastest, and you’ll hear it: documentation. One nurse enters a patient’s weight on the admission form. Moments later, the system gives her a new task: “obtain a current weight.”

Later, she records capillary refill time under “cardiovascular.” But when she scrolls to “skin,” the same field sits empty. She has to enter the information again. Nothing carries over.

Each extra click might look trivial to a developer. But across a 12-hour shift, the redundancy stacks up. Nurses call it “click fatigue,” and it steals focus from patient care.

When ‘special instructions’ go nowhere

Here’s another lesson. A physician enters detailed lab instructions into an EHR field labeled “special instructions,” assuming lab staff will see them. But the lab’s system doesn’t pull from that field. The instructions never make it through. The tests aren’t performed correctly (Medical Liability Association report).

From the doctor’s perspective, he did his job. From the system’s perspective, the instructions didn’t exist. The mismatch created a silent failure that the physician couldn’t have predicted.

This wasn’t user error. It was a system that didn’t match the user’s mental model. The interface didn’t make its limits clear, and the result was hidden risk.

Why stress testing product design matters beyond healthcare

It might be tempting for product leaders outside of healthcare to see these examples as niche. But the underlying dynamics are universal. And sometimes you can’t see what’s happening without stress testing product design.

• Users under pressure: Nurses in ERs are extreme cases, but every user experiences pressure in the form of deadlines, multitasking, or distractions. If your product only functions in a calm, idealized setting, it will fail under real-world conditions.
  
• Overload and fatigue: Whether it’s nurses facing “alert fatigue” or SaaS users drowning in notifications, too much noise makes people tune out the signal (PSNet primer on alert fatigue).
  
• Workarounds as a warning: Nurses placing stickers on shared devices to keep track of them (Imprivata frontline account) may seem like a small hack, but it signals a deep mismatch between system design and workflow. The same goes for SaaS users exporting data to spreadsheets because in-app reporting doesn’t cut it.

These patterns reveal a larger truth: designing for the edge isn’t about planning for rare disasters. It’s about recognizing that complexity, interruptions, and human error aren’t bugs in the system. They are the system.

Resilient UX design: Building products that survive chao

“If your product only works when everything goes smoothly, it’s not designed for reality—it’s failed the stress test.”

So, what can product leaders learn from the ER?

1. Run real-world product testing, not just lab demos.
   Don’t validate your product only in a calm, scripted environment. Observe how people use it under pressure, like when they’re interrupted, multitasking, or switching between devices. That’s where you see flaws and can build in resilience.
   
2. Design for resilience, not rigidity.
   Systems should bend, not break. Build systems that can tolerate mistakes and interruptions without collapsing. Redundancy checks, flexible workflows, and clear error recovery paths matter more than elegant linear flows.
   
3. Respect cognitive load.
   Every extra click, duplicated entry, or irrelevant alert chips away at a user’s mental bandwidth. In high-pressure settings, that’s deadly. In SaaS, it’s costly. Streamline flows to respect attention and keep focus where it belongs. (JMIR study on workload)
   
4. Match system behavior to user expectations.
   Don’t bury critical functionality in places users don’t think to look. If users expect instructions to be visible across teams or data to carry over across fields, your product should deliver. Misaligned mental models are  design failures.
   
5. Co-design with real users.
   The best adoption rates come when the people doing the work have a seat at the table. In healthcare, that’s nurses. In SaaS, it’s frontline employees. Real-world product testing with the right users ensures solutions stick.

Designing for edge cases in SaaS and health tech

The ER shows us that “edge cases” aren’t edges at all—they are where products are truly tested. In SaaS, the high-stakes moment might not be a trauma bay, but it could be a quarterly close in finance software, a product launch using a marketing platform, or a sales team rushing to hit end-of-month quotas.

The pressure might be different, but the principle is the same: users don’t operate in your imagined flowcharts. They operate in messy, unpredictable, high-pressure environments. If your product can’t support them there, it’s not built for reality.

Designing for the edge is the foundation of resilient UX and the only way to build products that endure.