Tesler’s Law
“Sir, hum itna simplify kar denge ki sab kuch one-click ho jayega.”
I smiled at my student and asked, “Great—but who will handle the complexity you’ve hidden?”
That’s precisely where Tesler’s Law steps in.
Every product has some complexity that you can’t remove—you can only decide who carries it: the system, the designer, or the user. Push it away in one place and it pops up somewhere else (people call this the “waterbed” effect). Our job is to shoulder the right parts in design and engineering, so users feel confident and fast.
What exactly is Tesler’s Law?
Coined by Larry Tesler (Xerox PARC, Apple), the Law of Conservation of Complexity says a system contains irreducible complexity. You can shift where it shows up, but you can’t make it vanish. Good products eliminate unnecessary complexity from the user and keep the inherent complexity manageable. Tesler was also famous for advocating modeless software—interfaces that don’t force users to remember which “mode” they’re in—because modes often impose an extra mental burden on people.
Two quick truths you can teach your team tomorrow:
- Not all complexity is bad. Finance tools, analytics, medical apps—they’re naturally complex. The win lies in placing complexity wisely and sequencing it well.
- Hiding everything can backfire. If the system oversimplifies, users lose control or get stuck at the “one weird edge case.” Balance simplicity with clarity about what’s happening.
How to implement Tesler’s Law in UX/UI
1) Decide who pays the “complexity tax”
- Shift to system: validation, auto-formatting, sensible defaults, data lookups, prefilled values.
- Shift to design: clearer IA, better labels, consistent patterns, progressive disclosure.
This is the heart of Tesler’s Law: move avoidable complexity off the user’s plate.
2) Use progressive disclosure like a pro
Expose the next best choice first. Put advanced or rare options behind “More,” accordions, or a dedicated step. You respect time for most users while empowering experts.
3) Prefer recognition over recall
Call things what users already expect (“Save,” “Download,” “Billing address”). Consistent, familiar language reduces the burden of remembering and decoding unfamiliar terms. (This complements Jakob’s heuristics and works beautifully with Tesler’s idea of shifting cognitive effort away from the user.)
4) Engineer for helpful defaults
Default date ranges (“Last 7 days”), recommended plans, or preselected shipping options reduce decision load. Defaults are powerful; keep them ethical and reversible.
5) Make complex flows resumable
If a flow is long (KYC, onboarding), auto-save and surface a Resume entry point. You’re absorbing the complexity of state management so that the user doesn’t have to restart the application. (This also leverages the Zeigarnik/Ovsiankina pull to finish later.)
6) Measure where complexity hurts
Instrument time-to-first-action, backtracks, error rate, rage-clicks/taps, and completion. For commerce, checkouts that are “too long/complicated” are a classic drop-off cause; Baymard’s research shows ~18% of US shoppers abandon for this reason—and that lean checkouts can work with ~12–14 form elements versus the ~23.5 commonly shown. That gap is pure, fixable complexity.
How UXGen Studio helps your team apply Tesler’s Law
- Complexity Mapping Workshop: We chart where users make avoidable decisions and where the system can take over (defaults, data enrichment, validation, modeless flows).
- IA & Copy Realignment: We simplify labels, group options by intent, and apply progressive disclosure, enabling both beginners and experts to progress smoothly.
- Preset & Default Strategy: We design ethical defaults and presets backed by usage data—reversible and explainable.
- Proof, not opinions: We instrument TTFA, backtracks, completion, and—if you’re e-commerce—benchmark against Baymard’s element counts to cut checkout complexity.
Bring us your “people get stuck here” flows. We’ll help you move the right complexity under the hood.
FAQs
Q1. Does Tesler’s Law mean “always simplify”?
No. It means being honest about inherent complexity and moving it to where it’s least painful—often into code, defaults, or design patterns. Over-simplifying can reduce control or create edge-case traps.
Q2. How is this different from “Simplicity at all costs”?
“Simplify” is a direction; Tesler’s Law is a trade-off rule. It asks who should deal with each piece of complexity and suggests progressive disclosure to stage it.
Q3. What’s one change we can make tomorrow?
Find one dense form. Add a preset + a default, and move rare options into Advanced. You’ll likely see faster first actions and fewer support pings. (If checkout: aim for 12–14 elements vs. the ~23.5 many sites still show.)