design law　/　特斯勒定律

Tesler’s Law (Law of Conservation of Complexity)

每个系统都存在一定程度的、无法彻底消除的复杂性。设计者真正能决定的，不是“是否存在复杂性”，而是这部分复杂性应该由用户还是由系统承担。优秀的设计通常会让系统处理重复、可预测和可自动化的复杂性，同时把真正需要判断的部分留给用户。这里的复杂性包括业务规则、信息要求、异常处理、权限约束和风险判断；它可以在用户、界面、应用程序、开发团队和平台之间转移。

Key fields

Identity

Subtype: 定律
Parent Taxonomy: Complexity Allocation & System Burden

What

Definition: 每个系统都存在一定程度的、无法彻底消除的复杂性。设计者真正能决定的，不是“是否存在复杂性”，而是这部分复杂性应该由用户还是由系统承担。优秀的设计通常会让系统处理重复、可预测和可自动化的复杂性，同时把真正需要判断的部分留给用户。这里的复杂性包括业务规则、信息要求、异常处理、权限约束和风险判断；它可以在用户、界面、应用程序、开发团队和平台之间转移。

Why

Mechanism: 1. 认知资源有限重复输入、记忆规则和理解系统逻辑，会占用用户完成任务所需的注意力。 2. 信息可以外部化系统可以记住已有信息并处理可预测步骤，减少用户的记忆与操作负担。 3. 重复成本会被放大产品由团队设计一次，却可能被大量用户重复使用。系统多承担一点复杂性，可能节省大量用户时间。 4. 复杂性会跨层转移更简单的使用体验，通常需要系统承担更多工程、数据和异常处理工作。

Where

Applicable Context: Cognitive Load & Complexity

How

Design Guidance: 1. 提供合理默认值根据常见情况预先选择最可能的选项，但必须允许用户修改。 2. 自动处理重复工作自动保存、自动填充和信息同步，减少没有判断价值的操作。 3. 渐进式展示复杂功能优先展示完成主要任务所需的内容，高级能力按需展开并保持可发现。 4. 使用用户熟悉的语言围绕用户任务表达信息，避免暴露数据库结构和内部技术概念。 5. 保留用户控制权自动化结果应当可以查看、修改或撤销，高风险行为不能替用户决定。

Evidence

Limitations: 1. 隐藏不等于消除隐藏复杂性或压缩操作步骤，可能只是改变复杂性出现的位置。 2. 并非所有决定都应该自动化付款、隐私、发布和删除等高风险行为需要明确的知情权和控制权。 3. 专业用户仍然需要控制用户可能需要查看规则、修改参数和干预自动化结果。 4. 系统承担复杂性也有成本简化不应该以牺牲可靠性、透明度和维护能力为代价。

Lifecycle

Status: 待复核