账户中心的体验报告里有2条建议没给达标率，不是漏了，是评测的人到不了那个状态

摘要：一份覆盖150多个电商站的账户体验基准里，给出的5条改进建议只有3条附了行业达标率，另外2条写着数据不足。把这5条按“评测的人要怎样才能看到这个界面”重新排一遍就会发现，有达标率的3条全都是注册个账号、点开菜单就能打分的，没有达标率的2条全都要求真的下一单、真的付钱、真的等着包裹走完。分界线不在这些问题有多重要，而在观测者进入那个状态要付多少代价。代价过线的那一段体验不会被评为差，它根本不会拿到分数，而没有分数在任何一张报表上都不是红色。

做独立站的人多少都参考过这类行业基准：某某机构评了几百个电商站，告诉你多少比例的站在某个环节做得不行，然后给几条改进建议。这类数据很有用，至少比拍脑袋强。

但今年翻一份账户与自助服务方向的基准报告时，有个细节挺扎眼。报告给了5条建议，前3条后面都跟着一个百分比——96%的站没做到、78%没做到、81%没做到，说服力很强。后2条后面没有百分比，取而代之的是一句注记：这条准则的基准数据不足，无法给出达标率。

一开始我以为是排期问题，某个季度没测完。后来把这5条建议按另一个维度重排了一次，发现它们分成两堆的方式非常干净，干净到不像是排期能造成的。

账户区的失分，全部集中在评测的人不用花钱就能走到的地方

先说清楚这不是在挑一份数据的刺

这份基准来自Baymard，一家做电商可用性研究十几年的机构。它的方法学页面写得比行业里绝大多数同类产品都透明，把测了哪些站、每场测试多长、评分怎么加权、归一化用了什么因子全都公开了。本文后面所有的推算，用的全是它自己公布的数字，一个都没往外找。

正因为它公开得足够多，才有可能拿它的数据反过来算它自己没算的那几个数。市面上大多数体验榜单连样本量都不写，那种东西压根没有讨论的入口。所以下面这些话不是质疑这份研究，而是想搞清楚一件更普遍的事：一份界面质量数据，它的覆盖范围到底是被什么决定的。

结论提前放这儿：不是被问题的重要性决定的，也不是被评测团队的专业程度决定的，而是被观测者进入被测状态所需付出的代价决定的。这个结论对任何一份体验数据都成立，包括你们自己团队上周做的那次走查。

把这5条建议原样摊开

账户与自助服务是Baymard划分的7个电商主题之一，也是唯一一个不落在下单漏斗里、而是发生在付完钱之后的主题。它给出的高层结论是：73%的桌面站、66%的移动站在这个主题上表现为中等或更差，96%的站至少有一条关键实践没做对。

底下的5条建议是这样的。第一条，账户菜单里要直接给出7条关键路径——账户首页、订单、支付方式、会员权益、心愿单、地址簿、密码，96%的站没做到。第二条，账户仪表盘要能通往全部功能，78%没做到。第三条，用户要改一张已经存好的信用卡时，给他一个看上去像是在编辑的流程，81%没做到。

第四条，用户点了取消订单之后，订单要有一个正在申请取消的中间状态，而不是若无其事地继续往下走。第五条，物流跟踪信息和节点要整合在自己站上，别把人一脚踢到承运商的页面去。这两条后面没有百分比，取而代之的是一句注记：这条准则的基准数据不足，无法提供达标率。

没有达标率的那2条，共同点在哪

把第四条摊开看。要给它打分，评测的人得先在这个站上下一单，用真实的支付方式付掉真实的钱，等订单进入系统，然后赶在它变成不可取消之前点下取消，再守着页面看接下来几十分钟里到底显示什么。这一整套动作，没有任何一步能在别人家的站上跳过去。

第五条也一样。要判断跟踪信息有没有整合在站内，得等到订单真的发货、真的产生运单号、承运商真的开始推送节点。在那之前跟踪页上是一片空白，而空白既不算做对也不算做错，打不了分——它连一个可以被评判的对象都还没生成出来。

这两条有三个共同点。一是要花真钱，二是动作不可逆，你没法把同一单取消两次，三是从触发到看见结果中间要等，短则几十分钟，长则好几天。前两点还能靠预算解决，给评测员发一笔钱去下单就是了；第三点解决不了，因为没有任何一种预算能让物流快进。

就算钱和时间都付了，也不一定能看到问题

假设一家机构真的下了决心，给每个评测员发钱去150个站各下一单。麻烦还没完：一次取消申请本身有相当高的概率会顺利通过，而顺利通过的那一次什么都测不出来。界面在顺境里通常都表现得挺得体，出丑是需要条件的。

要看到它为难时的样子，你得等到它真的为难——库存对不上、支付网关延迟、仓库已经打包、清关卡住。这些事发生不发生，什么时候发生，完全不在观测者手上。你能安排的只有观测这个动作，不能安排被观测的那件事。

这就把观测成本又抬了一层：不只是花一单的钱，而是要花足够多单的钱，才能撞上一次异常。一个自然发生率10%的问题，你要看到它三次，理论上得下三十单。三十单乘以150个站，这份预算已经不像研究经费了，像一家小公司的季度采购。

有达标率的那3条，共同点一样干净

反过来看前三条。账户菜单里有几个链接——注册一个免费账号，点开菜单，对着7项清单数一遍，完事。整个动作零成本、可逆、即时，而且同一个人一天能在40个站上重复这件事，中间连喝咖啡的工夫都有。

仪表盘能不能通往全部功能，用的是同一个免费账号，把页面滚到底，把所有能点的入口列出来，跟功能清单比一遍。也是零成本、可逆、即时，唯一的消耗是耐心。账户中心该有哪些模块在主流电商系统里是有默认答案的，比对起来并不费脑子。

第三条稍微费点事，得先绑一张卡才能看到编辑界面。但绑卡不等于付款，绑完可以随时删掉，所以仍然落在免费、可逆、即时这一档。编辑一张已存的卡在后台其实是删除加新建两步，这件事在界面上看一眼就能判断，不需要真的走完。

把5条按观测代价重排一遍

把上面拆出来的三个维度做成一张表，5条建议的位置立刻就固定下来了。左边三列是评测者要付出的代价，最右一列是这条建议在报告里的最终形态。

这张表最值得盯的不是那两条空缺，而是前三列和最后一列之间的对应有多整齐：三个不用花钱的全拿到了分数，两个要花钱的全没拿到，中间没有一条模棱两可。这种整齐度不可能是排期造成的，排期是随机的，随机切不出这么干净的边界。

顺带说一句，这张表的三列——花不花钱、可不可逆、等多久——后面还会反复用到，它基本上就是本文的那把尺子。你现在就可以拿它去量自己站上最近一次体验走查，量出来的结果多半不太好看。

分界线不是画在重要性上的

如果分界线是重要性，那有分数的应该是影响最大的那几条。但这份报告自己在另一处说得很清楚：用户最看重的自助服务功能是查在途订单的状态和到货日期。用户排在第一位的那件事，恰好落在没有达标率的那一堆里。

如果分界线是评判难度，也说不通。判断跟踪信息全不全，比判断菜单里有没有7个链接在认知上更简单，无非是对着清单比对一遍。跟踪页该给出哪几项信息是有成熟清单的，不存在评不动的问题。

唯一能把这5条干净切成3加2的维度只有一个：评测的人能不能免费、可逆、即时地把自己送进那个状态。能，就有分数；不能，就没有。这个维度跟问题重不重要无关，跟团队专不专业也无关，它是一个卡在观测动作本身上的物理约束。

没有分数和分数很低，在报表上长得不一样

这里有个容易滑过去的地方。假设那两条拿到的是很低的达标率，比如只有5%的站做对了，那它会在报告里以一根很长的红条出现，会被排进待办，会有人在会上问一句这个要不要修。低分是会说话的。

但它拿到的不是低分，是没有分。没有分不产生颜色，不进排序，不出现在任何一张对比图里。它在报告上的最终形态是一句灰色小字，位置在建议标题的最下方，字号比正文还小，读的人视线扫过去大概是零点几秒。

这跟指标体系里那些好看但不带来生意的虚荣数字是完全相反的毛病。虚荣指标是存在但不该被看重，靠认知纠偏就能治；这两条是该被看重但压根不存在，认知纠不了，因为人没办法对一个空格产生怀疑。

这条线不只画在别人的报告上

下面这句才是要紧的：这条线画在别人的评测报告上，同时也画在你自己的站上，位置几乎一模一样。

你们团队做站内体验走查的时候，会不会真的用一张个人信用卡在自己站上下一单？会不会真的申请一次取消，然后守着看后面20分钟页面怎么变？会不会真的等三天再回来看跟踪页写了什么？绝大多数团队的答案是不会，而且理由跟外部评测机构一字不差：花钱、不可逆、要等。

于是外部数据的盲区和你自己的盲区完全重合了。你翻榜单，那一块没有数据；你做走查，那一块没人走到；你看监控，那一块页面返回的全是200。三边都安静，安静得很像是那块确实没问题。这不是有人做错了判断，是没有人做过判断——接下来要拆的就是这件事。

这个主题跟其他6个主题不一样在哪

Baymard自己点出了一件很关键的事：在它划分的7个电商主题里，账户与自助服务是唯一一个通常不属于直接购买漏斗、而是发生在购买之后的。首页、类目、搜索、商品列表、商品页、购物车与结账，这6个全在漏斗里，账户与自助服务在漏斗外面。

在漏斗里意味着什么？意味着这一环出问题，转化率会掉，而转化率是有人盯的。结账环节的弃单率能被拆成九个具体成因，就是因为漏斗每一步的通过率都在被记录，掉了立刻看得见。

在漏斗外面意味着相反的事：这一环出问题，转化率纹丝不动，因为钱早就付过了。它的代价会以另外几种形式出现——客服工时、退货率、复购间隔变长、差评里多出一类抱怨，而这四样分别记在四个部门的账上，没有一样记在体验团队的账上。

没有分数的事情，会一直排不上队

还有一个后果值得先提一句，它是这条边界最长远的影响：一件事如果没有分数，它就很难进入排期，而且是年复一年地进不去。

排期这件事本质上是在比较。这个季度是做搜索还是做筛选、是改商品页还是改结账，团队会把各自的数字摆出来比一比——转化率差多少、行业达标率多少、影响多少用户。能摆出数字的事情会被讨论，摆不出数字的事情连上桌的资格都没有。

购后这一块的尴尬在于，它不是数字不好看，是没有数字。提出来只能靠一句我觉得这块体验不太行，而这句话在一个摆满百分比的会议室里毫无重量。任何需要长期投入的事情都得先有一套能说话的数，这是组织运作的基本规律，不因为谁更有洞察力而改变。

所以这类问题的典型命运是：每年都有人提一次，每年都排不进去，三年之后它变成了一个大家都知道但没人负责的老问题。而它之所以变成老问题，起点只是当初没有人能给它算出一个数。

为什么这件事对独立站更要紧

大平台在这块有一层缓冲：客服团队足够大，站上做不到的事有人接得住，用户抱怨两句还是买。独立站没有这层缓冲，一个人可能同时管运营、客服和补货，购后出的每一个问题最后都变成他自己的时间。

更现实的一点是，独立站的复购本来就更依赖购后这一段。会员体系和积分能把老客留下来的前提，是这个人上一次收货的过程没有让他觉得糟心。第一次买东西是广告的功劳，第二次买东西是购后体验的功劳。

