特斯勒定律（复杂性守恒定律）：如何把产品复杂度交给代码而非用户

特斯勒定律（Tesler's Law），又称复杂性守恒定律（Law of Conservation of Complexity），由人机交互先驱拉里·特斯勒（Larry Tesler）提出。该定律指出：每一个过程都有其固有的、无法被彻底消灭的复杂度；一旦简化达到临界点，复杂度就只能在“系统后台/代码”与“前端用户”之间相互转移。特斯勒强调，产品的复杂度应该交由代码与设计师去承担，而不是让成千上万的用户在应用里为交互多花哪怕一分钟。

在设计复杂的企业级 SaaS 平台、高并发交易系统或超级 App 时，团队常常争论一个问题：“这个业务逻辑本来就很复杂，是不是只能让用户多填几张表、多点几次按钮？”人机交互大师拉里·特斯勒（Larry Tesler，复制粘贴功能的发明者）用著名的特斯勒定律（Tesler's Law）给出了振聋发聩的回答：复杂性是守恒的，但你可以选择让工程师和设计师多花一周时间写代码，从而替成千上万的用户每人省下一分钟。

一、复杂性守恒定律的本质：谁来为系统的复杂度买单？

任何一个数字产品在完成某项任务时，都存在一个不可再压缩的“固有复杂度总量”。这就好比能量守恒定律：

如果工程与设计团队偷懒，直接把底层数据库字段和后台审批逻辑原封不动地甩给前端界面，那么开发虽然省事了，但每一个打开产品的用户都必须面对密密麻麻的按钮和繁琐的操作步骤。
如果产品与技术团队主动担当，在后台通过智能算法、上下文预判、手势聚合和异步处理消化掉大部分逻辑判断，那么呈现在用户面前的界面就会变得极其轻巧顺滑。

计算一笔简单的商业账：研发团队多投入 10 个工时去优化一段交互逻辑，是一次性的固定成本；而如果把这点复杂度留给 1000 万名日活用户，哪怕每人每天只多浪费 5 秒钟，全社会每天就要为此虚耗近 1.4 万个小时，伴随而来的则是转化漏斗的大量流失。

二、案例 1：B站“长按一键三连”——用微手势聚合省去逐个点击成本

在内容社区产品中，创作者希望获得更多的互动数据，而平台如果提供了多种互动维度，往往会增加用户的操作负担。哔哩哔哩（B站）的“长按一键三连”正是特斯勒定律在动作层面的教科书级应用：

传统交互的繁琐路径：在B站视频详情页下方，并排陈列着“点赞”、“投币”、“收藏”、“转发”等多个独立按钮。在没有聚合交互之前，一个想全力支持 UP 主的粉丝，必须先点击“点赞”，再点击“投币”（并在弹窗里确认投币数量），最后再去点击“收藏”。三个动作分布在不同坐标，包含了多次点击与弹窗确认。
把复杂度交给代码的创新：B站设计并研发了“长按点赞键”手势识别与联动状态机——用户只需长按“点赞”按钮，就能同时触发点赞、投币和收藏 3 个操作，伴随酷炫的环形蓄力动效与“三连推荐成功”反馈，一气呵成。
体验与商业双赢：后台代码承担了长按手势判定、多接口并发请求、硬币余额校验与同步动效渲染的复杂度；而前端用户从“点击 3–4 次”简化为“长按 1 次”，操作成本骤降，社区高价值互动率随之大幅攀升。

*图 6-1：案例1：B站用户长按点赞按钮同时触发点赞、投币、收藏“一键三连”，省去逐个点击成本*

三、案例 2：微信全局搜索结果页——用分层透传化解亿级数据信息过载

特斯勒定律不仅体现在“合并操作步骤”上，有时为了降低认知复杂度，适当拉长物理点击路径反而是更优解。微信全局搜索（搜一搜）的设计便深刻体现了这一辩证智慧：

