用途
Tesler 定律（又称复杂度守恒定律）由 Larry Tesler 提出：每个应用都存在一定量的、不可消除的固有复杂度。这种复杂度无法被消灭，只能被移动。设计决策的关键在于：由用户吸收这份复杂度，还是由产品吸收。
本技能用于在设计中应用这一定律，识别复杂度被不必要地转嫁给用户的地方，找到产品应当代为吸收的环节，并抵制那种为追求“干净”界面而过度简化、从而制造出隐形下游负担的反射式做法。
核心原则
简化界面并不会移除复杂度，它只是把复杂度搬到了别处。
两类复杂度
- 固有复杂度：来自任务本身的性质。例如为多位乘客、指定座位并含中转的航班预订，本身就是复杂的。移除这种复杂度意味着移除相应能力。
- 附加复杂度：来自设计而非任务。例如令人困惑的表单顺序、不一致的术语、冗余步骤或结构混乱的决策，这些是产品没有理由强加的负担。
工作的目标是：消除附加复杂度，并对固有复杂度由谁吸收做出有意识的决定。
复杂度应当在哪里被吸收
以下为资料中给出的对照示例（左为用户承担，右为产品承担）：
- 用户必须按正确格式输入日期 → 产品接受多种格式或提供日期选择器
- 用户先选国家、再重新输入地区 → 产品自动识别国家并填充地区选项
- 用户必须遵守文件命名规范 → 产品强制或自动生成名称
- 用户在开始前需设置 12 个选项 → 产品应用智能默认值，选项逐步提供
- 用户阅读并解读错误、再自行寻找修复方法 → 产品直接给出修正建议
何时不应过度简化
Tesler 定律警告一种常见的 UX 反射：为追求“干净”界面而剥离所有表面复杂度。当出现以下情况时需警惕：
- 把过多选项藏在渐进式披露之后，高级用户需要花时间寻找
- 对关键决策过度默认，用户在真正重要的时刻失去控制
- 移除配置能力，产品不再适配合理的边缘情况
简化表面可能在下游制造隐形复杂度——更长的流程、更多的错误恢复、更高的支持开销。复杂度只是被移动了，并没有消失。
常见应用场景
- 表单默认值：默认选择最常见项；在不隐藏的前提下暴露其他选项
- 错误提示：指出问题并说明修复方法，不要让用户自行解读技术原因
- 导入与导出：接受用户已有的格式，不要要求用户先重新格式化产品才能读取
- 多步骤流程：自动化不需要用户判断的步骤；只询问只有用户才知道的信息
- 设置与配置：为每项设置提供可用默认值；让自定义可选而非强制
最佳实践
- 审查流程的每一步：用户正在做什么决策？产品能否在不损失保真度的前提下代做这个决策？
- 积极应用智能默认值，但始终为需要的用户暴露底层选项
- 在简化之前区分固有复杂度与附加复杂度——前者无法移除，只能管理
- 简化 UI 时，核实被移除的复杂度去了哪里；它可能重新出现在支持队列或下游用户步骤中
- 通过结果衡量复杂度——错误率、任务耗时、放弃率、支持量——而不是数可见的界面元素
限制
资料未提供该技能的具体安装方式、运行环境、依赖条件、收费信息或平台支持范围，这些内容暂未提供。