而这一整段，恰好落在所有公开数据的盲区里、落在自己走查的盲区里、也落在监控的盲区里。你在最需要参考的那件事上，能拿到的外部信息最少。这不是行业不重视，是这一块的观测成本天然比别处高一个量级。

同一份报告里，为什么有2条建议永远不会有达标率？

把数据不足这四个字当真

报告里那句注记的原话是：这条准则的基准数据不足，无法提供达标率。这句话读起来像个临时状态，像是再攒两个季度就能补上。但如果去算一下补上它需要发生什么，会发现它不是临时的。

基准的样本是150多个站。要给正在申请取消这条准则算出一个达标率，意味着评测方得在这150多个站上各自完成一次真实下单，各自完成一次真实的取消申请，各自守着看结果。这不是补测两个季度的问题，这是把整个基准的成本结构换掉。

而且这还是最乐观的算法，它假设每个站下一单就够。前面说过，取消申请有相当高的概率一次就顺利通过，顺利通过等于没观测到边界情况，那就得再下一单。真要把这条准则测扎实，单量得往上翻好几倍。

所以那句注记的准确含义不是还没测，而是在现有的方法框架下，这条准则测不了。它不是一个待办事项，是一个结构性的边界，而边界是不会因为时间过去就自己往外挪的。

要凑齐这条准则的样本，需要发生什么

不妨把这个成本具体拆一遍。第一步是采购：在150个站上各买一件商品，客单价按60美元算，光货款就是9000美元，还没算国际运费和可能的关税。

第二步是支付：这些订单得用真实的卡付，而同一张卡在150个陌生站上连续下单，大概率会在第20单左右被风控拦下来。真要做，得准备一批不同的支付工具和不同的收货地址，这件事本身就是一个项目。

第三步是时间：每一单从下单到取消窗口关闭，短的几十分钟，长的一整个工作日。要在150个站上都卡准这个窗口，需要一张精确到分钟的排班表，而且不能出错，因为错过窗口的那一单是没法重来的，钱已经花了，机会已经过了。

第四步是收尾：没取消掉的那些订单会真的发货，评测方得收货、退货、跟每个站的客服交涉。这一步的工作量大概率超过前三步之和，而且它产生的全是行政成本，一条数据都不产生。

三个维度里，前两个能用钱解决

花钱这个维度是最容易解决的，因为它可以直接换算成预算。9000美元的货款对一家机构来说不算天文数字，真要做也做得起，无非是这份报告的售价要往上调。

不可逆这个维度稍麻烦，但也不是没法处理。不可逆的本质是每次机会只有一次，对策是提高每次的成功率——把流程写细、把排班做准、让熟手来做。这些都是管理问题，管理问题总有解。

换句话说，如果只有前两个维度，这两条准则最终还是能拿到达标率的，只是贵一点、慢一点。决定它们永远拿不到分数的，是第三个维度。

这一点值得单独拎出来说，因为它同时解释了另外一件事：为什么做实验时样本量算得再准，也没法把一个需要等三天才出结果的实验压缩成一小时。有些成本是可以用钱换的，有些不能。

第三个维度为什么用钱解决不了

时间这个维度的特殊之处在于，它不只是一段需要被消耗的等待，它本身就是被观测对象的一部分。

用户申请取消之后那20分钟里的真实体验是什么？是不确定。他不知道申请有没有被收到，不知道会不会成功，不知道要不要现在就去联系客服。这份不确定就是这段体验的全部内容，也是这条准则真正想要考察的东西。

如果你为了省时间，用后台直接把订单状态改成已取消，然后截图打分——你确实省下了20分钟，但你同时把不确定这个变量删掉了。剩下的那张截图上，界面显示得清清楚楚，看起来完全没问题。

这是本文最关键的一个转折：加速一段体验，等于把这段体验里唯一值得测的东西拿掉。钱能买来更多次观测，买不来一次被压缩过的等待，因为压缩过的等待已经不是等待了。

三句可以随身带走的判据

把上面三个维度翻译成三个问题，就得到一把很小但很好用的尺子。拿到任何一份体验数据、任何一次走查报告、任何一份自查清单，都可以问这三句。

第一句：要看到这个界面，做评测的人得先付出什么？免费注册，还是真金白银付一笔钱？
第二句：这个动作能不能撤销、能不能重复做？一个人能做40次，还是一辈子只能做一次？
第三句：从触发到界面出现，中间隔多久？几秒钟，还是几天？

三句里有任何一句的答案是贵的那一边，这一块的数据质量就要打折；三句全是贵的那一边，这一块大概率根本没有数据。而它没有数据这件事，通常不会写在报告的显眼处。把两边的典型答案列出来，用起来更顺手。

用这三句去量本文开头那5条建议，答案完全对得上：前三条三句全是便宜的那一边，后两条三句全是贵的那一边。中间没有一条混着的，这也是我相信这把尺子有效的原因——它不是事后编出来解释结果的，它切出来的边界跟实际边界严丝合缝。

为什么第三句最狠

前两句问的是钱和机会，这两样东西都在提问者的掌控范围内，答案再难看也是能改善的。第三句问的是时间，而时间不听任何人的。

更要命的是第三句有一个隐藏的门槛：一次可用性测试会话通常在1小时左右。任何一个需要超过1小时才能出现的界面，都不可能在一场标准测试里被看到。这不是水平问题，是测试这个形式本身的容量上限。

那超过1小时的界面归谁看？答案是没有人。它不在实验室里、不在走查清单上、不在监控告警里，因为监控系统只会在页面出错时报警，而这些页面在技术上完全正常，返回200，数据也是对的，它们只是没说出用户此刻需要的那句话。

没有报错的问题最难被发现，因为发现它的唯一途径是有人以用户的身份、在用户的那个时刻，打开那一页看一眼。而这件事在大多数公司里不属于任何一个岗位。

这跟数据被谁筛掉是两回事

这里要跟一件容易混淆的事划清界限。前段时间我拆过一个自动化工具公布的准确率是怎么把分母划小的，那是发布方主动做了一次筛选：有些项没达标，于是被移出了统计范围，数字因此变好看。

本文说的是另一件事，性质完全不同。那两条准则不是被谁筛掉的，是从来没有人到过那个现场。前者是有数据但不给你看全，后者是压根没有数据可看。前者能靠追问分子分母揭开，后者追问也没用，因为对方给的答案是诚实的：确实没测过。

两者的补救方式也不一样。分母被筛小，解法是要求对方公开纳入标准；根本没测过，解法只能是自己去测，或者接受这一块永远只能靠推测。前者是透明度问题，后者是可及性问题。

顺带说一句，这两种毛病经常同时出现在一份材料里，而且后者更难发现——因为一份报告不会为它没做过的事专门写一节。

一条可以留在手边的说法

把上面这些收成一句话，大概是这样：

一段体验能不能被测量，取决于观测者能不能以低于体验本身的代价进入它。当进入代价接近或超过真实用户付出的代价时，测量就停止了——而停止的那个地方，不会留下任何标记。

最后半句是重点。如果测量停止的地方会亮一盏灯，事情就好办多了，大家会知道那儿有一片没探过的区域。可它不亮灯，它在报告上表现为一行小字，在你自己的走查清单上表现为一条没写的条目，在数据看板上表现为一块空白面板。

空白从来不会自己提醒你它是空白。接下来几节要做的，就是把这块空白的形状描出来——它有多大、边界在哪、别的行业遇到同样的问题时是怎么处理的。

这把尺子顺手解释了另一件事

如果你翻过几份不同机构出的电商体验榜单，可能注意过一个规律：它们的详细程度是不均匀的。首页、搜索、列表、商品页、结账，这几块永远被拆得极细，几十上百条准则；而付完钱之后的那一段，通常只有薄薄几条，有时干脆并进一个叫其他的分类里。

过去我以为这是因为购买之前的环节对转化率影响更直接，所以研究资源自然往那边倾斜。用上面三句判据重新看一遍，会发现有个更简单的解释：购买之前的所有状态，对观测者来说都是免费、可逆、即时的。你可以在一个陌生站上把商品页翻上一百遍，一分钱不花，随时可以重来。

而付款这个动作，恰好是这条线上的第一道闸门，它一次性把三个维度全部翻转过来：从这一步开始要花真钱，从这一步开始动作不可逆，从这一步开始每件事都要等。不是研究者选择了不看购后，是购后这一侧的门票贵了好几个量级。

这个解释还有个附带的好处，它可以被证伪。如果我的说法成立，那么在那些购买动作本身很便宜的领域——比如免费注册就能用完整功能的软件产品——购后体验的研究应该明显更充分。这一点跟我自己的观察是对得上的：软件产品的退订流程、账号注销流程被研究得比电商的退货流程细致得多，因为研究它们只需要注册一个免费账号。

这件事不只发生在电商

把三句判据换个场景就会发现，同样的边界到处都是。保险的理赔流程只有真出了事才走得到，所以关于投保页面的体验研究汗牛充栋，关于理赔页面的几乎没有。银行的开户流程被反复优化，销户流程很多人这辈子只走一次，也就没人研究。

再往近处说，退款和拒付这条链路在多数团队里是靠SOP文档撑着的，而不是靠体验设计撑着的。原因一样：要观察一次真实的拒付，你得先制造一次真实的拒付，这件事的代价高到没人愿意为了研究去做。

共同点很清楚：凡是只有在出了问题、花了钱、等了很久之后才会出现的界面，都缺研究、缺数据、缺标准，也缺人看。而这些界面偏偏是用户情绪最激烈的时候看到的，一个体验做得糟糕的理赔页面，杀伤力远超一百个做得平庸的商品页。

最后一行是那个能证伪的对照组。软件产品的退订和注销流程被研究得相当细致，而它跟前三行的区别只有一个：走完它不需要花钱、不需要等待、随时可以重来。研究密度跟重要性无关，跟门票价格有关。

说得刻薄一点，这个行业把绝大部分精力花在了用户心情最好的那几分钟上，因为那几分钟最好观察。剩下那些心情很差的时刻，不是没人在乎，是没人看得见。

这个分布还有个连带后果：由于研究都集中在门票便宜的那一侧，行业里积累下来的设计经验也全都长在那一侧。关于商品页该怎么排、结账该几步，你能找到几十套成熟方案；关于物流停更第4天页面该说什么，你连一个可以抄的样板都找不到，只能自己想。经验的稀缺跟研究的稀缺是同一件事，中间隔的只是几年时间。

评分体系说自己量的是第一次来的人，账户中心却只有回头客会打开？

先看这套评分自己是怎么定义的

Baymard把评分方法写在一个单独的方法学页面上，公开可读，不需要付费账号。这一点值得先夸一句，因为大部分做榜单的机构不会把评分口径摊开给人看。

这一页里有一句关于总分的定义，原话大意是：分配给每个被评测站点的总体验分，本质上表达的是一个首次访问的用户在这个站上会获得多好或多差的体验，判据是那794条准则。这句话在页面上出现了两次，措辞几乎一样。

注意里面那个限定词：首次访问的用户。这不是随口一说，它是这套分数的定义本身。分数在回答一个很具体的问题——一个从没来过的人，第一次落到这个站上，体验会怎么样。

站点评测的默认协议也是围着新客转的

同一页往下翻，还有一句讲评测怎么执行的：所有站点评测都由自己的员工完成，并且都是按一个新顾客会经历的样子来做的，因此没有使用任何已有账号或浏览历史。