面临的极端挑战：微信承载了上亿级的数据量，涵盖聊天记录、联系人、群聊、公众号、小程序、朋友圈、百科、视频号等十几个完全异构的维度。如果用户搜索一个词，系统直接把上万条跨类别结果平铺在一个冗长的列表里，用户将瞬间陷入严重的信息过载。
场景化分层透传策略：当用户在微信搜索框输入“饿了么”时，搜索结果页在首屏并不会把所有分类结果一股脑倒出来，而是首先透传与当前用户强相关的信息：
1. 优先展示用户“最近使用”过的饿了么外卖服务小程序与拼团小程序；
2. 呈现包含该关键词的本地互动微信群聊（如“大工上海互联网互动群”）；
3. 当用户需要深入检索全网内容时，点击“搜一搜更多结果”，再进入包含“全部、百科、公众号、朋友圈、表情”等清晰标签栏的聚合结果页，按官方账号、官方服务有序归类呈现。
核心洞察：从点击次数来看，查看全网分类结果似乎“路径变长了（多点了一次）”；但对于 80% 只是想快速打开常用小程序点外卖的用户而言，首屏精准透传直接终结了搜索任务，信息复杂度大大减少。后台的个性化权重排序算法替用户完成了繁重的筛选工作。

*图 6-2：案例2：微信搜索“饿了么”首屏优先透传用户关联小程序与群聊，大幅降低信息复杂度*

四、特斯勒定律在产品与企业系统设计中的复杂度转移策略表

在58UI 设计工作室服务的大量企业级软件（如销售管理平台、云存储平台、车险选购系统）中，我们通过以下结构化方法将复杂度从用户端转移至系统端：

复杂度类型	推卸给用户的糟糕表现	由系统/代码承接的优化方案（特斯勒定律落地）	适用产品场景
动作操作复杂度	需要用户跨多个页面或连续点击 3–5 个按钮才能完成一个高频组合动作	引入手势聚合（如长按三连）、批量一键处理、快捷键或自动化工作流	内容社区互动、B端批量审批、高频工具软件
信息检索复杂度	搜索或打开看板时一次性平铺上百个数据维度，无优先级区分	基于用户角色与最近使用行为进行首屏智能透传，次要分类按需渐进展开	超级 App 全局搜索、企业 BI 数据看板、大型官网产品目录
表单录入复杂度	要求用户手动输入省市区、开户行全称、计算税率与折后总价	输入统一社会信用代码或卡号后，后台接口自动关联补全全套企业信息与计算结果	车险投保平台、企业入驻认证、跨境电商结账页

五、常见问题解答（FAQ）

问：把所有操作都合并成“一键自动完成”，用户会不会失去控制感？
答：这正是特斯勒定律需要把握的临界点。对于低风险、高共识的正向操作（如B站一键三连、智能填写常用地址），自动化与手势聚合能带来惊喜；但对于涉及资金扣款、数据删除或不可逆权限变更的操作，必须保留明确的确认步骤，不能为了省一步而让用户产生“系统自作主张”的恐慌。
问：为什么微信搜索的例子里说“虽然路径变长了，信息复杂度却大大减少”？这不是和少点几次矛盾吗？
答：交互效率不等于单纯数点击次数（Click Count），而是取决于总认知负荷（Cognitive Load）。在一屏塞满 50 个混杂结果里找目标（1 次点击，耗时 20 秒思考），远不如首屏只给 3 个最匹配项、不满足再点进二级分类页（2 次点击，每次仅耗时 1 秒判断）来得轻松。
问：B端管理后台业务逻辑极其庞大，如何用特斯勒定律进行改版？
答：先通过用户体验诊断与可用性测试梳理出各岗位角色的高频核心路径，将多表联查、状态流转校验、跨部门通知等工作交给后台规则引擎自动触发，前端只向当前角色展示“当前阶段他需要决策的那 3 个核心字段”。