同理心不是态度，是施工工艺
「要有同理心」是做产品的人听得最多的一句话，也是最没用的一句话——它听起来像个人修养，没法验收，没法排期，开完会就散了。
但如果你把同理心拆开看，它在软件里其实是以一个个具体的工程决定存在的。每一个都能指出来、能写进需求、能测试。这一章我们拆四个最常见的。
默认值：替用户把最可能的答案先填上
打开一个新的记账软件，创建第一笔账，日期那一栏是空的，还是已经帮你填好了「今天」？
这个区别就是默认值——输入框里预先填好的、最可能被接受的答案。它背后的推理是同理心最标准的形式：用户接下来大概率想干什么？记一笔账，十次里九次记的是今天发生的事，那日期就应该是今天；新建文档，十次里九次接下来就要打字，那光标就应该已经在标题栏里闪。
默认值是一种「说了半句话就替对方补全」的能力。人和人之间，这是默契；软件里，这是设计者愿不愿意花一下午去研究「用户在这一步最常选什么」。
预判：在用户开口之前接住
比默认值再进一步的是预判。你在地图软件里搜索过一个地址，下次打开它，那个地址就在搜索历史最上面；你晚上十一点打开打车软件，它猜你要回家，家地址已经躺在那儿。
预判的本质是把「用户接下来要走的弯路」提前走掉。它的工程成本不低——要记录行为、要做推荐、要承担猜错的风险——所以它最能反映一个团队把「少让用户说一句话」看得有多重。
当然，预判有一条红线：猜错的时候必须体面。猜对了省一秒，猜错了如果挡路，用户会觉得被冒犯——「你凭什么觉得我要回家」。所以好的预判永远是「放在顺手可拿的位置」，而不是「替你做了决定」。推荐和强迫的区别，就是共情和自说自话的区别。
容错：假设用户一定会错
这一点听起来反直觉，但它是同理心最深的部分：设计的时候就把「用户会犯错」当成前提，而不是当成意外。
电话号码输入框，用户输成「138-1234-5678」带两个横杠。不友好的系统说「格式错误」；友好的系统默默把横杠删掉——因为横杠根本不是错误，是人记电话号码的自然方式。邮箱多输了一个空格、身份证号最后以为是数字 0 其实是字母 O……这些都不是「用户笨」，是人和机器对「同一个东西」的写法本来就不一样。
工程上这叫宽进（Postel 法则，「对自己发出的要严格，对接收的要宽容」的俗称）：接口尽量接受各种合理的写法，在系统内部悄悄规整好。用户甚至不会知道有这回事——这恰恰是它的美德。最好的共情是用户感受不到的共情，就像最好的服务员是你没注意到他添过水。
解释：不让用户猜后果
最后一个工程决定是解释。每个有后果的操作旁边，后果应该写得明明白白。「删除」还是「删除且不可恢复」？「提交」还是「提交后将进入审核，约 1 个工作日」？
用户在点按钮前的犹豫，本质是信息不对称：他不知道按下去会发生什么。解释就是把信息差抹平。这件事的成本低到只是一行字，但它要求写这行字的人心里装着一个问题：「如果我是第一次来，我现在最怕什么？」
大白话：同理心在这行里不是「我很善良」，是四张施工清单——默认值、预判、容错、解释。每一张都能派活、能验收、能写进测试用例。「我们的团队很有同理心」这句话不值钱；「我们表单里 90% 的字段有默认值，所有删除操作都能撤销，所有报错都过了三问检查」才值钱。
这四个决定组合起来，就是用户口中那种说不清道不明的「顺手」。下一章我们把它放到一个每个软件都有、也最容易变成灾难的场景里看：表单。