这个设定有它的道理。如果评测员用一个老账号去看，站点会给他推个性化内容，会记住他的收货地址，会跳过一些新用户必须走的步骤，评出来的分就不可比了。个性化会根据登录状态和历史行为改变页面呈现，这在评测里是必须被摁住的变量。

所以用新客身份、不带账号、不带历史，是一个方法学上完全正确的选择。它保证了335个站被放在同一条起跑线上。到这里为止，一切都很扎实。

那个括号里的例外

问题出在那句话的结尾。它后面跟了一个括号，括号里写着：账户与自助服务的基准评测除外。

整份方法学页面，讲评测执行方式的地方就这一句总纲，而这句总纲带了唯一一个例外，例外正好就是本文在谈的这个主题。七个主题里，有六个可以按标准协议评，第七个不行，得单独开一条路。

这个括号非常诚实，也非常重要。它等于把这件事写在了明面上：账户与自助服务这个主题，没办法在这套评测协议下被评测，因为协议要求评测员是新客，而这个主题的界面只有登录过、买过东西的人才看得见。

换个说法，这套协议的第一条前提，和这个主题的第一条前提，是直接打架的。你必须放弃其中一条才能往下走，而放弃的那一条就写在括号里。

账户中心按定义只有回头客会打开

这不是一个可以商量的设定。账户菜单里那7条路径，第一条是订单——一个没下过单的人点进去看到的是空的。心愿单是空的，地址簿是空的，支付方式是空的，会员权益还没开始累积。

用一个刚注册的空账号去评这些界面，你评到的是空状态的设计，而不是真实使用中的设计。这两件事的差距可以非常大：一个订单列表在有1条记录、有20条记录、有200条记录时是三种完全不同的界面，而排序、筛选、分页这些真正会出问题的地方，只在第三种情况下才暴露。

所以这里有个双重约束。用新客身份评，评不到内容；用老客身份评，又违背了让335个站可比的那条前提。两条路都不通，只能破例。

两个定义正面冲突，而且都写在同一页上

把这件事完整摆出来是这样的：总分的定义是首次访问用户的体验；评测协议的默认执行方式是新客身份；而账户与自助服务这个主题，按其性质只有回头客会进入。

三句话都是真的，都写在同一份公开文档里，中间只隔了几个段落。但因为它们分别出现在讲总分、讲协议、讲主题的三个不同章节里，读的人几乎不可能在同一时刻把它们放在一起看。

我第一次读这一页时也没看出来，是后来为了核对样本量再翻回去，才注意到那个括号。这类东西的特点就是这样：它不藏着，它在明处，只是被章节结构分开了，而人读长文档是一节一节读的。摆成一张表就一目了然了。

最后一行是这张表里最要紧的。前三行都写在文档上，第四行没有人会专门写出来，因为它太显然了——而恰恰是这个太显然的事实，让前三行凑到一起时产生了矛盾。

这不是错误，是一把尺子被借去量了另一样东西

这里要说清楚：上面这些不构成对这份研究的指控。评测方明确写出了例外，没有含糊过去，这已经比行业平均水平高出一截。

真正的问题在于分数的使用者，也就是我们这些看榜单的人。那个73%和它旁边六个主题的分数并排放在同一张图上，看起来是六把同款尺子量出来的六个数，实际上第七把尺子的握法跟前六把不一样。图上不会标这件事，标了也没地方标。

这就像体检报告上七项指标并排列着，其中六项是空腹抽的血，第七项是饭后抽的，脚注里写了，但报告的排版让七个数字长得一模一样。数字本身没问题，把它们放在一起比较才有问题。

归一化让主题之间可以横向比较，而这放大了问题

方法学页面里还讲了一件事：每个主题的分数会经过一个归一化因子处理，一半依据资深研究员定义的业界最佳实现，一半依据335个站的分数分布。这么做的目的写得很直白——让不同主题之间、不同年份之间可以横向比较。

归一化本身是个好设计，它让分数不会因为某个主题的准则更苛刻就系统性偏低。但它有个副作用：它把七个主题的分数强行放到了同一个可比空间里，而这恰好抹掉了第七个主题在采集方式上的特殊性。

换句话说，归一化处理的是准则难度的差异，处理不了观测方式的差异。前者是刻度问题，后者是尺子的握法问题，后一种差异归一化算法看不见，因为它拿到的输入已经是分数了。

可用性测试那一侧也破了一次例

更能说明问题的是另一处。这家机构做用户研究的主力方法是实验室里的一对一出声思考测试，每场大约1小时，参与者被给2到4个任务，一轮下来测好几个站。7个主题里6个都是这么测的。

账户与自助服务这个主题的做法不一样：它既做了实验室测试，也做了远程主持测试，而远程那部分的招募条件是——参与者必须是即将在某个电商站上真实购物的人。然后研究者跟着他这一单走，在他每一次跟订单发生互动的时候发起一场小型测试：下单、收确认邮件、上网查物流、收货、发起退货、查退货进度、收退货确认。

这是整份方法学里唯一一个跟随真实订单生命周期、拆成多次会话的设计。而且实验室那一侧用的是合成账号，任务措辞是假设你刚下了这一单，你会怎么跟踪它——参与者并没有真的下单，是被要求想象自己下过。

一个主题需要破两次例，说明了什么

把两处例外放在一起：基准评测破了一次例，可用性测试破了一次例，破的都是同一件事——观测者进不去那个状态，所以必须换一种进入方式。

一家机构愿意为一个主题改两次方法，说明他们清楚知道这里有个坎。能改的地方他们都改了，改不动的那部分，就变成了报告最后那两句数据不足。这两句注记不是疏忽，它是这条边界在文档里留下的唯一痕迹。

而这个痕迹之所以值得研究，是因为它不只属于这一家机构。任何人要研究购后体验，都会撞上同一堵墙，区别只在于有没有在文档里把撞墙这件事写下来。第三方工具的数据能有多准，本来就得靠估算方法学去反推，而大部分工具连方法学页都没有。

凡是要登录才能看到的界面，都有这个毛病

把这件事再推远一点。账户中心只是一个具体例子，它背后是一整类界面：所有需要先登录、先有数据、先发生过什么才能看到的页面。会员专区、订阅管理、积分明细、发票中心、退货进度，全在这一类里。

这类界面有个共同特征：它们通常是产品里最重要的部分，因为老客户的钱是从这儿来的；同时它们又是最难被外部研究覆盖的部分，因为外部研究者进不去。积分账本能不能被用户自己核对清楚，这种问题只有攒了几百分的老会员才提得出来。

所以你会看到一个很拧巴的分布：能查到的公开体验研究，绝大多数集中在登录墙之前；而做产品的人真正需要参考的地方，绝大多数在登录墙之后。门槛把研究者和真实用户分在了墙的两边，而墙内的样子只有真实用户看得见。

这也解释了为什么很多团队做会员区改版时找不到什么可参考的资料，只能靠拍脑袋和抄同行。不是资料写得不好，是压根就少有人能进去把它写出来。

下次看榜单，多问一句什么

说了这么多方法学，落到实用层面其实只有一个动作：拿到任何一份体验数据，先翻它的方法学页，找一句话——他们是用什么身份看这些站的。

如果答案是新客身份、不带账号，那这份数据在登录墙之前是可信的，登录墙之后要打个大折扣。如果他们连这句都没写，那这份数据的适用范围你就完全不知道，只能默认它只覆盖了公开页面。

第二句要找的是：他们有没有真的完成过交易。这句通常没有明确答案，那就看间接证据——报告里有没有关于付款之后的具体发现，有没有出现只有真实订单才会产生的细节，比如确认邮件的内容、跟踪节点的更新频率。没有这些细节，基本可以判断他们没走到那一步。

这两句加起来大概花五分钟，而它决定了后面几个月你要不要拿这份数据去支撑排期。把外部数据带进跨职能讨论的时候，适用范围是最该被讲清楚、也最经常被省掉的那一句。

335个站的榜单，到了这个主题上为什么只剩150个？

把两个数字放在一起看

方法学页面写着，这套基准覆盖335个美欧头部电商站，累计275000多个人工打出的加权体验分，评的是794条准则。这是整个数据库的规模。

而账户与自助服务这一篇写着，本次分析汇总的是150多个被评测站点的5400多个体验分。同样是这家机构、同一个数据库、同一套评分体系，到了这个主题上，站点数从335变成了150出头。

两个数字都是公开的，只是从来不会出现在同一段话里。一个在方法学页，一个在文章正文的第一节，中间隔着一整个网站。

先算覆盖率

150除以335等于44.8%。也就是说，这套基准里有55.2%的站，在账户与自助服务这个主题上是没有分数的。不是分数低，是没有。

这不难理解。要给一个站的账户区打分，评测员得在这个站上注册、登录、有一段像样的使用痕迹，最好还有过订单。任何抽样设计都要在覆盖面和单次成本之间做取舍，单次成本一高，覆盖面就必然往下掉。

335个站里挑150个来做这件事，从工程角度是完全合理的决定。问题不在这个决定，而在于最终发布出来的那个73%，读者会本能地以为它是在335个站上算的。

那185个站去哪了

被留下的185个站，在这个主题上既不是好也不是差，它们是不存在。你在那张分数分布图上找不到它们的点，不是因为点太小，是因为压根没画。

更微妙的是，这185个站大概率不是随机挑出来的。真要选150个站做账户评测，谁会被选中？合理的选法是挑那些账户功能比较完整、值得评的站，也就是大站。功能简陋到没什么可评的站，天然会掉出样本。

如果这个推测成立，那73%这个数还偏乐观了——因为掉出样本的那批站，账户功能本来就更弱。这个方向的偏差没法量化，我也不打算硬编一个数出来，但方向是确定的。

再算每个站被打了多少个分

5400多个分数摊到150多个站上，每个站大约是36个分数。这个数可以拿来跟整个数据库比一比。

275000个分数摊到335个站上，每个站大约是821个分数——这跟794条准则基本对得上，说明在通常情况下，一个站会被794条准则逐条过一遍。

36比821，相差23倍。换个说法：一个站在账户与自助服务上被打的分数，只占它全部体验评分的4.4%。

36这个数意味着什么

方法学页面还提到，794条准则分布在7个主题里，每个主题通常是50到130条。取中位数90条来算，账户与自助服务这个主题手上应该有90条左右的准则。

但每个站实际只拿到36个分数。也就是说，即便在那150个入选的站里，平均每个站也只有四成左右的相关准则被真正打了分，剩下六成要么不适用，要么没评。

这一层跟前面的覆盖率是叠加的，不是替代的。先是55%的站整体缺席，然后在剩下的站里，又有六成的准则没有落地。两层乘起来，实际被评到的判断点大概占理论总量的18%。

把这几个数并排放一次

这些数字单独看都不刺眼，摆在一起才看得出形状。

最右边那一列是我算的，前三列全是对方公布的原始数字。没有一个数字是错的，也没有一处夸大，但把它们并排之后，那个73%的分量跟你第一眼读到时的感觉已经不太一样了。

那个73%究竟是在什么基数上算的

把上面的推算收一下，73%这个数的准确含义大概是：在150多个被选中评测的站里，有73%的站，在它们各自被实际打分的那三十来项上，加权得分落在中等或更差的区间。

这句话比原始表述长得多，也啰嗦得多，但它是准确的。而原始表述在传播中会进一步缩短，最后变成一句四个字的结论：账户体验普遍很差。

