用智能手机拍照时，只需在屏幕上点一下，对焦和亮度就会自动调好。过去，拍照的人必须亲自计算光圈和快门速度，如今这些计算都由机器代劳。那么，拍照这件事中包含的复杂性真的消失了吗？用“复杂性不会消失，只是换了位置”来回答这个问题的原则，就是“特斯勒复杂性守恒定律”（Tesler's Law of Conservation of Complexity）。
简单来说，特斯勒定律是这样一条原则：“每个系统都有一定程度无法再减少的复杂性，剩下的问题是由谁来承担它”。这一原则由曾在施乐帕洛阿尔托研究中心（Xerox PARC）和苹果（Apple）打磨用户界面的计算机科学家拉里·特斯勒（Larry Tesler）提出，也被称为“复杂性守恒定律”。
本文将依次探讨特斯勒定律的产生背景、分担复杂性的三方、生活中的例子，以及在设计中运用它的原则与局限。
特斯勒定律：决定复杂性归属的设计
什么是特斯勒定律？
拉里·特斯勒在施乐帕洛阿尔托研究中心研究了让用户不被困在特定模式中的“无模式”（modeless）编辑方式，1980年转入苹果，参与了丽莎（Lisa）电脑的用户界面工作。他还以推广了如今人人都在用的剪切、复制、粘贴方式而闻名。
特斯勒在回顾文章中提到，当有人反对说暂存剪切内容的功能会加重开发负担时，他坚持认为“宁可让开发者负重，也不要让用户负重”。他把这一主张加以提炼，在1984年前后总结如下。
“每个应用程序都有其固有的、无法再减少的复杂性。剩下的问题只有一个：由用户、应用程序开发者还是平台开发者来处理它？”
定律名称中之所以有“守恒”（Conservation）一词，也是出于同样的道理。正如能量只会改变形式而不会消失，复杂性也可以从屏幕上隐藏起来，却无法被消除。人们有时也用按下一侧另一侧就会鼓起的水床作比喻，称之为“水床理论”（Waterbed Theory）。
分担复杂性的三方
按照特斯勒的总结，无法减少的复杂性最终会由以下三方中的某一方来承担。
- 用户（User）：用户必须亲自选择设置、记住操作顺序、纠正错误。
- 应用程序开发者（Application Developer）：开发产品的人多费心思、多写代码，替用户省去麻烦。
- 平台开发者（Platform Developer）：操作系统或开发工具预先提供通用功能，让多个产品分担同样的负担。
在这三者中，特斯勒最警惕的是把负担转嫁给用户。在设计师丹·萨弗（Dan Saffer）书中收录的一篇访谈里，他指出：如果工程师只需再多花一周就能消除的复杂性，导致一百万用户每天各浪费一分钟，那就等于为了减轻工程师的工作而惩罚用户。
这一定律与“选项越多决策越慢”的希克定律（Hick's Law）、“目标越远越小越难点中”的菲茨定律（Fitts's Law）关注点不同。如果说这两条定律是衡量用户所耗时间的框架，那么特斯勒定律探讨的则是把复杂性交给谁来承担的责任问题。
通过简单的例子理解复杂性的转移
复杂性转移的情形，在我们每天使用的服务中很容易找到。
（1）搜索框
用户只输入几个字，背后却进行着纠正错别字、推荐搜索词、对结果排序的一连串计算。想出准确搜索词的麻烦，由系统代为承担了。
（2）地址输入
只要输入邮政编码或道路名称的几个字就能自动补全其余地址的界面，是把准确填写冗长地址的负担转移到数据和开发一方的结果。
（3）汽车与导航
唐纳德·诺曼（Donald Norman）在2010年出版的《Living with Complexity》一书中解释说，汽车里的计算机系统一年比一年复杂，但正是得益于这些隐藏的复杂性，驾驶变得更简单、更安全。计算最佳路线这件事，如今也不再由司机而是由导航来承担。
在这三个例子中，用户的工作都变轻了，而开发一方的设计和计算则相应地变重了。复杂性的总量没有变，变的只是承担其重量的人。
在设计中的运用与局限
要把特斯勒定律融入设计，首先要找出这项任务中最终无法减少的复杂性在哪里。然后只保留用户必须亲自判断的部分，其余的交给系统，通过默认值、自动填充和分步引导来处理。这时，与其假设一个总是理性行事的理想用户，不如在真实用户卡住的那一刻，就在那个位置显示简短的帮助说明，这样更有效。
不过，把复杂性全部藏起来也不是答案。藏得太多，用户就失去了按自己意愿进行调整的途径，因此需要区分对待，例如为初次使用的人提供分步引导，为熟练用户另设高级设置。此外，界面设计师布鲁斯·托格纳齐尼（Bruce Tognazzini）认为，人们并不会心甘情愿地接受生活中复杂性的减少：程序变得简单了，用户就会相应地挑战更复杂的任务。
特斯勒定律告诉我们，看似简单的界面并不是消除了复杂性的结果，而是有人替用户扛起了这份复杂性的结果。因此，评价好的设计，与其看它减少了多少复杂性，不如看它把复杂性放在了哪里。
由开发者先扛起本该由用户承担的负担——这正是为用户而设计的第一步。
