TeslerLaw [fact] v1.0.0

Tesler's Law of Conservation of Complexity (Larry Tesler, ~1984): every application has an irreducible core complexity that cannot be eliminated — it must be absorbed by either the system or the user.

Larry Tesler observed that all non-trivial applications contain inherent complexity that exists in the domain itself, not merely in the interface. Designers can shift where that complexity lives — hiding it inside the system, spreading it across a longer workflow, or exposing it to the user as configuration — but they cannot make it disappear. Attempts to over-simplify simply transfer hidden complexity to error states, edge cases, or support costs.

Confidence

proven

Applies To

• advanced settings panels — hiding power options creates implicit complexity that experts must work around
• smart defaults — the system absorbs complexity by picking sensible values, reducing user burden
• multi-step wizards — spreading complexity across more steps reduces cognitive load per screen but increases total path length
• API / developer tools — complexity removed from the UI surface often reappears in documentation, error messages, or programmatic configuration

Counter Conditions

• Purely cosmetic complexity (redundant UI chrome, decorative options) is reducible and is not covered by Tesler's Law.
• Novice vs. expert tradeoff: progressive disclosure can shift complexity to power users without increasing it for casual users, which is a valid design strategy.
• Automation via AI or rules engines can genuinely absorb domain complexity — the law describes human-visible complexity, not algorithmic complexity.

TeslerLaw [fact] v1.0.0

Tesler's Law of Conservation of Complexity (Larry Tesler, ~1984): every application has an irreducible core complexity that cannot be eliminated — it must be absorbed by either the system or the user.

Larry Tesler observed that all non-trivial applications contain inherent complexity that exists in the domain itself, not merely in the interface. Designers can shift where that complexity lives — hiding it inside the system, spreading it across a longer workflow, or exposing it to the user as configuration — but they cannot make it disappear. Attempts to over-simplify simply transfer hidden complexity to error states, edge cases, or support costs.

Confidence

proven

Applies To

• advanced settings panels — hiding power options creates implicit complexity that experts must work around
• smart defaults — the system absorbs complexity by picking sensible values, reducing user burden
• multi-step wizards — spreading complexity across more steps reduces cognitive load per screen but increases total path length
• API / developer tools — complexity removed from the UI surface often reappears in documentation, error messages, or programmatic configuration

Counter Conditions

• Purely cosmetic complexity (redundant UI chrome, decorative options) is reducible and is not covered by Tesler's Law.
• Novice vs. expert tradeoff: progressive disclosure can shift complexity to power users without increasing it for casual users, which is a valid design strategy.
• Automation via AI or rules engines can genuinely absorb domain complexity — the law describes human-visible complexity, not algorithmic complexity.

Sources

Confidence

proven

Source

• Tesler, L., 'A Personal History of Modeless Text Editing and Cut/Copy/Paste', ACM interactions (2012) — attribution of the law to his ~1984 Apple research
• Johnson, J. & Henderson, A., 'Conceptual Models: Core to Good Design', Morgan & Claypool (2011)
• Laws of UX — Tesler's Law (lawsofux.com, Jon Yablonski, 2020)

Applies To

• advanced settings panels — hiding power options creates implicit complexity that experts must work around
• smart defaults — the system absorbs complexity by picking sensible values, reducing user burden
• multi-step wizards — spreading complexity across more steps reduces cognitive load per screen but increases total path length
• API / developer tools — complexity removed from the UI surface often reappears in documentation, error messages, or programmatic configuration

Counter Conditions

• Purely cosmetic complexity (redundant UI chrome, decorative options) is reducible and is not covered by Tesler's Law.
• Novice vs. expert tradeoff: progressive disclosure can shift complexity to power users without increasing it for casual users, which is a valid design strategy.
• Automation via AI or rules engines can genuinely absorb domain complexity — the law describes human-visible complexity, not algorithmic complexity.