信息在传播里的损耗从来不是随机的，它按长度和好不好当标题来有序发生。适用条件在这两个维度上都排最后一位，所以它总是第一个掉的。

不适用项不进分母这件事，这里只说一句

方法学页面提到，一个主题的分数是把主题内全部准则的得分汇总后，除以适用准则的总数，这样标为不适用的项就不会影响分数。

这个处理本身是标准做法，没什么可挑的，我也不打算在这儿展开——一个百分数的分母怎么被划定是另一件事，跟本文说的观测边界不是同一个问题。

提它只是想说明一点：前面算出来的那些缩水，跟分母怎么算无关，它们发生在更前面一步——在数据被生成之前，而不是在数据被汇总的时候。

缩水不等于造假，这一点得说清楚

上面这一整节，没有一句是说这份数据造假或者不该用。恰恰相反，它是我见过的同类数据里最经得起核对的一份，因为它把核对所需要的每一个数字都公开了。

真正做研究的人都知道，任何一份大规模数据都会在采集环节缩水，区别只在于缩水的幅度写没写出来。这份数据的问题不是缩水，是缩水的信息和结论的信息被放在了不同的页面上。

而读者读的是结论那一页。方法学页在网站的另一个栏目里，需要主动去找，而且长达三万多字符。绝大多数人不会翻，包括很多引用这份数据写文章的人。

对你的意义：置信度该打几折

落到实用上，这些推算只回答一个问题：拿这份数据去支撑你的排期决策时，该给它多大权重。

我的建议是分两档。关于账户菜单、仪表盘、表单这类静态结构的结论，可以当作可靠数据用，因为它们的观测成本低，样本量再打折也够用。这部分的百分比拿去说服老板是站得住的。

而关于购后流程、异步状态、跨系统跳转的结论，只能当作定性提示用，不能当数据用。它们背后的样本可能只有个位数，甚至只有几段访谈记录。指标体系里最危险的动作就是拿一个口径的数去替换另一个口径的数，这里是同一个道理。

96%这个数还能再挖一层

报告开头有一句关键数据：多达96%的电商站，至少有一条关键的账户与自助服务最佳实践没做对。这句听起来是个总结性的大数，但它跟下面那三个百分比之间其实有算术关系，可以拿来互相验证一下。

三条有达标率的建议分别是96%、78%、81%的站没做到。如果这三件事互相独立，那么一个站三条全做对的概率是4%乘22%乘19%，等于0.167%。反过来说，至少有一条没做对的比例应该是99.83%。

可报告给出的数是96%，明显低于99.83%。这不是矛盾，而是说明一件事：这三条不是独立的，它们高度正相关——做对了一条的站，大概率另外两条也做对了。

正相关这件事对你意味着什么

账户体验的质量不是一条一条随机掉落的，它是成团出现的。一个站要么这几件事都想过、都做了，要么一件都没想过。中间状态比统计上应有的比例少得多。

这个结论对做站的人其实是个好消息。如果失分是随机分布的，那你就得一条一条去查、去补，永远补不完；而如果失分是成团的，那它的根因就只有一个——有没有人系统性地把这块过一遍。

换成排期语言：账户区不适合零敲碎打地改，适合一次性拨出两三周做一轮完整梳理。分十次改，每次改一条，效果会明显差于集中改一次，因为这些问题共享同一个根因，而根因不会被单条修复触及。

移动端那个66%的样本更小

报告同时给了移动端的数：66%的移动站表现为中等或更差，比桌面端的73%好一些。乍看是移动端做得更好，但这个对比要小心。

移动端账户区通常功能更少——很多站在手机上直接砍掉了地址簿的部分功能、砍掉了发票下载、砍掉了部分订单操作。功能少意味着可评的准则少，可评的准则少意味着不适用项多，而不适用项不进分母。

所以移动端那个看起来更好的分数，有一部分可能来自它做得少而不是做得好。这个方向我没法用公开数据证实，只能提醒一句：两个数字能不能对比，取决于它们的分母是不是一回事。

这套推算的方法本身可以复用

上面这几节做的事情其实只有一个套路：把一份材料里散落在不同位置的数字抄到同一张纸上，然后做除法。整个过程不需要任何专业工具，也不需要额外数据。

它之所以有效，是因为发布方通常会在方法学里如实交代样本规模，在结论里只写百分比，而这两处几乎从不相邻。把它们放到一起，多数时候就能看出这个百分比的真实分量。

我的习惯是拿到任何一份行业报告先做三件事：找样本量、找采集方式、找有没有哪个结论没配数字。第三件最容易被忽略，但往往最有信息量——一份报告不写数字的地方，通常不是因为不重要，而是因为测不了。

提醒一句：别拿这些数去抬杠

最后说个实际的。上面这些推算适合用来给自己的判断定权重，不适合拿去会上驳同事的方案。

原因很简单：这些数削弱的是那份报告的适用范围，而不是它的结论方向。账户体验普遍做得不好这件事，即便打了折仍然成立；打折影响的是你该给它排多高的优先级，不是该不该做。

把方法学分析当武器用，最后往往会变成一场关于数据可不可信的辩论，而真正要决定的那件事——这季度要不要抽两周把账户区过一遍——反倒没人谈了。这种会我参加过，不太值得。

国际方法学是怎么定义默认路径的，它假设用户会不会填错？

换一个毫不相干的来源来验证

到这里为止，所有论据都来自同一家机构的公开材料。一个结论只有一个来源，说服力是有限的，所以这一节换一份完全不相干的文件来看看：如果观测代价真的会划出一条边界，那么在别人的方法学里，这条边界也应该留下痕迹。

我挑的是W3C的网站无障碍一致性评估方法学，业内一般叫它WCAG-EM。它跟电商体验研究没有任何关系，作者不同、目的不同、评估对象不同，唯一的共同点是它们都要面对同一件事：怎么在一个有无数页面和状态的网站上，选出一批能代表整体的样本来评。

这份文件的地位比较特殊，它是全世界唯一一份把网站评估该怎么抽样、怎么走流程、怎么写报告规定成方法学的公开规范。凡是做正式无障碍审计的机构，基本都按它来。

它明确要求样本必须包含完整流程

这份规范的第3步是选样本，其中有一条单独的要求叫包含完整流程，原文写着：所选样本集必须包含属于同一个完整流程的所有页面或视图。

意思很直白。你不能只挑购物车页评一评就说自己评过结账了，从加购到付款成功之间的每一个页面都得进样本。这条要求在方法学里是硬性的，不是建议。

更狠的是第4步里专门有一小步，就叫检查所有完整流程。也就是说，走流程不只是选样本时要考虑，评的时候还要单独走一遍。这份规范对流程的重视程度，比绝大多数体验评测都高。

那么完整流程是怎么定义的

关键就在这儿。规范给完整流程配了一个概念叫默认序列，并且明确说明默认序列遵循标准用例，描述的是穿过整个流程的默认路径。

紧接着是那句最要命的话，原文大意是：它假设不存在用户输入错误，也不存在对额外选项的选择。

请注意这句话的性质。它不是在描述现实中的用户，它是在给评估工作定义边界——为了让评估可执行、可复现、可比较，必须先假定被评估的那次通过是一次干净的通过。这是个工程上完全合理的取舍，但它取掉的那部分，正是本文一直在谈的那部分。

它拿电商结账当例子，逐条列出了排除什么

更巧的是，这份规范举例时用的正是电商。它说，对一个网店应用来说，用户会走到结账、确认默认支付方式、正确填写全部支付信息、完成购买，然后列出这个过程中不包括的事情。

不包括的部分是：不改动购物车里的内容，不使用已保存的用户资料，不为支付方式或收货地址选择备选项，不提供任何错误输入，等等。四件事加一个等等，全部写在规范正文里。

把这四件事念一遍就会发现问题：改购物车、用已存的地址、换个支付方式、填错一次——这几件恰恰是真实用户在结账时最常做的动作。规范排除掉的不是罕见情况，是日常情况。

右边那一列的理由全都成立，没有一条是敷衍。这也是这条边界最难对付的地方——它不是由懒惰造成的，是由可复现这个正当要求造成的，所以你没法通过让别人更认真来消除它。

再看它对不在流程里的样本怎么规定

规范第4步的第一小步，讲的是怎么检查那些不属于完整流程的普通页面。这里有一句同样值得抄下来的话。

它要求检查样本的全部组成部分，然后跟了一个限定：不激活任何功能、不输入任何数据、也不以其他方式发起任何流程。这些交互留到后面的步骤再评。

这句话把评估的默认姿势描述得非常准确——不点、不填、不发起。看，而不是用。这不是懒惰，是为了让一次评估的结果可以被另一个人在另一台机器上复现出来，而任何一次输入都会引入不可复现的状态。

可复现和真实之间，规范选了可复现

把上面两处放在一起，这份规范的取舍就很清楚了：在可复现和贴近真实之间，它选择了可复现。而且它选得很坦白，把假设逐条写在正文里，不藏。

为什么必须这么选？因为无障碍评估的结果是要被引用、被对比、甚至被拿去做合规依据的。如果甲评估员填错了一次触发了一个错误提示、乙评估员没填错所以没触发，两个人给出的结论就不一样，这份评估就失去了作为依据的资格。

所以这个取舍是必要的。但它的代价同样确定：凡是只有在输入错误、选了备选项、改了主意之后才会出现的界面，都不在默认评估范围内。而这些界面出问题的概率，明显高于顺利那一条路上的界面。

两份不相干的文件指向了同一件事

现在把两份材料并排：一份是电商体验基准，它在购后那两条准则上写了数据不足；一份是无障碍评估方法学，它在默认路径的定义里写了假设不出错。

这两份文件的作者不认识彼此，目的完全不同，一个是商业研究一个是国际标准。但它们各自划出的可评估边界，形状是一样的：顺利的、即时的、可重复的那一部分进得来，出错的、要等的、一次性的那一部分进不来。

两个独立来源指向同一个结论，这条边界就不太可能是某一家的方法缺陷，而更像是评估这件事本身自带的性质。这也是我愿意把它提炼成一条通则的原因。

规范自己承认了一件事：地址不够用

这份规范里还有一句话，读的时候没在意，后来越想越觉得重要。它在讲怎么记录流程样本时说：多数情况下必须记录并写明从一个样本走到下一个样本所需的动作，以便日后能被复现，例如填写姓名和地址、然后点击提交按钮。

然后是那半句：多数情况下，网址本身不足以标识一个完整流程中的样本。

这句话说的是无障碍评估的记录问题，但它顺手描述了一个更普遍的困境。一个表单控件在不同选择下呈现的界面可能完全不同，而它们共享同一个网址。你没法把一个状态用链接的方式交给别人。

不可指认的界面，连报个问题都难

顺着上一节往下想。一个界面如果没法用网址指认，会连带失去很多东西。

它没法被贴进工单——客服只能写用户说他看到订单还是显示已接收，而不能贴一个链接让开发点开看。它没法被加进监控——监控是按网址巡检的，而这个网址在大多数时刻都是正常的。它没法被同事复现——你截图发过去，对方点开链接看到的是另一个样子。

购后的那些状态，几乎全都是不可指认的。订单详情页的网址一年到头不变，可它在下单后10分钟、在申请取消后20分钟、在物流停更9天时，显示的是三个截然不同的界面。而这三个界面在任何系统里都叫同一个名字。

这一条能借走的东西

从这份规范里，做电商的人其实可以直接借走两样东西，都不需要懂无障碍。

