Thinking

When the Right Design Decision Is to Do Nothing

ProcessProduct Design·March 20, 2026·4 min read

There’s a kind of design work that never makes it into a portfolio. No screens. No deliverables. No artifacts to show. Just the record of something that didn’t get built — and the argument made for why it shouldn’t.

This is some of the most valuable design work that exists. It’s also the hardest to defend in a room full of people who equate output with progress.


Product teams accumulate features the way houses accumulate clutter. Each addition makes sense in isolation. Someone needed it. A competitor had it. A stakeholder wanted it. The cost at the time felt manageable. But features compound — in interface complexity, in engineering maintenance cost, in the cognitive load they place on users who now have one more thing to learn, one more option to consider, one more path to get lost in. Nearly 45% of software features are rarely or never used, yet they continue to consume development and maintenance resources [2].

The pressure to add is structural. Roadmaps reward addition. Stakeholders feel heard when their request ships. Progress meetings track what got built. There is almost no organisational mechanism that rewards the decision not to build something — even when that decision is the correct one.

Which means the designer who pushes back on addition is pushing against the current, every time, on principle, with the burden of proof always on them.

What features add — and what each one costs
Bulk exportPower users can export large datasetsNew menu path, edge case surface area, maintenance burden
Notification preferencesUsers control alert frequencySettings complexity, support for "why am I not getting emails"
Saved filtersReturning users skip re-configurationState management, empty state, filter migration on schema change
Comparison modeSide-by-side analysis across time periodsDoubles cognitive load, requires users to already understand individual views
Benchmark overlayContext vs. platform averageShifts task from understanding own data to evaluating relative performance
Nearly 45% of software features are rarely or never used, yet they continue to consume development and maintenance resources. The addition of each individually useful thing quietly degrades the usefulness of everything already there.

Barry Schwartz’s research on the paradox of choice showed something counterintuitive: more options reliably reduce satisfaction and increase decision paralysis, even when each individual option is genuinely valuable [1]. The cognitive cost of evaluating ten things is not ten times the cost of evaluating one. It’s an exponential tax — paid in attention, in confidence, in the feeling that maybe you made the wrong choice even after you chose.

In product design, this plays out concretely. An interface that offers twelve actions asks the user to understand twelve things before they can act on one. An analytics dashboard with twenty filters implies twenty dimensions of possible importance — and leaves the user to determine which ones actually matter for their situation. The addition of each individually useful thing quietly degrades the usefulness of everything already there.

On the Pax8 monetization project, a request came through to add benchmark toggles to every analytics chart — a feature that would let partners compare their performance against platform averages. On paper, reasonable. More context, better decisions.

I killed it. Not because it was a bad idea, but because it was the wrong idea for this moment. Partners on the platform were still learning to interpret their own data. Introducing a comparison dimension before they had a baseline understanding of their own performance would have shifted the cognitive task from understanding what I’m doing to evaluating how I compare— two fundamentally different modes that the product wasn’t designed to support simultaneously. The benchmark toggle would have felt like a feature. It would have functioned as noise.

The benchmark toggle — the case for and the case against
The request
More contextPartners can see how they compare to platform average
Competitive signalUnderperforming partners motivated to improve
Precedent existsCommon in analytics dashboards across the industry
Why it was killed
Wrong cognitive modePartners still learning their own data — comparison shifts task before baseline exists
Two tasks, one viewUnderstanding own performance and evaluating relative performance require different mental models
Noise before signalContext without comprehension creates anxiety, not insight
The benchmark toggle would have felt like a feature. It would have functioned as noise. The no required being specific about exactly which cognitive task it interrupted and why.

The argument for doing nothing is rarely popular in the meeting where it’s made. It requires specificity — not “we should keep it simple” (which sounds like laziness), but “here is the precise cognitive task this feature interrupts, here is the user state where it creates confusion rather than clarity, here is what would need to be true for this to belong.”

Restraint isn’t a compromise — it’s the key to creating the right products [3]. The most focused products aren’t the ones that said yes to the best features. They’re the ones that said no to the good ones.

That argument requires a clear model of what the product is trying to do and for whom — specific enough that you can evaluate a feature not just by what it adds, but by what it costs. Most teams don’t have that model explicit enough to make the no legible. Making it explicit is the design work that precedes the decision not to build.

The portfolio piece for that work isn’t a screen. It’s the reasoning. And the reasoning is, almost always, the most interesting part.

References

  1. Schwartz, B. (2004). The Paradox of Choice: Why More Is Less. Harper Perennial.
  2. Sonin (2025). Feature Bloat: The Silent Product Killer. sonin.agency
  3. Test Double (2025). The Art of Product Restraint: Why Less Delivers More. testdouble.com
The best design decision you'll ever make might be the one that leaves no artifact. 🚫 The best design decision you'll ever make might be the one that leaves no artifact. 🚫 The best design decision you'll ever make might be the one that leaves no artifact. 🚫 The best design decision you'll ever make might be the one that leaves no artifact. 🚫