UI/UX law
// Motivation & Complexity;
Law of Deletion
An interface element is a liability until proven otherwise: it earns its place on screen only after its requirement is questioned and owned by a real person, and only after it survives an honest attempt to delete it. Simplifying, accelerating, and automating an element all come after that, never before it.
Mechanism
Why it happens
Every element shipped to a screen is also maintenance, load, and a future failure point added to the product, whether or not anyone ever asked for it. Deleting a requirement removes that surface entirely; simplifying an element that survives deletion can only ever reduce it. The two aren't interchangeable, which is why order matters: time spent polishing an element that should have been deleted is time spent on the wrong problem, however well it's executed, and a requirement nobody can name an owner for tends to survive by default rather than by need.
Impact
Why it matters
- An unowned requirement survives by default, not because anyone actually needs it
- Polishing an element that shouldn't exist is expensive procrastination: effort spent on the wrong problem, however well it's executed
- Every extra element is a compounding cost, not a one-time one: more to learn, more to maintain, more load, more noise, for as long as it ships
- Deleting too little is the default failure. If nothing ever has to be added back, the deletion pass probably wasn't honest
Example
Without vs. with
A dashboard ships with a carousel, a tips panel, a stats widget, and a notifications bell because a template included them, and nobody on the team can say who asked for any of them.
Stats widget
Owner: Support engineering
The same dashboard ships with only the stats widget a support engineer explicitly requested; the carousel, tips panel, and bell were cut in review because no one could name an owner for them.
Checklist
How to apply it
Before adding any element, name the person who owns the requirement behind it and have them justify it in one sentence
Try removing a dashboard widget, carousel, menu item, or field entirely before proposing a redesign of it
If a deletion turns out to be wrong, add the element back. That's a sign the process is working, not failing
Reserve visual polish for elements that have already survived an honest attempt to delete them
Only reach for automation once a manual version of the workflow has proven, through real use, that it deserves a system
Where it shows up