第一样是完整流程这个概念。做体验走查时，别按页面列清单，按流程列清单，并且把流程的起点定在用户产生意图的那一刻、终点定在他的目的达成或彻底放弃的那一刻。按页面列，永远列不到那些没有独立网址的状态。

第二样是记录动作序列这个习惯。既然网址不够用，那就把到达一个界面所需的动作写下来：用哪个账号、下过哪一单、在第几分钟、点过什么。这几行字就是那个界面的地址，有了它，这个界面才第一次变成一个可以被讨论的对象。

这两样加起来成本几乎为零，只是换个写清单的方式。但它们能把一批原本不存在的界面，变成清单上的条目。这份评估方法学本身也值得完整读一遍，它是少有的把评估怎么做写得足够细的公开文件。

有一类购后界面是可指认的，而它恰好被研究得最多

上一节说购后状态几乎都不可指认，但有一个例外，这个例外反过来能证明整件事。邮件是可指认的。订单确认邮件、发货通知邮件、退款到账邮件，每一封都是一个独立的、可以被存档、被转发、被逐字引用的对象。

然后你会发现，行业里关于购后邮件的研究、模板、最佳实践，数量远超关于购后页面的。订单确认这件事该放页面上还是放邮件里，有大量成熟讨论；而订单详情页在申请取消后的20分钟里该显示什么，几乎查不到系统性的资料。

两者的重要性差不多，甚至页面那一侧更高，因为用户焦虑时第一反应是打开网站而不是翻邮箱。造成研究密度差异的不是重要性，是邮件天然带着一个可以被保存、被搜索、被并排比较的形态，而页面状态没有。

在这类问题上，截图比链接管用

顺着可指认这件事，有个很土但很有效的做法值得推荐：处理购后界面的问题时，全流程用截图加时间戳，别用链接。

原因前面说过了——链接指向的是页面，页面在不同时刻是不同的东西。你发一个订单详情页的链接给同事，他点开看到的是他自己的订单，或者是这一单在此刻的样子，而你想让他看的是三小时前的那一屏。链接在这里是失效的，它传递不了时间这个坐标。

截图能。一张带时间的截图是一个被冻结的状态，它可以被存档、被并排比较、被贴进工单、被拿到会上投影。前面那个园艺站的案例里，整件事被发现的转折点就是一张截图——不是因为截图多高明，是因为它是那个状态唯一能被搬到桌面上的形态。

所以建议把这件事直接写进流程：凡是涉及订单状态、物流、退款进度的用户反馈，客服都要请用户发一张截图。它会稍微拖慢一点响应速度，代价是实的，但换来的是这一类问题第一次变得可讨论。这个取舍值不值，得由团队自己定，但至少要知道它是一个取舍，而不是一个效率问题。

把不可指认变成可指认，其实只要一个小改动

既然形态决定了能不能被研究，那反过来，给状态一个形态就能把它拉进可讨论的范围。最小的做法是给每一个值得关注的界面状态起个内部名字，然后在页面上留一个能识别它的痕迹。

具体点说，可以在订单详情页的地址栏加一个不影响功能的参数，或者在页面里埋一个肉眼看不见但能被脚本读到的状态标识。订单状态机在电商系统里本来就是有名有姓的，只是这些名字通常只活在后台，没被带到前台。

做完这一步，很多事情才第一次变得可能：客服能贴一个准确的状态名而不是一段描述，监控能按状态而不是按网址巡检，团队开会时能说出我们来看看这个状态，而不是各说各的。命名是让一个东西进入讨论的最低门槛，也是最容易被跳过的一步。

无障碍标准里最长的时间单位是20小时，一个跨境包裹要走几天？

先把三种时间尺度摆在一起

前面反复说时间这个维度用钱解决不了，这一节把它量化。要量化就得找一个参照物，而最好的参照物是那些明确写了时间的规范——因为大多数体验规范压根不提时间。

我找到的时间尺度有三种。第一种是研究方法的尺度，一场标准可用性测试大约1小时；第二种是技术标准的尺度，无障碍规范里出现的最大时间单位是20小时；第三种是真实业务的尺度，一个跨境订单从下单到收货是7到15天。

三个数放在一起：1小时、20小时、240到360小时。中间的跨度大到不像是在讨论同一件事，而它们讨论的确实是同一件事——用户从做出一个动作到看见结果，中间要经历什么。

最右一列是我按7到15天的订单周期折算的。用得最多的那个研究方法，覆盖的时间还不到整段体验的百分之一。这不是方法不行，是拿一把30厘米的尺子去量一条马路。

无障碍标准里那个20小时

先说中间那个数的来历。WCAG也就是网页内容无障碍指南，是全球最通用的一套界面标准，欧盟的无障碍法案、各国的政府采购要求基本都以它为准。它的2.2版里有两处提到20小时。

第一处在时间可调整这条准则里，列了几个不需要给用户提供调整机会的例外，其中一条写着：时间限制长于20小时。也就是说，只要一个限制超过20小时，标准就不再管它了。

第二处在一条叫超时的准则里，规范原文大意是：如果用户长时间不操作可能导致数据丢失，必须提前警告用户这个时长，除非数据在用户不做任何操作的情况下能被保留20小时以上。同样是20小时这条线。

20小时是这套标准的时间视野上限

把WCAG全文翻一遍会发现，20小时是它里面出现过的最长的一个时间量。再往上就没有了——没有一条准则的判据是以天为单位的，更没有以周为单位的。

这不是标准写得不好。网页无障碍标准管的是一个人坐在设备前的那段时间里会遇到什么，而一个人坐在设备前的时间本来就不会超过一天。20小时这条线画得很合理，它大约等于一个人的清醒时长加上一点余量。

但这条合理的线，意味着整套标准的时间视野在20小时处截断。一个跨境订单的生命周期是它的12到18倍。从物流开始那一刻起，用户经历的这段体验就已经完全走出了这套标准能覆盖的范围。

更值得注意的是那条超时准则的等级

WCAG的准则分三个等级：A、AA、AAA。行业惯例是做到AA，欧盟的法律要求也基本对齐AA。AAA这一档在实践中几乎没人做，标准自己都说不建议把AAA作为整站的通用目标。

那条要求提前警告用户数据可能丢失的准则，是AAA级。整套标准里唯一一条正面处理长时间等待会怎么样的准则，被放在了几乎没人做的那一档。

这个位置很说明问题。不是标准的编写者觉得它不重要，而是这类要求的验证成本太高——你要验证一个站有没有在20小时后保住用户数据，验证这件事本身就得花20小时。验证成本高的准则会自然往上飘，飘到AAA，然后从大部分人的清单里消失。

一个跨境订单要走多久

回到第三种尺度。跨境电商的常规时效，从付款到签收，7到15天是主流区间，旺季、清关抽查、偏远地址还会更长。配送政策页要不要写清预计送达日期之所以是个反复被讨论的问题，就是因为这个区间又长又不稳定。

在这7到15天里，用户会打开你的订单页几次？根据我接触过的几个站的数据，收货前平均3到6次，物流一旦停更超过48小时，这个数字会翻倍。这是他跟你的站互动最频繁的一段时期，比他下单那天频繁得多。

而这一整段，落在所有研究方法的视野之外、落在无障碍标准的时间上限之外、也落在你自己走查清单之外。用户来得最勤的那几天，恰好是没有任何人看过那些页面的几天。

把观测时长比算出来

用最保守的算法：订单生命周期取7天等于168小时，一场标准可用性测试取1小时。比值是168比1。取15天的话是360比1。

这意味着什么？意味着如果你想用可用性测试这个方法完整覆盖一次购后体验，你得让参与者在实验室里坐168个小时。这显然不可能，所以现实中的做法只有两种：要么只测头尾，要么改用别的方法。

而这两种做法各有代价。只测头尾会漏掉中间那段最长也最容易出事的时期；改用别的方法——比如让参与者在家里断断续续记录——成本会跳一个数量级，下一节会算这笔账。

为什么不能把时间压缩掉

最直接的念头当然是压缩：既然等7天不现实，那就在后台把订单状态调成第5天的样子，让参与者直接看那一屏。快、便宜、可控。

但压缩会删掉东西，而且删掉的恰好是关键的那样。用户在第5天打开订单页时的真实状态不是好奇，是已经等了5天的焦虑；他不是来看信息的，是来找一个理由说服自己再等等。同一屏内容，对一个刚被调到这个状态的测试参与者来说，只是一屏信息。

这里有一条很难绕过去的性质：购后体验里真正被评价的对象不是页面，是页面和用户情绪状态的组合，而情绪状态是时间的函数。把时间拿掉，剩下的那半个对象再怎么测也测不出结论。

三种加速手段各自删掉了什么

实践里常见的加速手段有三种，每一种删掉的东西不一样，值得分清楚。

三种都有各自的用处，第三种就是前面提到的实验室做法，它能可靠地测出用户看不看得懂界面，这已经很有价值。但没有一种能测出用户在真实等待里的反应，因为三种手段删掉的第一样东西都是等待本身。

这解释了一个常见的困惑

不少团队有过这种经历：账户中心和订单页在内部评审时看着挺好，逻辑清楚、信息齐全、设计也整齐，上线之后关于这块的客服工单反而变多了。

用上面的框架看，这件事不奇怪。评审时所有人看的都是被加速过的版本——数据是造的、状态是调的、心情是平静的。而用户看到的是原速版本，数据是真的、状态是等出来的、心情是着急的。两个版本共用一套界面，评价可以完全相反。

要缩小这个落差，唯一的办法是让评审者也进入原速状态，哪怕只进入一次。这件事的成本比想象中低，具体做法放在最后一节讲。

有些等待是带截止日期的

上面把等待当成一段均匀的时间来算，其实不准确。很多品类的等待带着一个硬截止日期，过了那个点，商品的价值直接归零而不是打折。

最典型的是园艺——种子要赶在播种季之前到，晚两周不是晚两周，是晚一年。节日礼物、演出服装、考试用书、婚礼用品全是这个结构。对这些订单来说，物流延迟不是体验问题，是交付失败，而用户往往比你更早知道这一点。

在这类品类里，用户盯订单页的频率和情绪强度都要再翻一档。他不是在问东西到哪儿了，是在算还来不来得及、要不要现在就去别处再买一份。这两个问题需要的信息完全不同，而绝大多数订单页只回答了第一个。

顺便说，这也是为什么同一套账户与订单页设计，搬到不同品类上效果会差很多。跨境退货率高的品类往往有它自己的结构性原因，时效敏感就是其中一个，而它在通用的体验准则里基本没有位置。

你的时钟和用户的时钟不是一个

还有一层错位值得说。团队看待一个订单的时间轴，起点是付款成功，终点是签收，中间的刻度是履约系统里的节点——已支付、已备货、已出库、已交运、清关中、派送中。

用户的时间轴起点不在付款，在他决定要买这个东西的那一刻，可能是三天前刷到的某条内容，也可能是上周孩子说的某句话。他的终点也不是签收，是这个东西真的派上用场的那一天。他的刻度是他为什么要买，不是你的仓库走到哪一步。

这两根时间轴的错位，在顺利的时候不显眼，因为顺利的时候两根轴都在往前走。一旦某个节点卡住，错位立刻放大：你的系统显示一切正常在途中，他的系统显示还有4天就要用了。

订单页上那句到底该写什么，本质上是在选站哪根时间轴。多数站选了自己的那根，因为那根有现成数据。选另一根需要知道用户为什么买，而这个信息你通常没有——除非你去问，或者去翻工单。

