Loading…
Loading…
Every application has an inherent amount of complexity that cannot be removed.
stellae.design
Every application has an inherent amount of complexity that cannot be removed — only moved. Someone has to deal with it: either the user or the system.
Every application has an inherent, irreducible amount of complexity. This complexity cannot be eliminated — it can only be transferred between the user and the system. The question is not whether complexity exists, but who bears the burden of managing it.
Drag the slider to shift complexity between user and system. The total complexity stays the same — only who handles it changes.
Balanced: the system provides tools, the user makes choices.
Complexity can't be eliminated, only moved. Good design shifts it from user to system.
Date input with smart parsing and auto-formatting
System accepts any format and normalizes — complexity absorbed by engineering
Raw text field with strict format requirements
User must know and match the exact expected format — complexity pushed to user
Tesler's Law reframes the design challenge from 'make it simple' to 'decide who handles the complexity.' When designers push complexity onto users through configuration screens, ambiguous choices, and manual processes, the product feels hard to use. When engineers absorb that complexity through smart defaults, automation, and inference, the product feels effortless — even though the total complexity hasn't changed.
Gmail's automatic categorization (Primary, Social, Promotions) absorbs the complexity of email triage into the system. Users get organized email without writing filter rules. In contrast, traditional email clients required users to manually create rules — the same complexity existed, but the user bore the burden.
Before GPS, drivers managed the complexity of route planning themselves using maps, memorized directions, and landmarks. GPS navigation absorbs that complexity into the system, handling real-time route calculation, traffic avoidance, and turn-by-turn guidance. The complexity didn't disappear — it moved from the user to the software.
Some tax preparation software presents every IRS form field to every user, regardless of whether it applies to their situation. Instead of using the information already entered to infer which sections are relevant, the software forces users to navigate irreducible tax complexity themselves. The result is an experience that feels as complex as doing taxes by hand.
Notion provides a flexible block-based system that lets users build databases, wikis, and project trackers. The system absorbs significant structural complexity through templates, linked databases, and relation fields. Users work with familiar concepts like pages and tables while the system handles the underlying data relationships.
• Teams sometimes use Tesler's Law to justify unnecessary complexity by claiming 'the complexity has to live somewhere.' But the law is about irreducible complexity — the minimum needed to solve the problem — not about complexity introduced by poor design or architecture. Others over-absorb complexity into the system, creating brittle automation that fails in ways users cannot diagnose or recover from.
| Check | Good Pattern | How to Test |
|---|---|---|
| Complexity placement audit | For each major feature, you can articulate where the irreducible complexity lives and have deliberately chosen whether the user or the system handles it. | Map each feature's complexity and classify each element as user-facing or system-absorbed. Review whether any user-facing complexity could reasonably be absorbed by the system. |
| Smart defaults coverage | Configuration screens pre-populate intelligent defaults so users only modify what they need to, rather than building every setting from scratch. | Count the number of decisions a new user must make before reaching value. Compare against a competitor or previous version. Fewer mandatory decisions indicates better complexity absorption. |
| Automation reliability | System-absorbed complexity works correctly in the common cases and fails gracefully with clear user recovery paths in edge cases. | Test automated features against edge cases. Verify that when automation fails, users receive clear explanations and can manually override or correct the result. |
When exposing complexity gives expert users control they need — power tools, developer APIs, and professional software often benefit from surfacing complexity that enables precision. The key is making that exposure optional and progressive rather than mandatory.
Was this article helpful?