← 返回规律列表
架构

特斯勒定律:复杂度守恒

每个应用都有无法消除的固有复杂度,只能在系统与用户之间转移。

显示原始英文内容

Tesler's Law (Conservation of Complexity)

Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated.

Takeaways

  • Good design often requires that developers absorb most of the complexity (through smart defaults, algorithms, etc.) so that the user's interaction is simpler.
  • If your UI requires the user to manage many settings or steps, you've conserved complexity in the wrong place (on the user side). Often, it's better to design the product to manage that complexity internally.
  • Good design often hides complexity without eliminating it by handling it internally.

Overview

Tesler's Law, also known as the Law of Conservation of Complexity, states that for any system, there is a certain amount of complexity that cannot be removed; it's inherent to the problem. The key is who deals with it.

If you design software that's very simple for the user, it likely means the software is doing a lot of complex work under the hood. If you make the software very simple internally, it might dump complexity on the user (e.g., requiring many manual steps).

Tesler's Law encourages designers to move complexity away from the user experience whenever possible.

Examples

A classic example is scheduling meetings, which is inherently complex (finding a common time). A tool like Calendly hides that complexity from the user (the software handles it), whereas an email chain to schedule a meeting places that complexity on the user to figure out.

In system architecture, imagine designing a database vs. putting logic in application code. Sometimes pushing logic into the DB (such as stored procedures) can simplify app code but add complexity to the DB layer, or vice versa. Complexity isn't gone, just relocated.

In the end, the law reminds us that no design is without complexity. It's all about smartly allocating complexity to the right place.

Origins

Larry Tesler, who worked on Apple Lisa and early GUI concepts, formulated this principle in the 1980s. He observed that you can't make everything simple without someone handling complexity. It's a fundamental trade-off in design.

核心含义

一个问题的复杂度不会因为换了界面、框架或服务边界就凭空消失。把复杂度封装在系统里,通常能降低用户负担;把它推给用户,则可能让界面变得难用。

工程设计的关键不是追求“零复杂度”,而是决定由谁承担复杂度、在什么时机承担,以及如何让它可理解、可恢复。

实践例子

支付系统必须处理幂等、退款、风控和对账。产品可以把这些流程封装在后台,给用户一个简单的支付界面,但业务规则本身并没有消失。

来源与边界

拉里·特斯勒在用户界面设计领域提出了复杂度守恒的观察。通过自动化和更好的默认值,确实可以降低总的操作成本,但不能消除领域本身的限制。