后端为了看故障态专门发明了一套方法论，前端对应的那件事叫什么？

同一个难题，隔壁工种是怎么解的

观测不到故障状态，这个问题并不是电商体验独有的。后端工程也面对完全相同的困境：一套分布式系统在正常流量下跑得好好的，可谁也不知道某个依赖挂掉时它会怎么表现，因为那种情况平时不发生。

区别在于，后端这一侧把这件事当成了一个正经问题来解，还给它起了名字、写了原则、造了工具、配了岗位。它叫混沌工程。

把这套东西拿过来跟体验侧对照，会看到一个挺尴尬的落差——不是技术上的落差，是制度上的落差。同样的难题，一边发展出了完整的方法论，另一边连个名字都没有。

混沌工程到底是什么

它有一份公开的原则文件，一页纸，2019年最后一次更新，定义写在开头：混沌工程是在系统上做实验的学科，目的是建立起对该系统在生产环境中承受动荡状况之能力的信心。

注意这个定义里的两个词。一个是实验——不是测试，是实验，意思是主动引入变量然后观察。另一个是生产环境，后面会看到这个词有多要紧。

它给出的实验分四步：先定义稳态，也就是一个能表明系统正常的可测量输出；然后假设这个稳态在对照组和实验组里都会保持；接着引入反映真实世界事件的变量，比如服务器崩掉、硬盘坏掉、网络断掉；最后试图推翻这个假设，办法是找两组之间稳态的差异。

第一条原则就跟体验走查分道扬镳

原则文件的第一条讲怎么建假设，里面有一句话很值得抄：通过关注实验中的系统行为模式，混沌工程验证的是这个系统能不能正常工作，而不是试图确认它是怎么工作的。

把这句话对着体验走查念一遍，落差立刻出来了。体验走查绝大部分时间在确认它是怎么做的——这个链接在不在、这个文案对不对、这个布局合不合规范。它很少验证这套东西在真实条件下管不管用。

这不是走查的错，是走查的形式决定的。走查是看，看只能看出结构；要验证管不管用，得让事情真的发生一次。而让事情真的发生，就回到了本文一直在谈的那个代价问题。

两边居然用了同一对参数

原则的第二条讲怎么选实验变量，写着：按潜在影响或预估频率给事件排优先级。

而那份电商体验基准的评分方法里写着，每一条准则的权重依据它的频率和严重度来定。两份来自完全不同世界的方法学，在给问题排优先级时用了同一对参数：多严重，多常见。

这个巧合不是巧合。任何一个要在有限资源下决定先看哪儿的体系，最后都会收敛到这两个维度，因为它们是唯一能把不同类型的问题放在同一个尺度上比较的东西。

但两边的相同只到这儿为止。用同一对参数排完优先级之后，一边被允许去把排在前面的那些事情真的做一遍，另一边只能看着。下面两条原则就是这个分岔口。

它要求在生产环境里跑

第三条原则的标题就叫在生产环境中运行实验，内容是：系统的行为会随环境和流量模式而不同，由于资源使用的行为随时可能变化，采样真实流量是可靠捕捉请求路径的唯一方式；为了同时保证系统被使用方式的真实性以及与当前已部署系统的相关性，混沌工程强烈倾向于直接在生产流量上做实验。

这段话说的是后端，但换掉几个名词就是本文的论点：合成账号上的账户中心和真实账号上的账户中心，是两个不同的东西；测试订单走的履约链路和真实订单走的履约链路，也是两个不同的东西。

测试订单不会触发风控，不会进真实的仓库队列，不会产生真实的运单号，不会收到承运商的真实推送。异步任务在真实队列里的排队和堆积，在一个空队列的测试环境里根本不会出现。

最关键的是第五条

第五条原则叫最小化爆炸半径，正文是这样的：在生产环境做实验有可能造成不必要的客户痛苦，虽然必须允许一定程度的短期负面影响，但确保实验的后果被最小化和被控制住，是混沌工程师的责任和义务。

中间那半句是整份文件里最有分量的一句。它是一个正式的批准：为了看到系统在故障下的样子，允许对真实用户造成一点伤害。这句话被写进了一份公开原则里，成了这个学科的共识。

而且它没有停在批准上，它同时给了边界——爆炸半径这个概念本身就是边界，控制它是工程师的义务。先批准，再限定，这是一个成熟制度该有的样子。

体验侧从来没拿到过这个批准

现在回头看体验这一侧。有没有哪份文件写过：为了看到用户在异常情况下的体验，允许在真实站点上制造一次可控的异常？

据我所知没有。不但没有，这个想法在多数公司里连提都提不出来——你去跟运营说我们这周故意让三单卡在清关，看看用户在订单页上能得到什么信息，对方的第一反应会是你疯了。同样的动作，在后端叫演练，在前台叫事故。

这个差别不是技术造成的，是归属造成的。后端的故障演练，成本记在技术团队自己的账上，收益也记在自己账上；前台的异常演练，成本记在客服和运营的账上，收益记在体验团队的账上，跨部门的账没人愿意开。

这张表里最刺眼的是第三行和第五行连在一起看：两边用同一对参数排出了同一批要优先看的问题，然后一边被允许去看，另一边不被允许。差的不是认知，是授权。

把爆炸半径这个概念借过来

话虽这么说，这套思路是可以借的，而且借过来之后会发现门槛比想象中低得多。关键是先接受那个前提：要看到异常状态，就得有一次真实的异常，这件事没有免费版本。

然后用爆炸半径去限定它。爆炸半径在这里有三个可以拧的参数：影响到几个用户、持续多久、能不能立刻停下来。把这三个参数都拧到最小，一次异常演练的实际代价就变得很小。

最小的版本是：影响一个用户，就是你自己；持续时间以小时计；随时可以在后台恢复。这个版本几乎没有风险，但它能让你看到一批平时永远看不到的界面，具体怎么做最后一节会列出来。

顺带说说这套原则的另外两条

还有两条原则值得一提。一条是自动化实验并持续运行，理由写得很实在：手工跑实验劳动密集，最终不可持续。另一条是把假设建立在稳态行为上，也就是先定义什么叫正常，再去看什么叫不正常。

第二条对体验侧尤其有启发。你没法判断一个界面在异常时表现得好不好，除非你先知道它在正常时长什么样。而多数团队恰恰没有正常态的基线——没人截过图，没人记过用户在正常情况下几天来看一次。

所以真要动手，第一件事反而不是制造异常，是先把正常的样子记录下来。任何告警体系都得先有基线才能分诊，没有基线的告警只会变成噪音。这份原则文件总共一页，读完不到十分钟，做电商的人也建议看一遍。

有个前提两边不一样，得说清楚

混沌工程之所以能成立，靠的是一个隐含前提：后端的故障是可以被注入的。想看服务挂掉时会怎样，就把服务停掉；想看网络抖动，就人为加延迟。故障是一个可以被制造出来的技术事件，制造它有现成的工具。

体验侧的异常没有这么听话。用户的糟糕体验往往不来自某个技术故障，而来自一串各自正常的事情凑在了一起——包裹在正常清关、页面在正常渲染、状态在正常更新，只是这三件正常的事加起来，让一个正在等种子的人不知道自己还来不来得及。

你没法注入一个不知道自己来不来得及。能被注入的是它的成因，比如让一单真的卡住几天，然后去看界面在这几天里说了什么。成因可以造，感受只能等它长出来。

所以体验侧的实验更像观察而不是注入

这个区别决定了动作的形态。后端可以注入完就看仪表盘，几分钟出结论；体验侧注入之后得等，等的过程中还得有人真的在那个位置上体会。

说白了，体验侧要的不是一个能注入故障的工具，是一个愿意把自己放进那个位置、并且如实记录感受的人。这个人可以是研究参与者，可以是团队成员，也可以是你自己。

这就自然带出下一个问题：如果非要正经地找一批人去经历完整的购后过程，这件事要花多少钱。这笔账有现成的行业基准可以算，而算出来的数字比我预想的难看。

花29倍的钱去看购后体验，为什么很可能什么都看不到？

长跨度的体验只有一种正规研究方法

要研究一段持续好几天的体验，业内公认的方法叫日记研究：招一批人，让他们在一段时间里持续记录自己的行为和感受，研究者定期收集、最后再做一轮访谈。

尼尔森诺曼集团在介绍这个方法时，有一句话把它的必要性说得很干脆：带上下文的、纵向的洞察，无法通过单次会话的主持式用户研究方法收集到，比如可用性测试或用户访谈；这类方法通常把用户从他们的个人情境中抽离出来，而且发生在很短的时间里。

这句话等于从方法学一侧确认了本文的结论：1小时的实验室测试，在原理上就装不下一段几天的体验。不是做得不够好，是这个方法不干这个活。

那日记研究要花多少

好在这套方法的成本也有公开基准。同一份材料里给了一个报酬参考：对美国的一般人群样本，大约按参与者总投入时间每小时40美元来算。并且明确说日记研究的报酬应当高于普通用户测试，因为它要求长期投入。

它还给了一个购物类研究的长度参考：涉及购买决策和购物的研究，参与者大约需要2周来完成一次完整过程，所以研究长度定为2周。

把这两个数拼起来算一个人的成本。2周每天记录一次，每次按10分钟算，是140分钟；加上开始前的说明会半小时、结束后的访谈1小时，总投入约3.8小时。按每小时40美元，一个参与者大约153美元。

再算实验室那一侧

对照组是标准的实验室可用性测试。按前面提到的执行方式，一场约1小时，参与者按任务快慢测好几个站——结账那一轮是每人测5到8个结账流程，移动端那一轮是每人测3到6个站。

同样按每小时40美元算，一个参与者1小时是40美元，覆盖5到8个站，取中间值6.5个。折算下来每个站每人约6美元。

而日记研究那153美元只能覆盖1个站，因为你只能跟着这个人真实购物的那一个站走，没法要求他这两周在6个站上各买一次——真那么要求，他的行为就不自然了，而自然恰恰是这个方法唯一的价值来源。

把比值算出来

153除以6，约等于25倍。这还没算日记研究那边的额外损耗：材料里专门提醒，日记研究的周期长，参与者因为生活里的意外情况中途退出的概率更高，因此要超额招募。

按超额招募25%计，实际单位成本还要再往上抬，综合下来单站单人的观测成本差距在29倍上下。这个数我算得比较保守，把工具费、研究员的时间、数据整理的工作量全都没算进去，全算上差距会更大。

最扎心的一点在后面

29倍还不是最糟的。最糟的是，花掉这29倍之后，你很可能什么都没看到。

因为参与者那一单大概率会顺利送达。物流正常、状态更新正常、按时收货，他在日记里写的是收到了、挺好的。你花了153美元，买到的结论是这次没出问题。

而你真正想知道的是出问题时界面表现如何，那需要参与者那一单恰好赶上延误、恰好需要改地址、恰好想取消。这些事情的发生概率不在你手上，你能做的只有多招几个人然后碰运气。

这就是购后研究真正的成本结构：单位成本高29倍，命中率还只有百分之几十。两个因素相乘之后，任何一家机构算下来都会得出同一个结论——这个主题只能定性地看，没法做成基准。于是就有了那两句数据不足。

顺便说，这也解释了为什么这类研究的结论往往是几段生动的用户原话，而不是一张分布图。当你只有十几条轨迹时，能拿出来的最好东西就是其中最有代表性的那几句话。这些引语的说服力其实很强，只是它们没法回答有多少比例的站存在这个问题，而排期恰恰需要那个比例。

