Complexity Is a Safety Problem

Feature debates usually come down to capability. Does the product do enough? Is it as powerful as the competition? Does it justify the price?

For most products, these are reasonable questions. But when users are vulnerable, the frame flips.

Every added setting is not a capability gain. It is a new way to fail.

I learned this while designing a companion app for a portable medication reminder device. The target users were elderly patients, people with memory loss, and the caregivers managing their schedules. The hardware was intentionally minimal: no screen, no WiFi, a single button. The setup happened entirely in the app, through a physical phone-to-device tap.

The Scope That Was Cut

The original feature list included per-reminder volume controls and per-reminder alert patterns. On paper, this made sense.

Patients have different hearing levels. Some reminders feel more urgent than others. Letting users tune each one looked thoughtful.

I cut all of it. What remained: daily and weekly schedule options, plus a single global buzzer toggle.

The reason was not engineering effort. The reason was the cost of a misconfiguration.

What Misconfiguration Means Here

For a photo app, a misconfigured setting means a slightly wrong crop or an unwanted filter. The user notices, adjusts, moves on. The cost is a few seconds of friction.

For a medication reminder, a misconfigured setting means a missed dose. Or a doubled dose. Both are serious.

For a patient managing a complex regimen, or an elderly person living alone, "the reminder didn't fire" or "the alarm was too quiet to hear" is not a minor inconvenience. It is a clinical event.

That asymmetry changes the design equation entirely. The question is no longer "does this setting add value?" The question is "what happens when this setting is wrong?"

The Burden of Proof Flips

In most products, you add features until they cost more than they contribute. More options, more surface area, more things to learn, more potential confusion. You ship when the gains outweigh the friction.

When the cost of a wrong setting is high, that logic inverts. The burden of proof is not on removing an option. The burden of proof is on keeping it.

Per-reminder volume controls could not clear that bar.

Could a caregiver set the wrong volume and not notice? Yes, especially during a rushed pharmacy visit or a stressful setup session. Could the device be handed to a new caregiver who adjusts settings without understanding the original configuration? Yes. Could a patient with early-stage memory loss attempt their own setup? Yes.

Any of those paths could produce a reminder that fires too quietly to wake someone at 7am.

Removing the option removed the failure mode. The global buzzer toggle remained because the tradeoff was different: one setting, obvious effect, applies to everything, recoverable in seconds.

The Transferable Heuristic

I think about this when I hear feature debates framed purely around capability. "Users want this." "The competition has it." "It would be more flexible."

These are real arguments. But they assume the cost of a wrong configuration is low.

When that assumption does not hold, the heuristic is simple: the higher the cost of a wrong setting, the fewer settings you ship.

This is not a plea for minimal products or stripped-down interfaces. Complex tools for expert users often need complex controls. A mixing board does not need to hide its EQ settings. But a medication device for someone with significant memory loss is not a mixing board, and treating it like one is a design failure, not a design choice.

Scope-cutting is usually framed as a compromise, something you do because of time or resources. In safety-critical contexts, it is not a compromise. It is the work.

The product I shipped had fewer options than the original brief. It was also safer. Those two things were not in tension.