CALM: The Art of Starting with Less

As the year turns, we often respond by adding new goals, new tools, and new pressure. Calm design asks a different question: what if we began by removing?

Across industries, the pattern is familiar. Developer environments accumulate flags. Enterprise dashboards fill with toggles. Financial, security, and healthcare systems ship with defaults no one fully trusts.

The problem is not ambition.
It is unmanaged choice.

In healthcare technology, outcomes are shaped less by what clinicians configure and more by the defaults they inherit on day one.

Consider how a patient monitor is typically deployed in a hospital. Out of the box, it exposes several hundred configuration items: alarm limits, delay times, averaging windows, escalation rules, display layouts, and modality-specific behaviors. To adapt the monitor to a specific ward, a configuration expert must translate clinical workflows into this parameter space—often manually, setting by setting.

This creates a well-known cognitive trap. Hick’s Law tells us that decision time increases with the number of available options. When configuration surfaces explode, understanding slows down. Setup takes longer. Explanations become harder. Errors become more likely—not because people are careless, but because the system demands too many decisions too early.

At the same time, the Paradox of Choice plays out quietly. More configurability promises flexibility, but in practice it increases hesitation, regret, and inconsistency. Experts second-guess settings. Customers defer decisions. Small misconfigurations—an alarm delay set too long, a copied profile applied in the wrong context—persist unnoticed. These failures rarely announce themselves. They become part of daily clinical work.

Now imagine a different default. The monitor starts in a clinically safe, minimal configuration aligned with common care settings. Core parameters are set conservatively. Alarm behavior is restrained. The display shows only what is needed for the current context. Advanced settings remain available, but are revealed progressively as clinical needs and user competence grow.

By reducing initial choice, the system shortens decision paths, lowers setup effort, and narrows the surface for error. Complexity is not removed—but it is delayed until it can be handled safely. Calm defaults do not limit capability. They protect attention, reduce risk, and allow clinicians and systems to grow together.

Book — The Paradox of Choice by Barry Schwartz
Read this less as psychology and more as operations. Every option adds training effort, QA combinations, documentation, and long-term maintenance.

In complex systems, excess choice is not freedom.
It is unfunded operational debt.

If every additional configuration option increases the chance of regret, which choices in your system should never have been offered in the first place—and which should have been decided safely by default?

In my work with patient monitoring systems, I proposed a simple rule:
Before introducing a new configuration setting, remove two existing ones.

Not because the new setting was unnecessary, but because every parameter carries a long-term cost. Each option must be learned, explained, maintained, tested, and defended against misuse. Without deliberate subtraction, configuration surfaces only grow, and so does hidden risk.

Try this exercise:

Before adding a new configuration option to a clinical system, pause and ask:

Document the decision—not just what you add, but what you remove and why. Over time, this creates a visible trail of intentional restraint rather than accidental complexity.

This practice enforces lean maintenance and a form of Stoic minimalism: complexity is allowed only when it earns its place. The result is not fewer capabilities, but fewer ways to fail quietly.

Starting with less is not denial.
It is stewardship.

Best,
Andreas Walden

Share this with someone designing for clarity.