还有一件事比钱更麻烦

假设预算不是问题。你要在335个站上做购后日记研究，钱管够。这时候会撞上一个用钱解决不了的障碍。

前面提到，那家机构做账户与自助服务的远程研究时，招募条件是参与者必须是即将在某个电商站上真实购物的人。这个条件是必须的，因为你不能要求一个人为了做研究去他本来不打算买的地方花钱——那样的话，他的心态、他的期待、他对这笔钱的在乎程度全都不真实了。

但这个条件带来了一个后果：你不再能决定研究哪些站，是参与者的购买意图在替你决定。他打算在哪儿买，你就只能研究哪儿。

样本的选择权发生了转移

这是本文最想说的一层。在购买之前的研究里，样本是研究者选的——想评哪335个站就评哪335个，因为看页面不需要征得任何人同意。

到了购后研究，样本的选择权从研究者手上转移到了被研究者手上。研究者只能在参与者本来就会去的那些站里采样，而普通人本来就会去的站，是他们信得过、买过、听说过的那些站。

结论几乎是必然的：购后体验数据会系统性地偏向大站，而且这个偏向没有任何办法修正，因为修正它的动作会同时破坏数据的真实性。这不是抽样设计没做好，是这个方法的固有性质。

去看那份测试站名单

这个推论可以验证。那份方法学页面把账户与自助服务研究用到的站点逐个列了出来——页面上写的是17个站，实际列出来数了一遍是16个。

名单是：Home Depot、Amazon、Best Buy、Nordstrom、Build、REI、Walmart、B&H Photo、Apple、Appalachian Mountain Company、GAP、All About Dance、Bed Bath & Beyond、Shop Bop、Old Navy、Sahalie。

16个里有11个是北美家喻户晓的大型零售商，剩下5个也都是有相当规模的垂直品牌。没有一个是小站，没有一个是新站，没有一个是那种年销几百万美元、团队十来个人的独立站。这跟上面的推论完全对得上。

这份数据里没有一个站长得像你的站

把这件事说透：如果你在做一个独立站，年销售额几百万美元上下，团队不到20人，那么在购后体验这个主题上，你能找到的公开数据里，没有一个样本的处境跟你相似。

这些数据描述的是Amazon和Walmart的账户中心该怎么改。它们的用户量、客服规模、履约体系、系统复杂度，跟你的站相差好几个数量级。连算个用户生命周期价值都得看清楚样本的分层，何况整套购后流程。

而这件事不会有人提醒你。数据是真的，方法是严谨的，结论也没错，只是它的样本是被参与者的购买意图选出来的，而没有人会为了帮研究者采样，跑去一个陌生的小站下单。你最需要参考的那一块，恰好是外部数据最不可能覆盖你的那一块。

那还能做什么

说到这儿结论好像挺灰暗：数据没有、方法太贵、样本还偏。但反过来看，这里面藏着一个不小的机会。

既然这一块的观测成本对外部研究者高得离谱，那么对站主自己就低得离谱——你不需要招募任何人，你自己就是那个即将在这个站上购物的人；你不需要征得同意，因为那是你自己的站；你不需要跟踪150个站，你只需要跟踪一个。

换句话说，外部研究者付153美元买不到的那条轨迹，你花一件商品的成本就能拿到，而且想拿几条拿几条。这件事在整个行业里是不对称的，而不对称的地方通常就是机会所在。日记研究这套方法的完整流程也值得看一眼，其中不少环节可以直接简化成自用版本。

一次没有人做错事的失手

上面说的都是外部数据看不见你的站。接下来这个例子说的是另一半：你自己公司里，也可能没有任何一个人看得见那块界面。保哥经手过的案子里，这一个是最难向人解释清楚到底哪儿出了错的。

站是做跨境园艺与阳台种植用品的，卖种子、育苗盘、滴灌套件、修枝工具和花盆，主要打北美和西欧，客单价25到180美元。团队十来个人，账户区做得算齐整——菜单里该有的入口都有，仪表盘能通到全部功能，地址簿和支付方式都能改。前面提到的那三条有达标率的建议，他们其实都做对了。

问题出在2到3月，也就是播种季之前那波旺季。那一年海运普遍延误，有一批订单卡在清关，卡了七八天。

用户看到的和客服看到的不是同一页

那段时间工单量涨了不少，问题高度集中：我的种子还赶得上播种吗、还要多久、能不能退。客服的处理其实非常到位——查内部履约系统，那里面清关的每个节点都有，能算出还要5到7天，然后主动给用户两个选项：等，或者直接退款。

用户的反馈也很好。当季的客服满意度不降反升，好几条评价专门夸客服回复快、说得清楚、主动给方案。从任何一张报表上看，这都是一次处理得当的旺季波动。

三个月后复盘时才发现一件事：整个过程里，没有任何一个人打开过用户当时正在看的那一页。客服看的是内部履约系统，那里节点齐全；用户看的是站上的跟踪页，那上面最后一条更新停在9天前，之后是一片空白，没有一句话解释这片空白是什么意思。

两个界面，两套信息，中间没有人

把这件事拆开会发现，每个岗位都离那个页面只差一步，但那一步不在任何人的工作范围里。

客服不看，因为内部系统信息更全、查得更快，为了回答用户的问题他没有任何理由去打开前台页面。开发不看，因为没有人报过bug——那个页面在技术上完全正常，返回200，数据也是对的，它只是把承运商推来的最后一条节点如实显示出来，然后停在那儿。运营不看，因为运营的视角是后台订单列表，那上面显示的是清关中。

老板确实自己下过单测试，但用的是员工账号，走的是内部折扣和优先发货，从来没卡过。四个岗位，四个不同的视角，没有一个是用户的视角。

最后一行和上面四行，看的是同一个订单在同一个时刻的样子。五个界面里只有一个是用户看到的那个，而公司里没有任何一个人的工作流会经过它。

这一型跟以往那些不一样在哪

以前我写过不少类似的复盘，形态各异：有的是预警发出来了但用错了部门的语言，有的是被读成了捷报，有的是被降级成沟通问题，有的是被一份正确的验收报告正式关闭，还有一次是预警本身就是一句表扬。

它们的共同点是信号发出来了，只是在传递过程中被削弱、误读或者归错了类。只要往回追，总能找到一个发出信号的人。

这一次不一样。这一次没有信号，因为没有人站在能看见它的位置上。不是有人喊了没人听，是那个房间里从头到尾就没有人。这也是它最难防的地方——你没法在流程里加一句要重视用户的反馈，因为压根就没有那条反馈。

它是怎么被发现的

发现的方式跟这件事本身一样偶然。第二年招了个新客服，头一周还不熟内部系统，查节点很慢。为了不让用户等，她用了个最笨的办法：让用户把看到的页面截个图发过来。

截图发过来，整个团队第一次看见了那个停在9天前的跟踪页。那一屏上什么都没有：没有一句话说明为什么不更新，没有预计恢复时间，没有联系客服的入口，也没有申请退款的入口。用户唯一能做的就是刷新，而刷新出来还是那一屏。

后面还有一层，更值得记下来。这位新客服的处理方式在内部被评价为效率偏低，因为多了一轮来回，她的平均响应时长明显长过同事，试用期评估的时候这一项差点被扣分。

唯一进入盲区的那个动作，在考核里是负分

这一层是我后来想了很久的。整个公司里，唯一一次有人真正进入了那个观测盲区，靠的是一个被考核体系判定为低效的动作。

这不是谁的疏忽。让用户截图确实更慢，客服考核响应时长也完全正当。问题在于这两件正当的事凑在一起，会稳定地把唯一能看见问题的那个动作淘汰掉——熟练之后她自然就不再这么做了，因为熟练的做法更快。

所以这件事第二年不会自动重演。一个组织越熟练，它进入盲区的概率越低，因为进入盲区的动作永远是笨办法，而组织的进步方向就是消灭笨办法。

后来改了什么，效果怎么算

改动本身很小：跟踪页上如果最后一条节点超过72小时没更新，就显示一段说明——这段时间通常发生在清关或者干线运输途中，节点不更新不代表包裹没在动；同时给出两个入口，一个是查看预计送达区间，一个是申请退款或改期。

效果怎么算是个麻烦事。当季退款率没有明显下降，因为退款入口给得更明显了，本来会打电话来退的人现在自己点了。真正变化明显的是播种季结束之后那批差评：抱怨没赶上的那一类少了一半以上。

但最大的一笔损失没法计算。前一年那批卡过单的用户里，相当一部分再没回来过。而没回来这件事在任何报表上都是一个空格，不是一个数字——你没法给它做归因，也没法在复盘会上把它摆出来，因为它的形态是缺席。

能从这一型里带走的一句话

把这件事收成一句：

一个界面出问题时如果不报错，那么发现它的唯一途径，是有人以用户的身份在用户的那个时刻把它打开一次。而这个动作在大多数公司里既不属于任何岗位，也不产生任何可考核的产出，所以它只会以意外的形式发生。

这句话里最要紧的是最后半句。既然它只会以意外的形式发生，那就不能指望它发生。要让它稳定发生，得有人把它写成某个岗位的固定动作，并且认下它带来的效率损失。

这件事该怎么落到具体的排期和责任人上，是下一节的内容。客服体系的分层和工单路由本身是个成熟话题，但把工单当成观测仪器来用，是另一件事，很少有人这么设计过。

不加埋点、不买工具，这周能先做哪几件？

排期按两个维度相乘

下面六件事全部不需要新埋点、不需要采购任何工具、不需要开发排期，最贵的一件成本是一件商品加一笔退款手续费。但它们的价值差别很大，所以先说排序原则。

保哥这些年给客户排这类清单，一直按两个维度相乘：拿到这个结论要花多少代价，以及这个结论能不能直接变成一个动作。两个都好的先做，都差的最后做或者不做。

按这个原则排下来会有个反直觉的结果：信息量最大的那件事排在中间，而不是最前面。因为它虽然能看到最多东西，但要等好几天，而且结论出来之后还要再讨论一轮才能变成动作。

第一件：用真钱在自己站上下一单，然后什么都不做

用你自己的私人账号、私人邮箱、私人信用卡、家里的收货地址，在自己站上买一件正常价格的商品。不要用员工账号，不要用测试订单，不要走内部通道，不要提前打招呼。

然后什么都不做。接下来的72小时里，每次你想知道点什么的时候——它发货了吗、大概什么时候到、能不能改地址——就打开站上的页面去找答案，找到或者找不到都截图，标上时间。

这件事的关键在于必须真付钱。测试订单不会触发风控，不会进真实的仓库队列，不会产生真实运单号，不会收到承运商的真实推送邮件，也不会经历真实的对账。你省下的那点钱，买走的是这次观测的全部价值。

成本是一件商品，结论通常在第二天就开始出现，而且几乎每一条都能直接变成一个待办。这是六件里性价比最高的一件，没有之一。

第二件：数一数有几个状态是只能等出来的

拿一张纸，把用户在你站上可能停留的状态一行一行列出来：刚下单、等待支付确认、已付款未发货、部分发货、在途、卡在清关、派送中、签收后、申请退货、退货在途、退款处理中。

每一行后面标一个数字：从触发到进入这个状态，大概要多久。几秒的标秒，几小时的标小时，几天的标天。

