设计定律 / Tesler’s Law (Law of Conservation of Complexity)
特斯勒定律
每个系统都存在一定程度的、无法彻底消除的复杂性。 设计者真正能决定的，不是“是否存在复杂性”，而是这部分复杂性应该由用户还是由系统承担。 优秀的设计通常会让系统处理重复、可预测和可自动化的复杂性，同时把真正需要判断的部分留给用户。 这里的复杂性包括业务规则、信息要求、异常处理、权限约束和风险判断；它可以在用户、界面、应用程序、开发团队和平台之间转移。
Identity · 身份
- 子类型
- 定律
- 父级类目
- 复杂性分配与系统负担
What · 是什么
- 定义
- 每个系统都存在一定程度的、无法彻底消除的复杂性。 设计者真正能决定的，不是“是否存在复杂性”，而是这部分复杂性应该由用户还是由系统承担。 优秀的设计通常会让系统处理重复、可预测和可自动化的复杂性，同时把真正需要判断的部分留给用户。 这里的复杂性包括业务规则、信息要求、异常处理、权限约束和风险判断；它可以在用户、界面、应用程序、开发团队和平台之间转移。
Why · 为什么
- 作用机制
- 1. 认知资源有限 重复输入、记忆规则和理解系统逻辑，会占用用户完成任务所需的注意力。 2. 信息可以外部化 系统可以记住已有信息并处理可预测步骤，减少用户的记忆与操作负担。 3. 重复成本会被放大 产品由团队设计一次，却可能被大量用户重复使用。系统多承担一点复杂性，可能节省大量用户时间。 4. 复杂性会跨层转移 更简单的使用体验，通常需要系统承担更多工程、数据和异常处理工作。
Where · 在哪里
- 适用场景
- 复杂度与认知负担
How · 怎么做
- 设计指导
- 1. 提供合理默认值 根据常见情况预先选择最可能的选项，但必须允许用户修改。 2. 自动处理重复工作 自动保存、自动填充和信息同步，减少没有判断价值的操作。 3. 渐进式展示复杂功能 优先展示完成主要任务所需的内容，高级能力按需展开并保持可发现。 4. 使用用户熟悉的语言 围绕用户任务表达信息，避免暴露数据库结构和内部技术概念。 5. 保留用户控制权 自动化结果应当可以查看、修改或撤销，高风险行为不能替用户决定。
Evidence · 证据
- 局限与边界
- 1. 隐藏不等于消除 隐藏复杂性或压缩操作步骤，可能只是改变复杂性出现的位置。 2. 并非所有决定都应该自动化 付款、隐私、发布和删除等高风险行为需要明确的知情权和控制权。 3. 专业用户仍然需要控制 用户可能需要查看规则、修改参数和干预自动化结果。 4. 系统承担复杂性也有成本 简化不应该以牺牲可靠性、透明度和维护能力为代价。
Lifecycle · 生命周期
- 状态
- 待复核
相关设计原则与机制
关系来自本地关系表，并包含反向关联。
- 复杂度与认知负担Cognitive Load & Complexity应用于
处理信息数量、认知负担、系统与用户之间的复杂性分配。
- 复杂性分配与系统负担Complexity Allocation & System Burden属于
聚焦任务复杂性、系统设计复杂性与用户可感知复杂性的分配，判断何时应通过自动化、默认值或分步流程降低用户负担。
- 认知负荷理论Cognitive Load Theory反向 · 相关
人的工作记忆资源有限。理解内容和完成任务所需的心理加工一旦超过可用资源，表现、学习和决策质量就会下降。 设计应减少与目标无关的额外负荷，同时为任务本身不可避免的复杂度提供支持。
- 默认效应Default Effect反向 · 相关
当系统预先选定一个选项时，许多人倾向于保留该默认值，而不是主动修改。 默认项既能降低重复决策成本，也会显著影响行为，因此必须符合用户利益、容易理解且可修改。
- 多尔蒂阈值Doherty Threshold反向 · 相关
当系统能在大约 400 毫秒内提供响应或明确反馈时，人机交互更容易保持节奏，用户也更愿意继续操作。 重点不是每个任务都必须在 400 毫秒内完成，而是尽快让用户确认系统已收到操作并正在推进。
- 米勒定律Miller’s Law反向 · 相关
人的工作记忆容量有限，经典研究常以“7±2 个信息单元”描述这一限制。 设计上的重点不是把界面强行限制为七项，而是通过分组和组块化减少用户同时需要处理的信息。
- 奥卡姆剃刀Occam’s Razor反向 · 相关
当多个方案能够同样充分地解释问题或达到目标时，应优先选择假设更少、结构更简单的方案。 它鼓励减少没有明确价值的规则、状态和步骤，但不意味着牺牲必要能力。