Is this really needed?

When I joined Alan five years ago, the first time I presented a mock-up to our former design lead Ed, he looked at it and asked: "Is this really needed?" Not "could we improve this", just, is it needed. Ed was the most pragmatic designer I'd ever worked with. No attachment to clever ideas, no ego about his own work. If something didn't earn its place, it was gone. That simple question rewired how I think about design.

There's a study that captures why this lesson matters. Researchers at the University of Virginia asked people to make a Lego structure stronger and almost everyone added bricks. Barely anyone thought to remove one, even when that was the simplest fix. We're wired to add. When we're faced with a problem, our instinct is to introduce something new: a feature, a toggle, a tooltip, an extra step. Subtraction takes more effort because it feels like doing less, and doing less feels uncomfortably close to doing nothing. But the most impactful move is often taking something away.

Addition is a deeply human bias, we tend to associate progress with accumulation, as if more features equals more value, or more options equals more flexibility.

But every addition carries hidden costs that we tend to overlook. A new setting adds a decision the user didn't ask to make, a new screen introduces a path that needs to be learned and a new component means one more thing to maintain, document, and keep consistent across the product. Addition is easy to justify because it feels productive, while removal feels like regression. And left unchecked, this is exactly how products become bloated, confusing, and fragile over time.

When you strip a flow down to its essentials, the signal you get back is so much cleaner. If users drop off a three-step onboarding, you know exactly where and why, but if they drop off a twelve-step one, good luck trying to isolate the friction.

Every element on screen competes for attention and the more choices you present, the harder each one becomes for the person who has to make it.

Fewer options don't limit the user, they clarify the path. A single call-to-action on an empty page is unmistakable, and a form with three fields feels respectful of someone's time. Reduction gives users confidence in what’s actually there. 

And here's the thing: if something is truly missing, your users will tell you. You don't need to anticipate every need upfront: ship less, listen, and let real usage show you what's lacking ; that's a much stronger signal than any assumption you could make in a design review.

The real power of "remove before you add" shows up at the team level, because when subtraction is a shared principle, it changes how people make decisions.

A product manager looking at a feature request starts by asking whether we can solve this without adding anything. An engineer reviewing a spec feels empowered to push back on complexity without it being taken personally. A designer presenting a flow doesn't have to justify why something is missing, because the team already agrees that absence is the default and presence needs to earn its place.

This creates trust in the product itself. If the team operates with subtraction as a first principle, then everything that exists in the product is there deliberately: there's no cruft, no leftover experiments, no "we added this because someone important asked for it once." Every element has survived the question: does this need to be here? This kind of clarity is rare, and it compounds over time.

This isn't just about flows and features though, it's equally true at the visual layer.

Fewer colors means things easier to scan, and fewer button variants means they're harder to use wrong. It means being ok with whitespace, resisting the urge to fill every gap just because an empty area feels unfinished. A layout that breathes is a layout that works.

This is where you have to kill your darlings. That component that looks beautiful but doesn't serve the flow? Remove it. That extra layer of visual structure that feels polished but serves no function? Let it go. Keeping something because it looks better is not a good enough reason. If it doesn't serve a purpose (communicating state, guiding attention, establishing hierarchy) it's noise and it's making everything around it harder to read.

The same goes for the design system, by the way. Thirty button variants is fragmentation. Every unnecessary variant is a future inconsistency someone will have to clean up. A tight system is a maintainable one.

Removing is harder than adding, and it's worth acknowledging. It means confronting sunk costs, disappointing stakeholders, sitting with a screen that looks "empty." It takes real conviction to ship less when everyone around you is measuring output.

But the products people love, the ones they describe as "clean" or "simple" without quite knowing why, are almost always the result of relentless subtraction. Not less work but harder work: figuring out what to leave out.

Ever since that first design critic with Ed, I've never added anything in vain: his voice still resonates in my head whenever I design something new. So next time you're about to add something, pause for a second and ask yourself: Is this really needed? What if we removed something instead?