标完之后画一条线，把超过1小时的那些圈出来。圈出来的这些，就是从来没有人在一次会议、一次评审、一次走查里看过的界面。通常一个跨境站能圈出六到十行，而这十行里通常有三四行是团队里没人能说清楚长什么样的。

这件事花二十分钟，产出是一张清单，清单上每一行都是一个可以派活的对象。它比第一件便宜，但结论要粗一些，所以排第二。

第三件：故意制造一次可控的失败

这一件是从混沌工程借来的，也是六件里唯一需要事先商量的。做法是在自己站上人为制造一次异常，然后去看界面在这几天里说了什么。

可选的异常有几种：把一单的地址填成一个会被系统拦下来的格式、用一张会被拒付的测试卡走到最后一步、对一个已经进入打包环节的订单发起取消、或者干脆请仓库把一单压两天不发。

关键是爆炸半径，三个参数都要拧到最小：只影响一个用户，就是你自己；持续时间以小时或一两天计；随时能在后台恢复。另外提前跟客服说一声，别让他们真去处理。旺季不要做，做了也白做，因为那时候没人有空看。

这件事的信息量在六件里最高，因为它是唯一一个能看到出问题时界面表现的方法。但它要等、要协调、结论出来还得讨论，所以排在中间。

第四件：把工单按用户提问时在哪个界面重切一次

工单系统里通常按问题类型分类：物流、退款、商品、支付。这个分法是给客服排班用的，对体验判断没什么帮助。

换一个维度重切：这个用户发问的时候，他正在看哪一页。不需要改系统，导出最近三个月的工单，人工抽两百条标一遍就够了，一个下午能做完。

标完之后看分布。如果某一页贡献了大量工单，那这一页上缺的信息是什么，基本就写在工单正文里了。这是最便宜的一次界面诊断，因为数据早就在那儿，只是从来没按这个维度切过。

从工单里挖用户的真实说法这件事很多人做过，但基本都是挖词、挖需求。按界面切是另一回事，它挖的是位置，产出的是一张页面级的问题地图。

第五件：算一次自己的覆盖率

拿第二件事产出的那张状态清单，数一数一共多少行；再回想一下最近一次体验走查或者评审，实际打开过其中几行。两个数相除。

我见过的结果通常在两到四成之间。这个数字的价值不在于它有多准，而在于它是一个可以直接带进会议的数——一句我们上次走查覆盖了三成的状态，比任何定性描述都有说服力。

做完之后每个季度重算一次。覆盖率是会变的，每上线一批新功能，分母就变大一点，而分子不会自动跟上。重算一次的成本是五分钟。

第六件：翻一遍你参考的那份榜单的样本名单

找到你团队常引用的那份体验报告，翻到方法学或者附录，看它列的样本站点名单，然后找一个规模跟你差不多的站。

大概率找不到。找不到不代表那份报告没用，它只是说明报告里关于购后流程的结论，对你只能当定性提示，不能当数据用。关于页面结构的结论仍然可以照用，这一点前面说过。

这件事花十分钟，结论不能直接变成动作，但它能防住一类很常见的错误决策：拿一份样本全是巨头的数据，去论证一个十几个人的团队该把资源投在哪儿。

六件事的顺序

这张表里最值得解释的是第4行的位置。制造一次可控失败的信息量在六件里排第一，按理该往前放，但它排在第四，原因是它的结论不能直接变成动作——看到界面在异常时什么都没说，接下来还得决定该说什么、由谁写、什么时候上，这中间隔着一轮讨论。

而排在前三位的那几件，结论落地时几乎不需要讨论。跟踪页上没有预计送达日期，这个结论本身就是那条待办；工单里三成的人在问同一件事，这个分布本身就是排期依据。能省掉一轮讨论的事情，在小团队里的实际价值要比信息量更高。

做之前先确认一个前提

上面六件事有一个共同前提，值得先确认一下：你的站得有真实订单在跑。如果站刚上线、一天几单，那么第三件和第四件的价值会大打折扣，因为异常状态本来就还没有机会出现。

这种情况下建议只做第二件和第五件——列状态清单、算覆盖率。这两件不依赖真实订单量，产出的是一张清单和一个数，可以直接拿来指导后面的开发排期，让那些还没被写出来的页面在写之前就被想到，比上线之后再补便宜得多。

另一个前提是履约方式。如果你是全托管或者平台代发，跟踪页和取消流程有相当一部分不在你手上，那么第一件事的产出会更多地指向该向服务商提什么要求，而不是自己改什么。这时候那份截图记录的用处会变成谈判材料，价值一点不小。

挂一个卡点：工单模板加一个必填字段

前面六件都是一次性动作，做完就完了。要让这件事长期活着，得挂一个卡点，而这次挂的地方是客服工单模板。

具体到一行字：工单系统新增一个必填字段，填写用户提问时所在的页面地址或界面名称。不设选项，不做校验，填什么都行，判定规则只有填了和没填。

为什么判定规则要这么松？因为一条不需要执行者具备专业能力就能执行的规则，才有可能长期活下去。如果要求客服判断这是不是一个体验问题，这个字段三个月内一定会名存实亡。

副产品才是最值钱的：三个月之后，这个字段的分布本身就是一张免费的观测盲区地图，而且它是持续更新的。你不需要再去组织任何一次专项走查，地图自己会长出来。

一个组织上的坑，先说在前面

这套动作最容易被整体派给测试或者质量团队，理由听起来很顺：这不就是测试吗。但这么派下去，基本会失败。

原因在于测试团队的职业本能是用测试环境和测试账号，而这恰好把整件事的前提删掉了。第一件和第三件的全部价值都建立在真实二字上，一旦换成测试订单，做出来的东西看着一样，信息量归零。

可行的分法是按要不要花真钱来分：第一件和第四件交给运营或者店长，他们习惯为结果花钱；剩下四件交给产品或者技术。这个分法的好处是不需要跟任何人解释为什么，因为它跟现有的预算权限是对齐的。

四条边界，主动说清楚

这套做法有明确的适用边界，动手前最好先讲明白，免得后面被质疑时说不清。

第一条，它不产生可比较的分数。它跟行业榜单不是一回事，不能拿去汇报我们排第几，也不能跟去年比。它产出的是问题清单，不是评级。第二条，真实下单的样本量永远是1，它只能回答有没有这个问题，回答不了这个问题多常见——多常见得靠工单分布来补。

第三条，制造失败是有风险的动作，必须限定爆炸半径，旺季不做，涉及真实用户的绝对不做。第四条，覆盖率这个数会随功能上线而变，不是一次性工程，每季度重算一次，成本五分钟。

四条里第一条最要紧，因为它决定了这套东西该拿去跟谁汇报。把没有分数的发现带进管理层汇报，得换一套讲法，硬套KPI的框架反而讲不清楚。

还有一个口径变化，必须提前讲

最后这条经验是踩过坑才有的。做完这套之后的头两个月，关于购后环节的工单量很可能不降反升。

原因有两个。一是你自己和团队会贡献几单真实订单，这些订单产生的问题也会走工单；二是加了那个必填字段之后，原本被归进物流的工单会被拆得更细，看起来像是新增了一类问题。

如果不提前说，管理层看到的就是投入了资源、工单反而变多。这个解释等报表出来再讲就晚了，听起来全是找补。动手之前用一句话讲清楚就行：接下来两个月这个数会先涨后降，涨的部分是本来就存在但没被记下来的。

说到底，这一整套动作解决的不是某个具体的界面问题，而是让一批原本没有人看过的界面，第一次进入被讨论的范围。进入之后，剩下的事情就跟别的产品问题没有区别了，该排期排期，该取舍取舍。真正难的从来是第一步。

常见问题解答

行业报告里的达标率，能直接拿来给自己的站定目标吗？

分两种情况。关于页面结构的那类结论——菜单里有没有某个入口、仪表盘能不能通到某个功能、表单字段怎么排——可以直接拿来对标，因为这类数据的采集成本低、样本足够、口径也清楚。

关于购后流程、异步状态、跨系统跳转的结论，不建议当成目标值。这类结论背后的样本往往只有个位数，而且样本站基本都是大型零售商，它们的履约体系和客服规模跟中小独立站不在一个量级。拿来当提示可以，当KPI会误导排期。

没有研究预算，这块是不是就完全没法测？

恰恰相反，这块是少有的自己做比花钱买更划算的领域。外部研究机构在购后环节的成本高得离谱，是因为他们得招募即将真实购物的参与者、跟随好几天、还要防中途退出。

而站主自己不需要招募任何人——你自己就是那个即将在这个站上购物的人，你不需要征得谁的同意，也不需要覆盖150个站。一件商品的成本就能拿到一条完整轨迹，想拿几条拿几条。真正的门槛不是钱，是有没有人把这件事写进某个人的日程。

用测试订单代替真实订单，具体差在哪儿？

差在四个地方。测试订单通常不过风控，所以看不到风控拦截后用户会收到什么；不进真实的仓库队列，所以看不到积压和延迟；不产生真实运单号，所以承运商那边的推送、异常节点、停更全都不会发生；也不走真实对账，所以退款时长跟真实情况对不上。

换句话说，测试订单能验证页面能不能正常渲染，验证不了这套流程在真实条件下管不管用。这两件事不是程度差别，是两个不同的问题。

故意制造失败，会不会伤到真实用户或者影响收录？

只要爆炸半径控制住就不会。三个参数要同时拧到最小：只影响一个账号也就是你自己的账号、持续时间控制在一两天内、随时能在后台恢复。做之前跟客服打个招呼，免得他们真的去处理。

搜索这一侧基本不受影响，因为这些页面本来就在登录墙后面，不会被抓取也不会进索引。唯一需要避开的是旺季——旺季做没有意义，因为那时候没人有空盯着看，而且真出岔子影响面会被放大。

给工单加一个必填字段，客服会不会抵触？

抵触通常来自两种设计：一是要求填写者做判断，比如让客服判定这是不是体验问题；二是设了校验规则，填错了提交不了。这两样都会让字段在几周内变成敷衍。

所以这个字段要设计得足够笨：不设选项、不做校验、填地址或者界面名称都行，判定规则只有填了和没填。客服不需要理解为什么要填，只需要知道要填。三个月之后这个字段的分布本身就有价值，不需要任何人在填的时候就想清楚它的用途。

购后界面的问题，该归产品还是该归运营？

按输出物的形态分工比按职能分工好用。需要花真钱、需要跟仓库或客服协调的动作——真实下单、制造一次可控失败——交给运营或店长，因为他们的预算权限和协调关系是现成的。

需要整理、统计、出清单的动作——列状态清单、按界面重切工单、算覆盖率——交给产品或技术。特别提醒一句，别把整套动作打包给测试团队，测试团队的职业本能是用测试环境和测试账号，而这恰好把这套方法的前提删掉了。

这套做法多久做一轮比较合适？

真实下单那一件，建议跟着大的功能变更走，账户区或者订单流程改过之后做一次，平时半年一次就够。制造可控失败一年一到两次，避开旺季。

状态清单和覆盖率适合每季度重算，成本很低，主要作用是盯住分母——每上线一批新功能，可能停留的状态就多几个，而走查范围不会自动跟着扩。工单按界面切这件事，如果那个必填字段已经上线，就不用再人工做了，看分布就行。

整体节奏可以粗略记成：一年两次真实下单、一年一次可控失败演练、每季度一次清单与覆盖率复算，工单那一侧则是常年自动积累。这个频率对一个十几人的团队来说不构成负担，而它换来的是这块区域从此不再完全靠猜。

权威参考资料