Removing UI is harder than adding UI.

Building the wrong UI is more expensive than not building it. But the second cost is invisible — and that's why deletion is the harder discipline.

When we audited Spicom's installation flow, the abandonment rate was 60%. The flow had 7 visible steps: database setup, theme selection, server configuration, and four others. The instinct was to redesign each step. The decision that shipped was different: delete the steps.

We collapsed seven visible steps into one button. The technical operations didn't disappear; they moved out of the user's path. Time-to-completion went from 7 minutes to 20 seconds. Abandonment went from 60% to 0%.

Nothing about the redesign was novel. The work was deciding which steps deserved to be in the UI at all.

Why deletion is harder than addition

01 · Deletion is invisible work

A new feature has a screenshot. A removed step has nothing to show. Promotion packets and design reviews reward output. The engineer who ships a new flow is celebrated; the designer who proves a flow shouldn't exist gets a paragraph in a retrospective.

02 · Deletion requires evidence, not instinct

Adding a step is defensible by intuition: “users might want to choose a server region.” Removing it requires arguing against that intuition, which means data. Specifically: how often is the choice meaningful? How often does the user have the context to decide? What's the failure rate if we choose for them?

These are answerable questions. They're just harder than “it might be useful.”

03 · Deletion fights every team's incentive

Engineering wants to ship the feature they built. Product wants the metric the feature was scoped to move. Marketing wants the bullet point. The only stakeholder advocating for fewer steps is the user, who is rarely in the room.

The test that survives

The test I came back to repeatedly: if a step requires technical literacy the user doesn't have, it shouldn't be in the UI.

Database configuration is the canonical case. The decision is meaningful only if the user has a non-default need. Most users don't. The default works. So the step exists to serve the 5% who care, at the cost of confusing the 95% who don't. That ratio inverts after you delete it: the 95% complete the flow, and the 5% can configure later.

A second test, harder to operationalize: what does the user think they're doing right now? If the step doesn't match the user's stated goal, it's a candidate for deletion. They came to launch a website. They didn't come to configure a database. The flow should reflect the goal, not the implementation.

What deletion looks like when it's working

You know deletion is working when:

• Support tickets drop without you adding documentation.
• New engineers onboarded into the flow ask which step is the “real” step.
• The marketing team needs you to explain what changed, because the screenshot is shorter than before.
• The metric you were trying to move (conversion, completion, activation) moves up even though the surface looks like less work.

The redesigned Spicom flow had all four signals.

The senior version of design isn't more screens. It's the discipline to ask, of every step: would this user complete this step if they understood what it was actually asking?

If the answer is no, the right design isn't a clearer step. It's no step.