评审会上有一幕做过复杂需求的人都见过。方案推到墙角了谁都没有更好的法子我们把用户某些操作可能引起的问题摆上桌得到的回复是五个字“用户不会这么用。”会议室一般会安静两秒。不是被说服了是这话没法反驳。它不是论点是预言而预言只能等开奖。《程序员应知的 97 件事》里有一篇标题就是答案你不是用户。你不是用户因为你懂得太多了这篇文章讲的是个老实道理做系统的人对系统懂得太多多到再也没法像用户一样思考。你知道那个按钮点完要等两秒所以你从不连点你知道先建档再录入所以你从不跳步你知道列表要刷新才是最新的所以你从不对着旧数据下手。你在自己的系统里永远走在正确的路径上不是因为路径设计得好是因为地图刻在你脑子里。这在心理学里叫知识的诅咒一旦你知道了一件事你就没法想象不知道它的人怎么行动。所以我觉得用户会怎么用这句话从说出口那一刻就是失真的。你不是在模拟用户你是在模拟一个懂全部实现细节的自己。我研究生读的是心理学这里忍不住掉个书袋用户不会这么用背后其实叠着两个偏差。知识的诅咒管一头你懂得太多回不去不懂的状态。虚假共识偏差管另一头人会系统性地高估别人和自己的相似程度默认自己的选择就是大多数人的选择。斯坦福有个经典实验请学生背着广告牌在校园里走一圈愿意背的人估计多数人都会愿意拒绝的人估计多数人都会拒绝双方都真诚地认为自己是主流。放回评审会用户不会这么用的完整翻译是我不会这么用而我默认用户都像我。前半句是事实后半句是偏差。麻烦的是这两个偏差谁也不豁免学过心理学照样中招所以光懂道理没用道理说服不了评审会。能说服评审会的是证据。巧了我有个证据仓库。我的铁证仓库生产告警群我们的生产环境有个告警群接口报错就往里推。干了这些年我对它有了新的理解这个群的本质是用户不会这么用的开奖记录。随便捞几条真事都脱过敏一张休假中的申请单界面上还显示着取消按钮。评审时的判断是没人会去点它毕竟单子都在休假状态了。上线后告警说点的人不止一个。事后想想毫无悬念用户哪知道你的状态机他只知道屏幕上有个按钮。同一条记录被删除两次。听起来很离谱做起来很容易手快双击了一下或者两个管理员前后脚删同一个人。告警准时来报到。一个申请撤销了又提交提交了又撤销来回打转把几张表的状态转出了不一致。评审时谁会设计这种操作路径没人。用户不设计路径用户只是在犹豫。这些案例攒多了我总结出三条铁律能点的一定会被点能连点的一定会被连点能同时点的一定会有两个人同时点。界面上存在的每一个按钮都是一份合同用户签合同的方式就是点它。为什么这句话总是输用户不会这么用输给现实输得这么稳定是有结构性原因的我数出来三条。第一样本错了。说这话的人想象的用户是自己熟练、耐心、网络好、注意力完整。真实用户里有第一次打开系统的、着急下班的、网卡到极致的、点到一半接了个电话回来忘了点到哪的。你是千锤百炼的老用户他们不是。第二规模错了。你脑补的是一个用户生产上是一万个。一万个人每天操作万分之一概率的怪路径天天发生。不会这么用在个体层面是概率在规模层面是日程表。第三动机错了。你以为用户在使用系统其实用户在完成任务。他不读文档不背流程不关心状态机他只想干完活回家。挡在他和回家之间的一切他都会用你想不到的方式绕过去。顺便说一句这毛病不是产品的专利。程序员的版本我也说过这个分支不可能走到。后来生产替我走到了。“用户不会这么用和这代码不可能走到这”是同一句话的两种方言翻译过来都是我拿自己的认知给别人的行为画了边界。架构师的接法别赌会不会算赔多少那评审会上到底怎么接这句话吵会不会是没有意义的双方手里都没有证据只有信念。架构师思维的接法是换掉问题别问会不会发生问如果发生赔多少兜底要多少钱。算完账事情通常分成两类。一类是兜底很便宜的按钮显隐跟着状态走、提交加防重、删除做幂等、关键操作先校验存在性。这类不用等评审吵出结果顺手做掉它们不是在防那个操作是在防所有想不到的操作。另一类是兜底很贵的那就把分歧记下来让数据裁决。裁决从来不缺。评审桌上吵不出结果的问题生产环境都会给出答案还附带告警时间戳。最后用户不会这么用这句话我现在还经常听到。我不反驳了反驳这句话需要预知未来而我只是个架构师不是先知。我就默默把便宜的兜底写上然后在告警群里等。一般不用等太久。你不是用户。你比用户聪明比用户懂系统所以你猜不中用户。设计能力的分水岭不在于能想出用户会怎么用在于承认想不出之后让系统在任何用法下都不失体面。有想进「编程一生」用户交流群的朋友吗