沐鸣测速代理_让设计更有说服力的20条经典原则：特斯勒定律
往期回顾：
- 《让设计更有说服力的20条经典原则：美即好用效应》
- 《让设计更有说服力的20条经典原则：多尔蒂门槛》
- 《让设计更有说服力的20条经典原则：菲茨定律》
- 《让设计更有说服力的20条经典原则：希克定律》
- 《让设计更有说服力的20条经典原则：雅各布定律》
- 《让设计更有说服力的20条经典原则：简洁法则》
- 《让设计更有说服力的20条经典原则：邻近性》
- 《让设计更有说服力的20条经典原则：相似性》
- 《让设计更有说服力的20条经典原则：连通性》
- 《让设计更有说服力的20条经典原则：同域原则、米勒定律》
- 《让设计更有说服力的20条经典原则：奥卡姆剃刀》
- 《让设计更有说服力的20条经典原则：冯·雷斯托夫效应、蔡格尼克记忆效应》
- 《让设计更有说服力的20条经典原则：帕累托原则》
- 《让设计更有说服力的20条经典原则：帕金森定律》
1. 理论表述
任何系统都存在固有的复杂性，无法减少；唯一的问题是谁来处理它。
2. 理论背景
特斯勒定律（Tesler’s Law），又称复杂性守恒定律（Law of Conservation of Complexity），是人机交互领域的一句格言。上世纪八十年代中期，Larry Tesler 在 Xerox PARC 工作时意识到用户与应用交互的方式与应用本身一样重要。后来 Larry 加入了苹果并致力于 MacApp 面向对象的框架的开发，在那里他正式地阐述了复杂性守恒这条定律。它向所有相关人员提出了一个问题：
既然产品固有的复杂性守恒不变，那么该把谁置于复杂之下？是增加代码的复杂度而让交互更便利，还是增加用户的交互成本让代码变简单？
特斯勒认为产品的复杂度应该交由代码，开发人员应该多花一周时间用代码来简化应用的复杂度，而不是让成千上万的用户在应用里为交互多花哪怕一分钟。
1. 用代码简化交互
特斯勒告诉所有的互联网人一个道理──要用代码帮用户节省操作的时间，虽然这对于一般的中小型公司来说有些强人所难，但并不妨碍我们始终怀有这样的追求。
B站的一键三连小细节就是一个很好的例子，这个操作是这样的：用户长按点赞按钮，就能同时触发点赞、投币和收藏的操作，这就省去了用户挨个儿点的操作成本和时间成本。
案例1：B站一键三连
除此之外，另外一款获得过苹果年度 APP 大奖的任务管理软件 Sorted³ 也有着非常新颖且便捷的交互。
案例2：Sorted³的多选
Sorted³ 的多选操作是先在一项任务上向左横划一小段距离触发多选状态，再直接下滑就可多选，甚至隔着一个或两个再次重复上次操作，就可以隔项多选，听起来似乎比常规的多选交互复杂，其实不然。实际体验之后发现操作如丝般流畅，尤其是多选之后可以紧接着重新分配任务时间。
尽管不是什么伟大的跨时代的交互变迁，但在 APP 的交互设计同质化严重的今天，小细节上的两点就可以得到很多人的垂青，所以特斯勒定律是一个非常好的突破口。
2. 算法解放「生产力」
在伯斯塔尔法则那篇文章中，我们提到过一个有趣的方法论──贝叶斯方法，它可以被用来解决用户输入错误的可能性这种逆概问题。简单来说，它是「智能纠错」、「机器学习」算法背后的核心思想之一。而这也是一个利用算法简化交互的典型的例子，它让输入法可以自动纠正输入错误，它让搜索引擎具备一定的自纠正能力，而使得用户不必进行「删去错误的词条，输入正确的」这种浪费时间的操作。
案例3：输入法和搜索引擎的自纠正
这背后所蕴含的概率论理论、数理思想和数学模型远远不是区区代码就能够实现的，无数的卓越的数学家、建模工程师和算法工程师投入了无数的时间，才实现了我们可能已经习以为常的某一个小功能，也正是这些小功能，我们的生活才能变得更便利、更智能、更省时，特斯勒定律说的就是这么一回事。
需要注意的一点是，我们所希望的节省时间，是通过代码和算法解决需要重复操作或者需要再次执行的任务，这些任务花费我们大量的时间却无法得到任何实质性的更好的结果。比如搜索栏输错关键词，删掉重输就是无意义的重复劳动，结果依然还是那个我想要的搜索结果，并不会变得更好。
但是，代码唯一不能代替的，是用户的决策行为。
决策，尤其是关键性的决策，依然需要把控在用户手中，不然用户会觉得自己对当前的应用/系统失去了掌控，产生不安全感。
这让我想起了一直被人吐槽的 Windows10 自动更新，用户不能决定更新还是不更新，只能够决定什么时候更新，甚至夜间自动更新更是让用户深恶痛绝。
反面案例：windows10 自动更新
更新还是不更新这件事完全取决于用户，如果用户没办法通过简单直观的办法决定更新的开和关，那么对于那些只追求稳定能用的用户来说这是体验极差的。无独有偶，苹果完全不顾老机型用户更新系统可能变卡的问题，一味地强制用户更新 iOS 系统，甚至私自决定通过降频来」帮助「用户延缓电池衰老，最终惹来了诉讼。
- 系统存在固有的复杂性，要把复杂性转嫁到代码的层面而降低用户端的；
- 代码不能代替决策。
欢迎关注作者的微信公众号：「超人的电话亭」
