Process February 2026 5 min read

On minimal interfaces — what restraint actually costs

Minimal isn't the same as simple. Stripping a UI down to its essentials takes more deliberate work than adding to it — and most teams don't budget for that work.

There's a myth in product design that minimal interfaces are easier to build. That by removing things, you're doing less. The opposite is true. Restraint is expensive. Every element you remove forces the remaining ones to carry more weight — and that weight has to be earned through precision, not assumed through omission.

What "minimal" actually means

Minimal doesn't mean sparse or empty. It means that every element present is there because removing it would make the product worse. That's a much higher bar than it sounds. It requires you to know, with confidence, what the product is for — and to resist the pressure to hedge that definition with features.

A good minimal interface is one where there's nothing left to remove. A bad one is one where there was never anything to remove in the first place.

The difference is felt immediately. Sparse interfaces that haven't earned their restraint feel unfinished — like the designer ran out of time. Minimal interfaces that have done the work feel inevitable, like the product couldn't be any other way.

What restraint actually costs

When you add a feature, you're making a bet with visible upside and hidden downside. The feature might be useful; the cost to coherence is abstract and delayed. When you remove a feature, you're making the opposite bet — immediate visible cost, diffuse long-term benefit. Most teams and most product processes aren't structured to make that second bet consistently.

The interface as argument

Every design decision is an implicit argument about what matters. A settings panel with forty options argues that flexibility matters more than clarity. A single-mode interface argues the opposite. Neither is wrong — but only one can be right for any given product.

The products I try to build argue, as clearly as possible, that the task matters and the tool should get out of the way. That's a coherent position. It's not the right position for every product — but it's the one I find worth defending, and it shapes every decision from layout to copy to the default state of every input.

A test I use: If I can't explain why a UI element exists in one sentence, it probably shouldn't exist. Not because brevity is a virtue, but because if I can't articulate it, I probably haven't understood the need well enough to solve it correctly.

This isn't a manifesto for minimalism as an aesthetic. It's an argument for minimalism as a discipline — a practice of understanding what a product is for deeply enough to know what it doesn't need to be.

← Previous post Why I built Hollow — and why it lives in one file All writing → Back to posts