Why Less is More

I once watched a senior nurse navigate an electronic health record to order a simple blood test. Fourteen clicks. Three dropdown menus. One confirmation screen that asked her to confirm what she'd already confirmed. By the time she finished, I'd lost count of how many times she sighed.

This is what happens when systems are designed by accumulation rather than intention. Someone needed a field for edge cases. Someone else wanted a safety confirmation. A third person added a dropdown because dropdowns feel thorough. Nobody asked whether the nurse ordering her hundredth blood test that week needed any of it.

The hidden weight of features

Every interface element carries weight. Not physical weight—cognitive load. Each button, field, and option demands a sliver of attention. These slivers add up. In healthcare, where attention is already stretched thin, they add up to something dangerous.

I've seen alert fatigue so severe that critical warnings get the same dismissive click as trivial ones. The system that was supposed to catch errors has become noise. The signal drowned in a sea of well-intentioned features.

Why we keep adding

There's a gravitational pull toward more. More features mean more capability. More options mean more flexibility. More fields mean more data. On paper, it all makes sense.

The problem is that capability, flexibility, and data aren't free. They're traded for simplicity. And simplicity is what allows people to act quickly and correctly under pressure.

Healthcare software often gets built by committee. Each stakeholder contributes their requirements. The integration team makes it all fit together. What emerges is comprehensive, certainly. But comprehensiveness and usability are different animals. Sometimes they're opposing forces.

The discipline of subtraction

The WHO Surgical Safety Checklist works precisely because it's short. Nineteen items. Three phases. The whole thing takes two minutes. Previous attempts at surgical safety protocols had been more thorough—and less effective. Thoroughness that doesn't get used isn't thorough at all.

Good design requires asking uncomfortable questions. What happens if we remove this? Usually, the answer is nothing bad. The feature that felt essential turns out to be vestigial—something added once for a reason nobody remembers.

My test is simple: if I can remove something and the user wouldn't miss it, it shouldn't be there. This sounds obvious. In practice, it requires courage. It means pushing back on stakeholders. It means trusting that less can genuinely be more.

The stakes in healthcare

In consumer software, bloat is annoying. In healthcare, it's a patient safety issue.

When a clinician is managing multiple deteriorating patients, every unnecessary cognitive load compounds the risk of error. The cluttered interface isn't just frustrating—it's a hazard. We should be designing for the worst moment, not the average one. The interface that works fine when things are calm needs to work when things are falling apart.

Most healthcare organisations say they want simplicity. What they often mean is they want comprehensive simplicity—everything captured, every workflow supported, but somehow still easy to use. This is wishful thinking. Comprehensive and simple pull in opposite directions. At some point, you have to choose.

A different starting point

What if we designed healthcare systems the way we design emergency equipment? Minimal. Essential. Nothing that doesn't earn its place through demonstrated necessity.

The organisations that embrace this will find their systems actually get used as intended. The workarounds will fade. The errors will decrease. The staff will be less exhausted.

The rest will keep wondering why their expensive software sits largely unused while clinicians find ways around it.

Related reading:

• Wayfinding in Healthcare Environments — Applying simplicity to physical spaces
• Designing for Patient-Centered Healthcare Systems — The broader context of healthcare design