On Clarity as a Design Tool

The hardest part of building something good is deciding what not to include.

Every feature you ship is a promise: that you’ll maintain it, that it won’t get in the user’s way, that it earns its place in the interface. Most features don’t clear that bar. Most features are noise dressed up as usefulness.

Clarity is subtractive#

When I look at software I admire, the defining quality is almost always restraint. Someone, somewhere, fought hard to keep the thing simple. They said no to the obvious addition. They resisted the temptation to hedge.

Clarity isn’t about making things pretty. It’s about making the next decision obvious — to the user, to your team, to your future self.

The pretty version of a product is something a designer can deliver in a week. The clear version takes months — because it requires arguing with everyone who wanted to add their favorite feature, and being right.

The compounding effect#

Small decisions compound. A clean component API today means a clean feature next month. A precise vocabulary in your codebase means fewer bugs in six months. A simple data model means you can actually ship the thing your customer asked for on Monday without rewriting the world.

Every piece of complexity you don’t add is a decision you don’t have to justify later.

That’s the quiet power of clarity. It’s a design tool that works on code, on product, on communication — on everything.

Where clarity comes from#

It’s tempting to think clarity is a personality trait — that some designers are just born minimalist. They’re not. Clarity is a practice.

Three habits produce it:

1. Saying no out loud. When someone proposes a feature, the default answer is no. The proposer has to make a case, and the case has to address what gets lost when the feature exists. Most ideas don’t survive contact with that bar.

2. Writing it down before you build it. If you can’t explain a feature in two sentences, the design isn’t ready. The act of writing forces you to find the words; the search for words forces you to find the idea. Implementation comes after.

3. Removing what you’ve already built. The bravest design move is taking something away after you’ve shipped it. You’ll find resistance — sunk cost is a powerful drug. Do it anyway. The product gets better.

The cost of unclear products#

The opposite of clarity isn’t ugliness — it’s cognitive overhead. Every unclear interface charges its users a tiny tax on every interaction: what does this do?, where does this go?, is this safe to click? Most products lose users not because they’re broken, but because answering those questions is exhausting.

You don’t always see the abandoned users. They don’t write angry emails. They just leave. And then you ship more features to win them back, and the new features make the problem worse.

A test for clarity#

When I’m not sure if a design is clear, I run a quick test: can I describe it to a smart friend who doesn’t work in tech, in one paragraph, without using the word just?

The “just” trap is real. Click on the menu, just open settings, just toggle the option. If you find yourself saying just more than once, the path isn’t clear — you’re papering over friction with a casual word.

The same test works on code. It just calls this function, which just maps over the array, which just returns the result. Three justs in a sentence is a tell. The code probably needs a refactor.

The bet#

Clarity doesn’t sell itself. It doesn’t win awards. There’s no “Clearest UX of 2026” category at design conferences. But every product I’ve kept around for years — the editor I write in, the terminal I work in, the email client I haven’t replaced — earned its place through clarity, not novelty.

That’s the bet. Build the thing that disappears. Let the user’s intent move through it without snagging on anything. Strip it down until it can’t get any simpler — then strip it down once more.

The best design is the one you don’t notice.