同一个搜索框，移动网页上79%的站放了提交按钮，你的App里只有10%

摘要：Baymard对30个欧美头部电商App打了一万一千多个UX分，71%落在中等偏差或更差，一个达到良好的都没有。真正值得琢磨的不是这个平均分，是这批App的分数挤得异常紧。同一条准则在移动网页上只有21%的站没做，换到App里变成90%没做；另一条在移动网页上58%没做，App里57%没做，几乎一模一样。差值不随机，它等于容器替你做掉的那些决定。

为什么一个品类里所有人的分数都停在同一格？

30个头部电商App，71%落在中等偏差或更差，一个达到良好的都没有。而比这个平均分更值得读的，是它们挤得有多紧。

一个品类里所有玩家的分数都差不多，通常不说明他们能力差不多，只说明他们受同一个约束。

先把这批数据的口径说清楚

Baymard在2026年更新的这一轮App评测里，手工评分覆盖了30个美国与欧洲的头部电商App、11000多个界面元素、380多条有研究背书的准则，归到39个主题下面，另外攒了9000多个好与坏的实现样本。这个体量足够让下面的结论不是几个人的印象。

结果是这样的：这30个App里，只有29%整体拿到还行，71%落在中等偏差到差，没有一个拿到良好或更高。往细里看，67%的App紧紧挤在中等这一格里，评到差的只有1个。

行业普遍平庸这件事本身不新鲜，任何一个品类拉出来都是这样。但Baymard自己在文末补了一句很关键的对照：在他们做过的其他电商UX研究里，平均分也差不多是中等，可分数的离散程度要大得多。

离散度比平均分更能说明问题

这句对照才是这份数据里最值钱的部分。平均分告诉你行业整体做得怎么样，离散度告诉你这个行业是怎么变成这样的。

离散度大，说明各家在同一件事上做了不同的判断：有人想到了，有人没想到；有人做对了，有人做偏了。这种分布对应的是能力差异与投入差异，也意味着领先者的做法可以被抄。

离散度小到67%挤在同一格，对应的是另一种局面：大家在同一件事上做了同一个判断。而当几十个互不相干的团队做出同一个判断，最可能的解释不是他们商量过，是他们都没有做这个判断，是别人替他们做了。

这个思路在数据分析上不算新鲜。看一份指标只看均值不看形状，会漏掉最多信息的那一层，这件事在砍虚荣指标、定北极星指标那套方法里被反复讲过。App这批数据是一个很干净的例子：均值平淡无奇，形状里藏着结论。

集体平庸，一般不是能力问题

把这个逻辑放到具体场景里就更直白。假如一条准则有40%的站没做，你大概会想：这40%的团队要么不知道，要么排期没排到，要么有别的取舍。这是一个正常的分布。

可如果一条准则有90%的站没做，前面那套解释就撑不住了。90%意味着几乎每一个团队、包括那些有专职设计团队与年度可用性预算的团队，都停在同一个位置上。这时候真正需要问的不是他们为什么不做，而是这件事在他们的流程里有没有以一个待决定的问题的形式出现过。

一个从来没有被提出来的问题，不会有人反对它，也不会有人支持它。它在会议纪要里、在设计评审里、在验收清单里都是缺席的。事后复盘时，你也不会把它记成一次错误的决定，因为它压根不是一次决定。

这类问题的隐蔽程度，和那种在报表上完全不留痕迹的失败很像。用户扫完一屏商品一个都没点开，在你的报表里等于什么都没发生；一个从未被提出的设计问题，在你的项目管理系统里同样等于什么都没发生。

抽样口径先自查一遍

还有一层要先排掉：这30个App会不会本身就是一个有偏的样本？欧美头部电商的App，恰好都是那种流量大、复购高、组织复杂的公司，说不好正是组织复杂才导致执行走形。

这个质疑有道理，但它的方向反了。如果偏差存在，它偏向的是把分数拉高：这批公司比中小站更有钱做研究、更有人手做迭代。样本里最有资源的一批人整体停在中等，说明中小站的实际情况只会更糟，不会更好。

顺手提一句方法上的习惯：拿到任何一份行业分布数据，先看它是怎么抽的。抽样方式能让同一个现象呈现出完全不同的规模，这一点在孤岛页面检测的抽样口径上吃过教训，逻辑是一样的。

十一条清单的分布，本身就是一份线索

Baymard从39个主题里挑了十一条出来讲，每条后面挂着一个没做到的比例。把这十一个数按大小排开：90、80、76、57、53、50、42、40、33、31、21。

跨度接近70个百分点。如果这些问题的难度差不多，比例应该聚在一起；如果难度差别很大，那就该能看出哪些难、哪些容易。可实际情况有点反常——清单上那条比例最高的90%，恰好是技术难度最低的一条：在搜索框旁边放一个按钮。

而比例最低的21%那一条，是让图片上的文字保持可读，这件事牵扯设计资源、素材流程和多语言长度，工程量明显更大。

难度和遵守率对不上，说明遵守率衡量的不是难度。它衡量的是别的东西，而找出那是什么，就是这篇文章要干的事。

再排掉一个解释：不是App太新

还有一个常见的解释是App这个形态还年轻，行业没积累够。这个说法在2015年成立，在今天不成立。

Baymard针对原生App的研究第一轮发在2021年，那时候电商App已经是主流购买入口。而Baymard对移动网页的研究从2013年就开始了，早期文章里讨论的还是三到五英寸的屏幕。 论年头，移动网页确实早了差不多十年。

但年头解释不了那五行差值的方向。首页链接写全范围这条，两边都要靠人判断文案，成绩差一个百分点；保留搜索词这条，原生反过来更好。如果差距来自积累时间，那所有条目都该是App更差，而且越是需要经验的越差。事实是最简单的那条差得最狠。

顺便说，这类给一个现象找解释的时候，有价值的动作往往不是想出一个说得通的解释，而是先把所有说得通的解释列出来，然后逐个去找能否掉它的数。年头不够、样本有偏、App团队更粗糙，这三个解释各自都合理，各自都能被表里的某一行否掉。剩下的那个才值得往下追。

这份数据可以自己去核

本文引用的App侧比例，全部来自Baymard那篇电商App UX的当前状态，它同时给出了那个可交互的散点图，能看到每一个App在九个主题下的分布位置。想看更细的评分口径，另一篇2026年App UX基准列了3300多个表现分与2500多个实践样本的组织方式。

建议真去看一眼那张散点图，因为文字描述传达不出它的视觉冲击。九行点，每行三十个点，绝大多数点堆在中间那一段，右侧良好和完美那两片区域几乎是空白。 一个品类的所有头部玩家在一张图上呈现出这种形状，是相当罕见的。

顺带一句读这类图的习惯：先看空白区在哪儿，再看密集区在哪儿。密集区告诉你行业现状，空白区告诉你天花板在哪儿有没有人碰过。 这张图的右侧空白说明的是，把这些准则做扎实这条路上，目前没有一个对手挡在你前面。

同一条准则，移动网页21%没做，App为什么变成90%？

Baymard在两个平台上各自发过评测，从来没人把两个数并排放。放在一起之后，差值有正有负，跨度从加69到减9。

先把同一批准则的两个数字放在一起

Baymard做研究有个习惯：同一条准则，在移动网页那一侧有独立的评测文章与独立的比例，在App这一侧也有。两边的文章各自发布，从来没有人把它们并排放过。并排放之后，事情就很清楚了。

五行里有正有负，跨度从加69到减9。如果这只是App团队普遍比网页团队糙，那五行应该全是正的，而且量级接近。它不是。

98%这个数字把另一个平台这个说法拿掉了

看到这张表，第一反应通常是：App和网页是两个平台，准则不能这么比。这个反驳听起来很稳，但Baymard自己在做App研究的第一天就把它否掉了。

他们那一轮针对原生App的定性研究，主要发现只有一句话：移动网页的准则里有98%被验证同样适用于App。不是大致适用，是逐条核过之后，只有2%需要改写。

这句话把解释空间压得非常窄。准则是同一套，被测的用户是同一批人，握着的手机是同一块屏幕，手指也是同一根手指。两边唯一真正不同的，是这段界面跑在浏览器里还是跑在一个自己画所有像素的容器里。

差值分层，不是随机的

把五行按差值排开，会看到一条很整齐的分界线。

差值大的两行（加69、加40），共同点是这件事在Web上不需要任何人想起来：它由HTML规范或浏览器默认行为直接提供。做网页的人不是想到了要做，是他压根没有机会不做。

差值接近零的两行（加7、减1），共同点是这件事在两个容器里都要靠人判断：把哪几个入口放到一级、按钮文案写多长，浏览器不会替你决定，操作系统也不会。所以两边的成绩自然接近。

差值为负的那一行（减9），是原生这一侧反过来白送了一样东西。这一行单独摆到后面讲，因为它是这套解释能不能站住的关键。

把它写成一个可以套用的问句

这套观察真正的用处，不在于解释Baymard的数据，在于它能变成一个开工前就能自问的句子。三句，顺序不能乱：

• 这件事在我原来那个容器里，是我做的，还是平台白送的？
• 如果是白送的，那么在新容器里，它有没有变成一件必须有人想起来才会发生的事？
• 这件事如果没人想起来，流程里有没有任何一个环节会把它拦下来——设计评审、验收清单、自动化断言、无障碍检查、搜索表现？

三个问题全是否的那些项，就是你的90%候选。它们不会出现在任何一份需求文档里，因为在你原来那个世界里它们从来不是需求。

这个自查表适用的范围比App宽得多。从桌面搬到移动、从自建站搬到SaaS平台、从服务端渲染换成前端框架、从网页封装成小程序，每一次换容器都会重新分配一批默认值。独立站搜索框那套从入口到结果的四层拆解里列的很多要求，在浏览器里是靠表单结构兜住的，换个容器就得逐条重新落地。

还有一对数字，说明这不是App独有的现象

这套思路要是只在App和移动网页之间成立，那它可能只是这两个平台之间的巧合。所以值得再找一对容器验一下。桌面和移动网页之间，同样有一条现成的例子。

商品图库要用缩略图来表示还有几张附加图片，这件事Baymard的原话是：缩略图在桌面站上无处不在，在移动站上却极其罕见——76%的移动站不用。

桌面上无处不在，移动上76%不做。同一个团队、同一批商品、经常还是同一个后端。区别在哪？桌面上你有横向空间，一排缩略图放上去不占什么成本；移动上那点宽度要在主图和缩略图带之间做取舍，于是一件在桌面上不需要决定的事，在移动上变成了一次必须做的决定，而做决定的人有一半选错了。

这一对数字把结论从两个平台之间的巧合，升级成了一个跨容器的规律。而缩略图这件事本身的后果已经单独写过，那几张没露出来的商品图，桌面用户不知道它存在讲的就是信号缺失之后用户会替你补出什么结论。

三级容器，一份逐级收缩的额度

还有一个可以量化的例子，把三个容器串成一条线。

Baymard对移动电商的整体研究里有个数：移动用户在同一屏里能看到的菜单项，大约是10到15个，比桌面用户少了八成左右。 再往下走一层，到App的底部标签栏，苹果建议默认控制在五个以内。

桌面几十项、移动网页十来项、App五格。同一份商品目录，要塞进一个逐级收缩的额度里，而每一次收缩都会逼出一批新的取舍决定。 目录本身一点没变，甚至还在变大。

这条阶梯解释了一个常见的现象：为什么导航结构这件事在每一次换容器时都要重新吵一遍。不是上一次没吵清楚，是额度变了，上一次吵出来的结论在新额度下不成立了。这跟当年移动优先索引落地时那批桌面掉量的站是同一类困境：结构没错，容器的容量变了。

一个副产物：怎么快速估这次换容器的风险

如果你正在把一套已有的体验搬到新容器里——封装成App、做成小程序、迁到某个SaaS平台——这套思路能变成一个开工前的风险估算，不需要任何工具。

做法是列两张单子。第一张列你现在这套体验里，所有靠容器免费提供的行为：回车提交、页面缩放、前进后退、链接可以长按复制、文字可以选中、表单能被密码管理器填、浏览器自带的翻译、以及无障碍那一整套。第二张列新容器里这些行为的现状：有的、要自己做的、做不了的。

第二张单子里要自己做的那一栏，就是你这次迁移的隐藏工作量。它通常不在项目预算里，因为它不属于任何一个功能。

五行数字的出处，一行一行说清楚

这张表是把六篇独立发布的评测拼起来的，所以每一行的来源值得交代清楚，免得被当成一份来路不明的汇总。

提交按钮那一行，移动网页侧的21%来自搜索框旁必须有提交按钮那一篇，App侧的90%来自本文的源头文章。捏合缩放那一行，移动网页侧的40%来自40%的站不支持商品图的捏合或点击手势。搜索词保留那一行的三个数——桌面33%、移动42%、App33%——前两个来自务必保留用户的搜索词。

剩下两行同理：分类入口那一行的33%来自把商品分类做成移动站主导航的一级项，首页范围那一行的58%来自移动首页链接务必写清完整范围。而那条98%通用的结论，出自原生App的那轮新研究。

把出处摊开还有一个用处：这六篇文章的发布时间跨了五年，评测的站也不完全是同一批。 所以这张表的每一行都可比，但行与行之间的绝对数不宜过度精细地对比——比如不要去论证69这个差值是不是比40这个差值精确地大了29。我用它得出的结论只依赖分层，不依赖精度。

那69个百分点是从哪里来的？

答案写在HTML规范里，而且是一条只对单字段表单生效的兜底。苹果那一侧的原因也写在自己的文档上。

HTML规范里有一条只对单字段生效的兜底

先看Web这一侧。HTML规范专门有一节叫隐式提交，讲的是用户在文本框里按回车会发生什么。规范里的两条规定值得逐字读。

第一条：一个表单的默认按钮，是文档树顺序里第一个提交按钮。用户按回车，浏览器要对着这个按钮触发一次点击事件。

第二条更关键：如果这个表单一个提交按钮都没有，隐式提交机制仍然要走下去——只要表单里阻止隐式提交的字段不超过一个，就直接提交这个表单。规范里还专门写了一句罕见的话：网上有一批页面只有靠隐式提交才能用，所以强烈建议浏览器都支持它。

规范列出的阻止隐式提交的字段类型，包括文本、搜索、电话、网址、邮箱、密码、日期、数字等等。而一个站内搜索表单里放了几个这样的字段？正好一个。

所以在Web上，那个搜索提交按钮其实有两层保险：一层是你自己写的按钮，另一层是规范替你兜的底。哪怕你什么都不写，回车也能把搜索提交上去。21%这个数字不是79%的网页团队特别用心，而是在Web上你需要主动做错才能让搜索提交不了。

字段从一个变成两个的那一刻

这条规范里还藏着一个反向的坑，正好是Web这一侧的人该知道的。

兜底的前提是阻止隐式提交的字段不超过一个。假设你的搜索表单原本只有一个输入框，回车工作正常。某天产品要求加一个在此分类内搜索的下拉、或者一个门店与邮编选择器，如果新加的是一个文本类输入，字段数变成两个，隐式提交那条兜底当场失效。

这次变更里没有任何一行代码涉及回车键，代码评审时也不会有人提到它，自动化测试如果只测点击按钮更是照样全绿。回车键是在一次跟它毫不相干的改动里安静停掉的，而它停掉的原因写在规范里。

可执行的检查只有一句：任何一次给搜索表单加字段的改动，加完之后手动按一次回车。这跟表单校验那件事的逻辑很像——后端明明知道用户错在哪里，页面上却只剩输入有误，问题都不在技术难度上，在于没有人负责把那条路径走一遍。

用户要找的那个按钮位置上，系统放的是清除

再看App这一侧，90%的根因写在苹果自己的文档里，而且写得很直白。

人机界面指南对搜索框的定义是：一个可编辑的文本框，显示一个搜索图标、一个清除按钮，以及占位文字。就这三样。这个定义里没有提交按钮，因为在原生的设计语言里，搜索的提交动作被安排给了软键盘上的那个键。

然后看Baymard在测试里录到的画面：用户在搜索框这一块UI里找一个能确认搜索的东西，结果本能地点了那个取消图标，把自己刚打完的词清空了。

这不是用户手滑。用户的心智模型是输入框旁边那个位置属于确认，而平台的默认组件在那个位置上放了一个语义完全相反的按钮。一个把提交按钮省掉、又在提交按钮该出现的地方放了清除按钮的默认组件，等于同时创造了缺失和误导两个问题。

差别的根源在结构上：Web里的搜索框住在一个表单里，而表单这个概念本身就带着提交的语义，你写下开标签的那一刻就已经在想提交去哪儿。原生的搜索框是一个孤零零的控件，它不住在任何容器里，提交这件事在结构上不存在，就只能靠人想起来。结构里有的东西不需要被想起，结构里没有的东西必须被想起。

把苹果自己给的另一条路一起算进去

这里要诚实处理一个反驳。苹果的指南里还有一条：如果可能，用户一边打字就一边开始搜索。做到即输即搜，提交按钮理论上就不必要了。那90%里会不会有一批是故意的？

有，但解释不掉这个数。Baymard的测试观察是：缺少显式提交按钮会实际拖慢搜索流程，并且提高误操作的概率。即输即搜没有消掉用户想找一个确认动作的冲动，只是让他在找的过程中看到一个不停抖动的结果列表。弱网环境下这个体验更差，前几个字符打出来的结果和最终结果往往差得很远，低端机加弱网的实际表现会把这个抖动放大到用户开始怀疑自己是不是打错了。

还有一条更省事的补救，苹果和Baymard都提到了：软键盘那个默认灰色的换行键可以改掉，让它显示搜索并做成醒目的蓝色。这一行代码的成本，和放一个按钮差不多。

搜索框藏起来，是另一层叠加的成本

提交按钮不是搜索这一块唯一被容器影响的东西。Baymard在移动网页那一轮里还测到：35%的移动电商站默认把搜索框收起来，用户得先点一个放大镜图标才能展开。

收起来这个决定本身有理由，首屏太挤。但它和缺少提交按钮叠在一起就麻烦了：用户先点图标展开、再打字、再找一个确认的地方，三个动作里有两个都靠他自己猜。Baymard的判断是，隐藏的搜索框加上必须使用软键盘这两件事凑在一起，会额外制造痛点。

这里还有一个容器差异容易被忽略：软键盘弹出来会吃掉视口。Baymard测到结账时键盘打开，用户能看到的表单区域缩小了大约四成。Web这一侧现在能用视口meta里的interactive-widget声明键盘对视口的处理方式，是收缩可视区、收缩内容区还是直接盖上去；原生这一侧要自己监听键盘出现的事件、自己算偏移量、自己滚动到焦点。又是同一个模式：一边是一个声明，一边是一段要有人写的逻辑。

联想词那一条，容器背了不该背的锅

清单上还有一条跟搜索有关：42%的App存在重复或不相关的联想词。这条要说清楚，因为它跟前面几条不一样——它不是容器造成的。

Baymard给的重复的定义很具体：露营帐篷和露营帐篷们、儿童鞋和小孩鞋，实质是同一个东西，却当成两条建议各占一行。不相关指的是用户打女士钱包，列表顶上给的是女士手袋和女士鞋。

这两种毛病的根子在搜索后端与词表治理，跟界面在哪个容器里跑没有关系。把它放进这份清单是对的，但它的解法不在客户端。Baymard给的两条建议也都指向数据侧：用搜索日志给建议排序，而不是用日志来生成建议；把语义等价的查询映射到一起，只让一条出现在列表里。

这里正好说明一件事：一份问题清单上的条目，成因可以完全不同，而混在一起会让整份清单被交给错误的团队。 提交按钮和捏合缩放是客户端的活，联想词是搜索团队的活，图上烤字是设计与素材流程的活。三拨人，一份清单，通常会被整包扔给客户端，然后卡住。

搜索日志这份资产本身值得单独盘一遍，它既能诊断可用性，也能反过来喂选词，被低估的第一方选词金矿讲的就是后一种用法。

迭代查询这个动作，成本在移动端被放大

还有一层值得补上，因为它解释了为什么搜索词保留这件事在移动端格外重要。

Baymard的观察是，用户在结果不满意的时候会频繁改词，而这个改词动作在手机上的成本远高于桌面：点击目标小、要连按退格删掉一串字符、想改中间某个词还得把光标精确地放到那个位置上。 每一个都是精细操作，而手指不擅长精细操作。

所以搜索词被清空这件事的代价，不是让用户多打几个字，是把一次本来只需要改两个字的迭代，变成了一次从零开始的完整输入。而需要迭代恰恰意味着他上一次没搜到，这个时候他的耐心是全程最低的。

苹果那份定义可以自己去核一遍

搜索框的标准组成写在人机界面指南的搜索字段一节里，原文的定义是一个可编辑文本框，显示一个搜索图标、一个清除按钮和占位文字，另外可以配范围栏与标记来收窄搜索范围。整节从头到尾没有提交按钮这一项。

同一节里还有几条值得顺手抄进需求的建议：用占位文字告诉用户能搜什么，这一条在SKU复杂的品类里价值很高，比如汽配站可以直接写按零件号或车型搜索，省掉用户一次试错；考虑展示建议搜索词，包括最近搜过的。

还有一个平台差异藏在这一节的末尾：在手表那个平台上，用户点搜索框会弹出一个占满整屏的输入控件，只有点了取消或搜索才回到搜索框。同一个控件在四个平台上的行为完全不同，而这些差异不写在你的需求文档里，写在人机界面指南里。

为什么这一条值得排在整份清单最前面

整份清单十一条，我认为搜索提交按钮应该排第一，理由不是它的90%最高，是它的失败方式最贵。

用户到了搜索框这一步，说明他已经很明确地知道自己要买什么了。这是整个漏斗上意图最强的一个位置——比逛分类的人强，比看推荐位的人强得多。 在这个位置上让他打完字之后不知道该按哪里、甚至误删了自己刚打的词，损失的是漏斗上最贵的那批流量。

而修复成本是一个按钮。这种成本与收益的悬殊在实际项目里很少见，多数优化项要么便宜但收益薄，要么收益大但工程量沉。搜索框这个入口的转化价值单独算过一遍，结论是它的单位面积产出在整个站里排前几名，而它得到的设计关注度远配不上这个排名。

顺带提一句，站内搜索这条路径的另一端同样值得盘：用户搜出结果之后，那个列表页的信息密度够不够他做判断。这两件事经常被拆给两个人做，而列表项上少一个关键属性的后果是他扫完一屏一个都不点，在报表上跟没搜到没有区别。

一个在Web上连关掉都关不掉的能力，到了App里为什么要重做一遍？

捏合缩放在浏览器里走完了默认给你、你可以关掉、你关不掉三个阶段。用户的预期跟着涨到了百分之百。

从你可以关掉，升级到你关不掉

缩放这件事在Web上的历史很有意思。视口那个meta标签里有个参数叫user-scalable，控制用户能不能缩放页面，它的默认值是允许。也就是说你什么都不写，页面就能捏合放大。

后来有一批站为了让自家界面看起来更像原生App，主动把它关掉。于是平台出手了：从iOS 10开始，系统默认忽略user-scalable、最大缩放和最小缩放这三个参数。你写了不许缩放，系统当没看见。

CSS这一侧是同一个方向。touch-action这个属性的默认值是auto，含义是启用浏览器对所有平移与缩放手势的处理；想关掉平移和缩放，得自己写none，而MDN在旁边挂了无障碍警告。

所以在Web上，捏合缩放走完了一条完整的路：先是默认给你，接着是你可以关掉，最后是你关不掉。用户这十几年里养成的预期，是这个能力百分之百存在。

同一个能力，在App里得从零做起

App这一侧完全是另一个起点。原生环境里没有一个东西叫页面缩放，图片能不能放大取决于有没有人写了一个可缩放的容器、设了缩放上下限、处理了双击、并且在放大时去取一张更高分辨率的图。每一步都要一个人想起来。

结果就是那两个数：移动网页40%不支持商品图的捏合或点击缩放，App里80%不支持。

而Baymard在移动网页那一轮里还测出一个更细的层次：支持缩放的那60%里，只有一半会告诉用户支持。也就是说整个行业里，既能缩放又让用户知道能缩放的，大约只占三成。

一个手势要成为约定，靠的不是好用而是普及率

Baymard对40%这个数字的评语值得单拎出来：当四成的站不支持缩放手势，用户就根本无法预判你这个站支不支持。

这句话点出了交互约定的形成机制。一个手势能不能变成用户的默认动作，不取决于它多好用，取决于它在这个环境里的普及率有没有过线。浏览器给的缩放是百分之百普及，所以在Web上它是铁约定，用户闭着眼睛都会去捏一下。App里普及率两成，意味着捏合缩放在App这个环境里压根还不是约定。

可用户的预期是跟着人走的，不是跟着容器走的。他在浏览器里养成的百分之百的预期，会原封不动地带进你的App。这就解释了源头研究里那句观察：用户经常会忽略点击放大这个功能，并且认定这个App压根没有放大能力——他试了他熟悉的那个手势，没反应，于是得出结论。

用户预期会跨容器迁移，而你的实现不会。这是本文最想留下的一句判断。

和手势被误读那件事，区别在哪

手势这个话题之前专门写过一篇：同一根手指要负责翻页、握住手机和下单，而你的界面只认得最后那一种。那篇讲的是意图过载——手势做出来了，系统收到了，但把它归到了错误的语义上。

这里讲的是完全不同的一层：手势能不能被处理，在两个容器里的默认归属不一样。一个是识别环节出错，一个是这个能力在这个容器里默认压根不存在。前者需要你重新设计动作词汇表，后者只需要有人在需求文档里写下这一行。

两篇合起来看，正好构成一个手势问题的分诊顺序：先确认这个手势在你的容器里默认存不存在，再去查它被识别成了什么。顺序搞反的话，你会花两周时间调一个压根没有被启用的手势的语义。

还有一条捎带的收益

把商品图的缩放做扎实，顺手会解决一个跟它长得不像的问题。用户放大图片最常见的动机不是欣赏，是去读图上那几行字——成分、尺寸标注、包装规格。这件事和图片本身的分辨率强绑定，也和图片资产的治理强绑定，一页图片的属性怎么批量体检那套办法里的清单可以直接搬过来用，只是检查项要多加一条：这张图在放大到最大倍数时，上面的字还认得出来吗。

四个实现细节，其中一个最容易被跳过

Baymard给捏合缩放配了四条实现细节，值得逐条对一下自己的App。

第一，全App范围支持，不要只在商品页支持。列表页那张主图经常是用户唯一认真看的图——有相当一部分人压根不点进商品页，只在列表上比较，这一点在商品列表上那些静默拒绝那篇里算过账。

第二，捏合和双击都要支持。有人习惯捏，有人习惯连点两下，这两拨人不重叠。

第三，把可以放大这件事在视觉上标出来。前面提过，支持缩放的站里只有一半会告知用户，而不告知等于把功能藏起来。

第四条最容易被跳过：用户开始放大的时候，去取一张分辨率更高的图。 如果你放大的还是那张列表用的小图，用户看到的是一堆马赛克，体验比不能放大更糟——因为不能放大他只是失望，放大之后一片模糊他会觉得这个商品的图就是这个质量。图片资产这一侧的取舍和实际收益，图片压缩那笔账里有比较细的实测。

触摸行为那个属性，反过来也能咬到你

既然说到Web上缩放是白送的，那也得说清楚这份白送有它自己的坑，不然这段就成了单边吹。

触摸行为属性能取的值不止开和关。除了默认的auto和全关的none，还有只允许横向平移、只允许纵向平移、单独允许捏合缩放，以及一个叫manipulation的值，含义是允许平移和缩放但不做双击缩放那一套延迟判断。

这些值在做自定义手势区域时很有用，比如一个可以左右拖的对比滑块。但它们也是Web上最容易误伤的一处：为了让某个组件的拖拽手感好一点，在一个偏上层的元素上写了none，结果整片区域的页面滚动和缩放一起没了。MDN专门提示，一旦手势已经开始，再改这个属性对当前这次手势没有影响。

所以Web这一侧的规则应该这么说：缩放是默认给你的，但它可以被一行样式在一个你想不到的层级上关掉，而这一行通常是为了别的目的写下的。 这跟App那边完全没有比找不到，但排查手段不一样——Web上你查的是哪一行样式关了它，App上你查的是有没有人写过它。

顺手把无障碍这条线接上

缩放还有一层跟生意关系不那么直接、但迟早要面对的意义。

MDN在讲禁用缩放时挂的警告写得很明确：关掉缩放会让低视力人群无法阅读和理解页面内容，而WCAG要求至少支持两倍缩放，实践中的建议是支持到五倍。这也是iOS后来干脆无视那个禁用参数的原因——它不是在跟开发者抢方向盘，它是在替一批用户兜底。

放到App里，商品图能不能放大这件事就不只是看清绣线的问题。包装上的成分表、尺寸标注、适配车型的那一行小字，对一部分用户来说，能不能放大等于能不能买。 这些信息通常没有以文本形式出现在页面上，只印在图里，所以图是唯一的通道。

把这件事和无障碍绑在一起说，在排期会上还有一个实际好处：它能把一个体验优化重新表述成一个覆盖面问题，而后者更容易拿到位置。

把三份规范原文摆在一起看

这一节的判断全部来自可以直接翻的文档，值得把它们并排列一遍，因为并排之后才看得出方向的一致性。

视口meta标签那份参考写的是：控制用户能否缩放的那个参数取值为允许或禁止，默认为允许；并且紧接着注明浏览器设置可以忽略这条规则，iOS 10及以后版本默认就忽略它。触摸行为属性那一页写的是：默认值auto的含义是启用浏览器对所有平移与缩放手势的处理。

而HTML规范讲隐式提交那一节更直接，它甚至用了强烈建议这种在规范里很少见的语气，理由是网上有一批页面只有靠隐式提交才能用。

三份文档，三个方向一致的表态：平台在这几件事上不但提供默认值，还主动限制作者推翻它的能力。 这不是巧合，是Web这个环境的一种设计取向——它假定作者会犯错，于是把几项对用户最要紧的能力做成了不易被关掉的。

原生环境的取向正好相反，它假定开发者知道自己在做什么，所以什么都不预设。两种取向各有道理，麻烦只出在同一批人要同时在两个取向下工作，而没有人在交接时把这件事说明白。

有没有反过来的例子？

有一条，App比移动网页好出9个百分点。这一条比前面所有条都重要，因为它决定这套解释是不是只是换个词骂人。

如果差值只有正的，这套解释就不成立

到这里得停下来自查一次。前面两条差值都是App更差，如果整张表都是这个方向，那这套容器默认值的说法就没有比App团队更粗糙这句话多提供任何信息，属于换个词重讲一遍。

真正能验证它的，是找到方向反过来的那条。找到了，而且原因干净得出乎意料。

状态在原生里是免费的，在网页里是要还的

保留搜索词这条准则，Baymard给的数字分得很细：桌面站33%会在提交后清空搜索词，移动网页是42%，而App是33%。

App跟桌面同一个水平，比移动网页好出9个百分点。为什么？

因为在原生环境里，用户输入的那串字天然就待在控件的属性里。你把搜索词读出来发个请求，界面切到结果页，那个字符串还在原来的对象上，什么都不做它也不会消失。要让它消失，反倒得有人主动写一行清空。

Web上正好相反。经典的搜索结果页是一次全新的文档加载，上一页的输入框连着整个DOM一起没了。要让搜索词出现在新页面的输入框里，你必须主动把它从查询参数里取出来、回填进value属性。这是一次要还的债，不是一份白送的礼。

移动网页比桌面更差那9个百分点，也说得通：移动模板往往是另一套代码，搜索框还经常是收起来的、点图标才展开，回填这一步比桌面更容易在模板分叉里漏掉。

纯文案的那一条，两边几乎一模一样

另外两行是对照组，用来证明差值不是凭空来的。

首页链接要写清完整范围这条，移动网页58%没做，App57%没做，差一个百分点。这件事纯粹是文案判断：按钮上写立即购买还是写选购全部厨房用品，浏览器不管，操作系统也不管，两边的人面对的是同一个空白的文本字段。所以两边的成绩一样。

把分类入口放到导航一级这条，移动网页33%没做，App40%没做，差7个百分点。也很接近，但App略差，那7个百分点后面还有一层容器约束，下一节专门讲。

这两行的价值在于它们是阴性对照。如果连纯文案的那一条都是App差出几十个百分点，那说明差值来自别的东西，比如组织结构或人员水平，我这套解释就该扔掉。它们没差，所以差值确实来自那些被容器接管过的地方。

一个能让人放心的时间序列

Baymard在保留搜索词那篇里还给了一条纵向数据：桌面站里会保留搜索词的比例，2014年是34%，2017年涨到43%，现在是三分之二左右。

十二年翻了一倍，说明这类需要人主动做的事情是会被行业慢慢学会的，只是速度以年为单位。这个速度对做决策的人有两重意思：一是这类问题不会自己消失，你不做它就一直在；二是你今天做了，领先窗口能维持相当长一段时间。

这也提供了一个判断优先级的角度：凡是需要人主动想起来才会发生的事，普及率的爬升速度都很慢，因此它的差异化保质期很长。反过来，凡是靠平台默认值提供的能力，普及率一夜之间就能到顶，你在上面做不出任何区隔。前面那份两套报表算出相反结论的案例里也有类似的味道：真正的杠杆往往在没人盯着的那一格。

白送的东西也会反过来变成负担

状态天然驻留这件事对搜索词是好事，但同一个机制在别的地方会变成麻烦，这一点值得说明白，否则容易得出原生什么都好的错误结论。

Web上每次导航都是一次新文档，等于每次都有一份干净的初始状态。原生里状态默认不清，于是要清的地方就得有人主动清。 用户退出登录之后，上一个账号的收藏列表还留在某个控制器的属性里；从A车型的配件列表切到B车型，筛选条件跟着带过去了；用户改了配送地址，购物车里那份运费还是上一次算的。

这些都是原生环境里的经典故障，而它们的根因跟搜索词保留是同一个：状态是黏的。 黏在你想要的地方叫体验好，黏在你没想到的地方叫脏数据。

Web那一侧当然也有对应的坑，一旦引入了单页应用那套路由，同样的黏性就跟着来了，只是范围小一些。至于跨域和跨子域那些状态清理的边界，本身就是一个容易翻车的地方，一张自家子域上的图片把主站登录态删干净那件事就是这条线上的极端例子。

把这个规律写成一张判断表

五行数据背后的规律，可以整理成一张开工前用的表。左边是这件事的默认值归谁，右边是你该怎么对待它。

这张表最大的用处不是指导实现，是指导你把清单交给谁。第一行和第三行归客户端，第四行归设计与文案规范，第五行归状态管理与测试用例。混在一起交出去，通常会卡在第一个人手上。

十二年翻一倍这件事的另一面

桌面站保留搜索词的比例从34%涨到三分之二，用了十二年。这条爬坡曲线除了说明差异化保质期长，还有一层提醒。

它意味着这类改动的竞争压力几乎为零。没有一个对手会因为你今年做了保留搜索词而觉得被威胁，也不会有任何一家把它写进季度目标。所以它永远排不到最前面，一年一年往后推。

反过来看，这也是它的机会所在。凡是能被平台一夜普及的能力，你在上面拿不到任何优势；凡是要靠人一个个想起来的事，谁做了谁就多拿几年。 判断一个待办值不值得做的时候，问一句这件事会不会有一天被平台白送给所有人，答案是不会的那些，才是真正能攒下来的东西。

同一套判断在别的场景里长什么样

这张表最好的检验方式，是拿几个跟App无关的场景套一遍，看它还成不成立。

第一个例子是筛选条件。用户在集合页上连点几个筛选之后，还记不记得自己选过什么，取决于有没有一个已应用筛选的概览区。这件事在两个容器里都要靠人做，浏览器不会替你汇总，操作系统也不会。 所以按这张表的第四行，它的遵守率在两边应该差不多——而连点五个筛选之后用户已经忘了自己选过什么那篇里的数据确实是这样。

第二个例子是商品页把内容收进横向标签。这也是纯设计决定，两个容器都没有默认值可依，那排标签把页面收拾干净的代价那篇讨论的相邻性问题在App里一字不改地成立，因为造成它的不是容器，是把两块要对照看的信息分开放这个决定本身。

第三个例子往反方向走：离线能力。Web上离线是要你自己搭一套的，装个服务工作线程、管好缓存策略，离线缓存那套策略不轻；原生这一侧网络断了界面还在、本地数据还在，属于表里第五行那种原生天然具备的能力。所以从App往网页反向迁移的项目，最容易漏的就是这一类。

三个例子分别落在表的第四行、第四行和第五行，预测的方向都对上了。这不算严格验证，但至少说明这张表不是只为解释那五行数据而硬凑出来的。

系统替你折叠的那个标签，为什么它自己的文档也说这样不好？

苹果一边在运行时按设备尺寸自动折叠，一边在指南里承认折叠有害，然后把避免它发生的责任交回给你。

五格的预算，装一个目录

底部那一排标签是App的主干道，它的格子数很有限。苹果的指南建议，如果允许用户自定义标签，默认清单控制在五个以内，这样在紧凑与常规两种视图尺寸之间才保持得住连续性。

五格要装什么？首页、购物车、账户几乎是雷打不动的三个，还想放会员、订单、扫码、客服、消息。而浏览分类这件事，要跟上面所有这些抢一个位置。

Web那一侧没有这个预算表。移动网页的主导航是你自己写的一份列表，想放八个放八个，一级项多了顶多是这一屏滚一下。标签栏的五格不是设计取舍，它是容器给的一个硬额度，而这个额度是按导航习惯定的，不是按目录规模定的。

于是那7个百分点的差值有了来处。移动网页上33%的站没把分类放到一级，是判断失误；App里40%没放到一级，是判断失误加上一个额度冲突。

折叠点不是一个常数

更麻烦的一层在这里。苹果的指南里有一条明确的告示：可见的标签数量可能少于你设的标签总数，取决于设备尺寸与方向；如果横向空间不够，最后一个标签会变成一个更多，把剩下的项收进一个单独的列表里。

请注意这句话真正说了什么。折叠这件事不是你的代码做的，是系统在运行时按当前设备与当前方向算出来的。同一份代码，在大屏手机上五个标签都在，在小屏手机横过来的时候可能只剩三个，剩下两个躲进更多里。

而你的验收在几台设备上做的？多数团队是一台主力机型、竖屏。这个折叠在验收环境里从来不会出现。这跟商品页那些被截掉的内容属于同一类问题，只是触发条件更隐蔽——那4张没露出来的商品图至少是你自己的代码截的，你查得到那行代码在哪；标签栏的折叠点在系统里，你的代码库里找不到它。

平台自己触发的问题，责任被交回给你

最值得琢磨的是苹果紧接着写的那半句：更多这个标签会让人更难触达和注意到被隐藏的内容，所以请限制你的App里发生这种情况的场景。

平台一边自动执行这个折叠，一边在文档里承认折叠有害，然后把避免它发生的责任交回给开发者。这不是苹果不讲道理，这是所有平台默认值的常态：它替你做决定的时候不需要你签字，出问题的时候责任还在你这边。

Baymard那一侧的观测正好对上了。测试里，60%的用户在Amazon的App里找不到开始浏览分类的入口，而那个入口就在底部导航的汉堡图标后面。有位测试用户的原话是：Amazon的分类到处乱放，所以对我来说直接在搜索框里打出我要的东西反而更容易，说实话他们从来没在顶上放个方便你找的东西。

这句抱怨最扎心的地方在于它的后果不是抱怨。约三分之一的用户在不确定自己要什么、或者想找灵感的时候更愿意浏览分类；找不到分类入口，他们会退回去用搜索，而搜索会把范围收得比他们想要的窄很多。一个来找灵感的人被逼着输入一个具体的词，结果自然是他没找到灵感就走了。

横向滚动区那一条，是同一个约束的另一面

标签栏的额度是横向空间不够，横向滚动区的问题是纵向空间不够。App里53%的站有过高的横向滚动组件，超过视口一半高度的那些最容易出事：用户想往下滑页面，手指恰好落在这个组件里，页面没动，横着的内容动了，有时候还会误开一个商品页。

Web那一侧有一个大致可比的数字：26%的头部电商站在筛选选项里用了内联滚动区。口径不完全一样——一个统计的是筛选面板，一个统计的是首页与列表页的组件高度，所以这两个数不进前面那张表。但方向是一致的，而且原因也一致：在浏览器里，嵌套滚动的手势仲裁是浏览器做的，你只在极少数情况下需要碰touch-action；在原生里，两层滚动视图打起来要你自己裁。

顺带一句，这类误触在Web上还有第三种成因，就是布局在加载过程中跳了一下，页面跳动与误触背后的机制那篇讲的就是这一层。App里没有CLS这个指标，但同样的误触照样在发生，只是没有一个现成的数字替你把它报出来。

中间分类页那50%，是同一个额度冲突的下游

标签栏挤不下分类入口，往下走一层，中间分类页上又发生了一次同样的挤压。清单上这一条是：50%的App没把子分类当成中间分类页的主要内容。

Baymard举的例子很典型。Nike的App里男士这一页，最显眼的是一组主推链接，把下面的鞋类这些子分类完全盖住了；Home Depot的冰箱页整页被促销内容占满。做对的是Target的玩具页，用户落地就能看清有哪些子分类，不用滚到底。有位测试用户的原话是：现在又有一个逛遍全部分类，这是我最喜欢的。

这一条和标签栏那一条是同一个额度冲突在不同层级上的表现。首屏空间有限，促销要位置，子分类要位置，而促销位有明确的收入归属和排期负责人，子分类导航没有。两个候选人抢一个位置，其中一个有人替它说话，结果是可以预料的。

顺带说，中间分类页这个东西本身在Web上的普及率是87%，只有13%的站没有。注意这两个数问的不是同一件事：Web侧问的是有没有这一层页面，App侧问的是这一层页面上什么排在最前面。所以它们不能相减，我把它排除在前面那张表之外，就是这个原因。

首页广告那76%，跟额度无关，跟激励有关

清单上比例第三高的是首页广告过分抢眼，76%。这一条的成因跟前面几条都不一样，值得单独点出来。

它不是容器少给了什么，也不是没人想到。它是想到了、讨论过、然后按另一个目标做出了决定。App首页是自有流量，获客成本为零，展示价值在整个站里最高，所以它是各个业务线抢得最凶的一块地。

Baymard录到的用户反应是这样的：我对这个首页的第一反应是有点让人喘不上气，好多不同的东西在同时发生。这是一位第一次用Home Depot的App的测试用户。而Burger King的App首页是整整一屏广告。

测试里观察到的三个后果分别是：用户没法对商品范围形成概览、被杂乱的首页压住、以及跟广告发生非本意的交互——最后这条就是误触。做对的例子是Just Eat，首页没有广告位，用户可以直接扫到商品范围。

这一条的解法不在设计评审里，在谁对首页的产出负责这个问题上。首页首屏的位置该怎么分配，从导航、主Banner到分类区的取舍那篇按转化路径算过一遍，结论跟这里一致：让用户先看清你卖什么，比让他先看到一个折扣更划算。

横滚区有一个正当的例外

回到横向滚动那一条，得把例外说清楚，否则容易被读成横滚组件一律砍掉。

Baymard给的界线是按内容重要性划的：促销广告、交叉销售这类次要内容，横滚组件应该控制在可用高度的一半以下；而商品页上那种信息量很大的图库，占更多高度是完全合理的。 判断依据是这块内容在用户当前这个任务里是不是关键决策信息。

这个界线好用的地方在于它把一个尺寸问题翻译成了一个优先级问题。不是多高算高，而是这块内容值不值得占用用户的滚动通道。图库值得，因为用户就是来看图的；一条推荐位不值得，因为他压根没打算看。

而交叉销售这块内容本身要不要放、放什么，是另一个话题。清单上第三条讲的就是这个：31%的App的交叉销售区里没有替代品，只有配件和搭配。Baymard的调研里，76%的用户表示至少有时会看交叉销售，59%专门去看有没有一个自己漏掉的更好的选项，这是2025年对1005名美国网购者的调查。也就是说用户看这一块的主要动机是找替代品，而三成的站在这个位置上放的是别的东西。推错一次的代价在购物车那一篇里算得更细。

两个不能相减的数，以及为什么还是要提

前面说中间分类页那两个数问的不是同一件事，横滚区那两个数口径也不一致。既然不能相减，为什么还要写进来？

因为它们能提供方向上的旁证。中间分类页那一篇统计的是有没有这一层页面，内联滚动区那一篇统计的是筛选面板里用没用滚动条，两者跟App侧的统计对象都有偏移。把它们当作证据会削弱论证，当作旁证则刚好。

这里顺手交代一个方法上的取舍。做这类跨来源的数据拼接，最大的诱惑是把口径相近的数硬凑成一张整齐的表，因为整齐的表更有说服力。而一张有五行严格可比、外加两行明确标注口径不同的表，比一张七行整齐但有两行经不起追问的表结实得多。 被追问的时候，前者只会丢掉两行旁证，后者会连带着让另外五行一起失去可信度。

另外那个60%找不到分类入口的观察，同一件事还有一个更早的旁证：Baymard在移动站主导航那一篇里写过，用户找不到分类之后会退回搜索，而搜索会把范围收窄到不适合他当前目的的程度。这跟本文引的App侧观察几乎是同一句话，只是发生在另一个容器里，隔了三年。

无障碍标准里那条免责条款，为什么在App里用不上？

两条触达尺寸准则都给尺寸由浏览器决定的情况开了免责。而App里几乎没有哪个像素不是你自己画的。

例外条款是写给谁看的

WCAG 2.2里有两条关于触达尺寸的成功准则。2.5.8属于AA级，要求指针目标至少24×24个CSS像素；2.5.5属于AAA级，要求至少44×44。

两条准则都各带一组例外，其中有一条一模一样，措辞也几乎一样：目标的尺寸由用户代理决定，且作者未做修改。翻成人话就是，这个按钮多大是浏览器说了算的，我没动过，那它不达标不算我的问题。

这条免责非常合理。规范的作者知道，把责任压在管不到的东西上没有意义。表单控件的默认尺寸、下拉列表里每一项的行高、日期选择器里那些小方块，都是浏览器给的，作者确实动不了。

然后把这条例外搬到App里试试。App里有哪个像素不是你画的？ 系统控件当然存在，可你几乎总会改它的高度、字号、内边距、图标尺寸，一旦改了就不再是未做修改。这条免责在App里几乎无处适用。

容器替你担的那份责，交接时不发通知

这就引出这套框架里最值得记住的一句：容器替你做的决定，同时也替你担了责。而你接管这个决定的时候，不会同时收到那份责任的通知。

换容器的时候，交接清单上写的是功能：搜索要有、筛选要有、结算要有。没有人会写一份默认值交接清单，列出你原来那个容器免费给了你哪些东西、你从今天起要自己维护它们、以及它们原本挂在谁的名下。

这份清单不存在的原因也很朴素：要列出它，你得先知道那些东西曾经是别人给的。而一个从入行第一天就在浏览器里写页面的人，很难意识到回车能提交搜索这件事有一个规范条款在背后撑着，他会觉得那是世界的物理性质。

顺带说一句单位。这两条准则用的是CSS像素，不是设备物理像素，也不是原生里的点。这几个单位在不同场合的换算关系经常被搞混，浏览器信息查询工具报的那58项里，屏幕分辨率和设备内存都不是你以为的意思那篇把这一层讲清楚了，做尺寸验收之前值得先对一下单位。

21%为什么是十一条里最低的

现在回到那份App问题清单，看它最低的那一格。图片上叠了读不清的文字，只有21%的App没做好，是十一条里表现最好的一条，比第二好的那条高出十个百分点。

为什么偏偏是这一条？因为它是十一条里唯一一条在Web时代有外部执法者的。

图里烤字在网页上会同时踩到三个人的脚：读屏软件读不出来，无障碍那一侧有人管；搜索引擎抓不到那几个字，SEO那一侧有人管；欧洲那些无障碍法规落地之后，法务那一侧也开始有人管。三路执法，各自独立，谁都能把这件事推回来重做。

被反复教育过的东西会变成肌肉记忆，团队换到App里，这份记忆跟着一起过去了。所以这一条的成绩在两个容器里都不错。

三种执法者，只有一种在App里还在岗

不过这份好成绩里有个陷阱，值得单独说清楚。它是惯性带来的，不是机制带来的。

把三个执法者在App里逐个点一遍：无障碍那一侧还在，系统的读屏与动态字号仍然会暴露问题，尽管它的检查手段和Web上完全不同；搜索这一侧彻底缺席，App里的图和文字不进任何搜索引擎的索引，图里烤字在App里搜不到只是搜不到，没有任何一份报表会掉；法务那一侧则取决于你的市场与产品形态，边界比Web模糊得多。

三路里少了最勤快、最便宜、反馈最快的那一路。这一路在Web上有多勤快，看看移动优先索引那次转换里Googlebot的渲染机制就知道了：它不打招呼、全天候、按自己的口径给你打分，你的移动端做得不行，桌面排名跟着掉。这个机制严厉，但它免费而且从不休假。

所以图里烤字这一条在App里的21%，不该被读成App团队在这件事上有免疫力。它更像一份存款：存款是Web时代攒下的，而App这一侧只剩两个人在往里存，其中一个还只在部分市场上岗。

另外四条例外，说明规范作者在想什么

触达尺寸那条准则一共给了五个例外，把剩下四条也读一遍，会看出规范的作者是按什么逻辑分配责任的。

一条是间距例外：目标小于24像素也可以，只要以每个目标的外框中心画一个直径24像素的圆，这些圆彼此不相交。一条是等效例外：同一个页面上有另一个达标的控件能完成同样的功能。一条是行内例外：目标在一句话里，或者它的尺寸受非目标文字的行高约束。最后一条是必要例外：这种呈现方式是信息本身必需的，或者法律要求的。

把五条排在一起看，逻辑很清楚：规范只在作者真正有控制权的地方追究责任。 行高约束的、用户代理决定的、法律规定的，都放过；作者自己排出来的密度，一个都不放过。

这份分配方式本身没什么问题，问题在于它是按Web的权责结构写的。搬到一个所有像素都归你的容器里，五条例外里能用上的就只剩间距、等效和必要那三条，而这三条都要靠你自己举证。

三个执法者在App里的实际状态

前面说搜索这一路在App里彻底缺席，这个判断需要再精确一点，否则容易被误读成App完全没有外部检查。

App商店的审核算不算一路执法者？算，但它管的东西和界面可用性几乎不重叠：它盯的是隐私、支付合规、内容分级、崩溃率这些硬门槛。一个搜索框没有提交按钮的App，审核不会拒它；一个图上文字小到看不清的App，审核也不会拒它。

评分和评论算不算？理论上算，实际上很弱。用户在商店里打一星写的多半是闪退、扣错钱、找不到订单，很少有人会写你们搜索框旁边缺个按钮——回到前面那条规律，遇到这问题的人要么已经走了，要么已经学会绕了。

所以清点下来，Web上那三路执法者到了App里的状态是：无障碍这一路还在，但检查手段完全换了一套；搜索这一路整条消失；法务这一路取决于市场，边界比Web模糊得多。 而消失的那一路，恰好是三路里反馈最快、成本最低、覆盖最全的。

那就自己补一个裁判

既然免费的裁判没有了，唯一的办法是自己造一个便宜的。造法不需要工具，只需要把检查变成断言。

具体做法是把几条能被机器判断的规则写成构建时的检查项，让它们跟着每次打包跑。能写成断言的例子：搜索输入控件的同级视图里必须存在一个可点击的提交控件；图片展示容器必须挂上缩放手势识别；主要可点击区域的高宽不得小于设定值；标签栏配置项的数量不得超过五个。

这几条都不需要跑UI测试，遍历一遍视图层级就能判。它们的价值不在于覆盖率高，在于把一个靠人想起来的事，改成一个不想起来就过不了的事。前面说过，一件从未被提出的事不会有人反对——那就让构建脚本替你提出来。

这也是那类需要长期维持的一致性问题的通用解法：不要做成一次专项，要做成一个卡点。 专项有开始有结束，一致性没有结束的那一天。检查项写完之后要顺手记一条：新加检查项时必须先造一个会失败的例子跑一遍，确认它真的会红。否则你可能挂了一个永远为真的断言，看起来在守着，其实什么都没守。

两个级别的尺寸要求，选哪个

触达尺寸有两条准则，数字差了将近一倍，实际选哪个值得说清楚。AA级那一条要求24×24个CSS像素，是多数合规场景的实际门槛；AAA级那一条要求44×44，属于更高的目标。

AAA级那条的说明里有一段话解释了为什么触摸格外麻烦：触摸是一种精度很粗的输入方式，用户没有鼠标或触控笔那样的精细控制；手指比鼠标指针大，而且它通常还挡住了屏幕上正被点击的那个位置。 后半句是关键——点鼠标你能看见准星，用手指你看不见自己在点哪儿。

实践上的建议是：主流程上的操作按24这个下限当红线、按44当目标，而列表里那些密集排布的次要操作靠间距例外来满足，别硬把每一项都撑到44，那会把列表的信息密度毁掉。

顺带说一句，这两条准则用的是CSS像素，跟原生里的点也不是同一个单位，跨端对齐尺寸规范的时候这一步最容易出错。屏幕分辨率那几个字段各自在说什么那篇可以当一份换算备忘。

动态字号是App里最容易被忽略的那一条

无障碍这一路在App里还在岗，但它的检查手段和Web上完全不同，其中最容易翻车的是字号。

Web上用户放大字号，靠的是浏览器的缩放或者字体大小设置，布局按相对单位跟着走。原生这一侧对应的机制是系统级的动态字号，用户在系统设置里调大字号之后，你的界面会不会跟着变，取决于有没有人在写界面时用了支持动态字号的文本样式。 写死一个字号，界面在任何设置下都长得一模一样，看起来很稳定，实际上是把一批用户挡在门外。

而这件事的验收有个陷阱：把系统字号调到最大之后，出问题的不是字看不清，是布局被撑破——按钮上的字被截断、两列变成重叠、底部标签栏的文字挤成一团。这些问题只有把字号推到极限才会出现，而验收的人手上那台设备是默认字号。

这跟前面那个横屏折叠标签栏的问题属于同一族：都是一个只在非默认设置下才出现的故障，而验收环境永远是默认设置。 所以App的验收清单上应该有一条固定动作，就是把设备设置里的字号、显示缩放、深色模式各推一次极端值，每次都把主流程走一遍。二十分钟的事。

这些问题为什么从来没人投诉？

新用户遇到了直接走，老用户遇到了已经学会绕。两头都不投诉，于是问题的严重程度和它被报告的概率成反比。

先看清你的App到底服务着多少人

Baymard做过一轮针对原生App的用户调研，几个数字放在一起会改变很多人对App优先级的判断。

用户心里排第一的那个电商站，75%的人装了它的App；装了的人里63%表示更愿意用App下单。这两个数听起来很鼓舞人。但把没装的人也算进去，比例就掉了：即便你是用户心中的第一名，也只有47%的人主要用App购买，另外53%仍然留在移动网页上。

接着往下走。排第二的站，只有31%的用户更愿意用App；第三名25%，第四名22%，第五名19%。而调研里72%的人把Amazon列为第一名，第二名eBay只有4%，Walmart也是4%。

结论很直接：除非你是那个72%，你就是别人的第二到第五名，你的App被当作主要购买渠道的比例在两成上下。这个占比很容易让人得出别投了的结论，但它同时还带着另一层信息——这两成人是你复购最频繁、生命周期价值最高的那批人。私域社群那套五维指标里反复出现的就是这批人，只是那边是从社群侧看，这边是从容器侧看。

两头都不投诉的那批人

用户量小、价值密度高，本来不构成问题。真正的问题是这个组合恰好制造了一个反馈黑洞。

遇到搜索框问题的人分两类。第一类是新用户，他搜不出来东西，退出App，可能装了三天就卸了。他不会写反馈，因为他不欠你什么，你在他心里也还不值得他花五分钟打字。

第二类是老用户，他遇到同一个问题，但他已经知道该怎么绕：打完字往键盘右下角摸，或者干脆记住了商品在哪一屏。他也不会写反馈，因为在他看来这件事已经解决了。

于是就有了一条反直觉的规律：一个App的可用性问题，它的严重程度和它被报告的概率成反比。 越是拦在主路上的问题，越会在早期就把新用户筛掉，剩下的全是已经学会绕路的人；越是无关紧要的小别扭，反倒是那些愿意留下来提意见的人才有心情提。

Baymard的移动端整体研究里有一个配得上这段的数字：63%的移动用户在测试中至少一次因为完全可以避免的可用性问题，放弃了一个商品或者整个站点。测试环境里能看见这个动作，因为有人坐在旁边看着。放到线上，它长得跟正常流失一模一样。

Web那一侧有一个免费的裁判，App没有

为什么Web上的团队更容易发现同类问题？不是因为他们更聪明，是因为他们头上有一个不请自来的第三方裁判。

搜索引擎每天来抓你的页面，按它自己的口径打分，然后用排名和流量告诉你结果。这个信号有三个稀缺的性质：它不要钱、它天天来、它跟你内部的立场无关。一个页面改坏了，排名会掉，而排名掉这件事在任何一间公司都有人看。

App这一侧没有这样一个裁判。应用商店的搜索排名跟界面体验的相关性很弱，主要吃的是关键词、评分和下载量，应用商店搜索与搜索引擎的连接逻辑那篇把这两套机制的差别拆过。至于App里那些页面，它们压根不在任何索引里——这也是当年一批团队做PWA的动机之一，PWA的抓取与索引影响那一篇算的就是这笔账。

没有裁判的直接后果是：你唯一的评分来源变成了自己的报表，而报表只反映你想到要埋的那些点。 你没想到搜索提交按钮是个问题，就不会去埋搜索词被清空这个事件，于是这个问题在数据上完全不存在。

一个横幅，把人从哪里推到哪里

说到这里可以把两个来自不同研究的数字拼一下，拼出来的结论有点难看。

Baymard统计过，53%的移动电商网站会显示安装App的广告。这些横幅通常在首屏，有时候还叠着隐私提示，测试里观察到这类非商品内容加起来能把用户可见的页面内容压掉一半以上。

现在把前面那张表拿回来对一下。移动网页那一侧，79%的站有搜索提交按钮；App这一侧，只有10%有。 于是这个横幅的实际作用是：花掉首屏最贵的一块位置，把用户从79%的地方，请到10%的地方去。

这句话不是反对做App。它想说的是，推装量这件事在很多团队里归增长，做App体验归另一个组，两边的目标在报表上都完成得很好，而中间那段落差没有任何一份报表负责。

成本高十倍，可见度低十倍

最后是经济学那一层，它解释了为什么这份清单常年排不上去。

Web上改一行文案，今天写完今天上线，错了十分钟回滚。App上改一行文案，要打包、过审、发版，然后等用户自己更新。修复成本高一个量级，而前面已经说清楚了，问题的可见度低一个量级。成本高十倍乘以可见度低十倍，就是一百倍的优先级差距。 没有一个App达到良好，这件事的经济学解释就在这里。

还有一件Web上压根不存在的事：App的旧版本永远不会消失。 你今天修好了搜索提交按钮，那些装着旧版本的人还在用坏的那一版，而他们往往是装得最早、最忠诚的那批。这一条会在下一节变成一个真实的教训。

把这个占比翻译成一份资源分配

两成用户这个数字容易被两种方式误用，都得避开。

第一种误用是据此砍掉App的投入。这里的问题是这两成人的价值密度不是两成。他们装了App、反复回来、下单频率高，把他们的订单量与生命周期价值加起来，通常远超两成这个人数占比。用人数占比来分配资源，等于按人头而不是按产出分。

第二种误用更常见：据此把App当成主战场，把移动网页当成配角。前面那个数已经把这条路堵住了——即便你是用户心中的第一名，也有53%的人主要用移动网页买东西。 而你大概不是第一名，那么留在移动网页上的比例只会更高。

合理的读法是把它当成一份分工说明：移动网页承担获客与首次购买，App承担复购与留存。 两个容器的优化目标不该一样，验收指标也不该一样。用同一份漏斗指标去考核两个容器，会同时得出两个错误结论。

把不投诉这件事再往下追一层

老用户学会绕路这件事，还有一个更隐蔽的后果。

他绕过去之后，那条绕路的路径会变成他的习惯，而习惯一旦形成，你把问题修好了他也不一定回到正路上来。 一个学会了不用搜索、靠翻订单历史找商品的人，你把搜索修好了，他也可能继续翻订单历史，因为对他来说那条路已经是最快的了。

这带来一个测量上的麻烦：修复的效果会被老用户的习惯稀释，而稀释的程度取决于这个问题已经存在了多久。存在时间越长的问题，修好之后的短期收益越小，而这很容易被误读成这个问题本来就不严重。

所以评估这类修复的时候，应该把新用户和老用户分开看。新用户那一组的数字才是这个修复的真实效果，老用户那一组反映的是习惯的迁移速度，两个数混在一起看不出任何东西。这跟按版本号切分是同一类动作——一个混合群体的均值，永远在同时替两拨人说话。

那个横幅的账，还可以再算细一点

前面那句把用户从79%的地方请到10%的地方，是一句尖锐但粗糙的话，值得补上它的边界，否则会被当成反对推App。

它成立的前提有两个。第一，你的App在那几条具体准则上确实不如自己的移动网页——这个可以查，装一台设备两边各走一遍。第二，被横幅带走的那批人里，有相当比例是首次访问者，也就是那批最经不起摩擦的人。

如果两个前提都成立，那么这个横幅的净效果是负的：它用首屏最贵的位置，把最脆弱的用户送到你最没打磨的容器里去。Baymard对这类广告的建议本身也是弱化处理或者干脆不放，另外统计过47%的站在用户浏览过程中压根不显示安装App的广告，说明不放它并不是什么激进选择。

如果前提不成立——你的App确实比移动网页做得好——那这个横幅就是划算的。关键在于这个前提从来没有人验过，它在多数团队里是一个假设，而且是一个所有人都默认为真的假设。

顺带说一句，安装引导这条链路上还有一个技术层面的老问题：用户点了横幅进商店、装完打开，能不能回到他原来那个商品页。这一段的机制和实现路径，应用商店搜索与网页SEO的连接逻辑那篇拆过。断在这里的话，你不只是把人送到了一个更粗糙的容器，还顺手让他从头开始找一遍。

那63%的弃单，和它为什么在线上看不见

前面引的那个数值得再交代一下口径，因为它常被引错。Baymard在移动电商体验的五个总体问题里给的原话是：63%的移动用户在测试过程中，至少有一次仅仅因为可以避免的可用性问题就放弃了一个商品或一个站点。

注意两个限定词。一个是仅仅因为——排除了价格、库存、评价不好这些正当理由。另一个是至少一次——不是63%的会话失败，是63%的人在若干次任务里至少踩了一次。

这个数在测试环境里能拿到，靠的是有研究员坐在旁边看着并且事后追问。线上拿不到它，不是因为埋点不够，是因为一次可用性弃单和一次正常的不感兴趣，在事件流里长得一模一样。 两者的区别只存在于用户的意图里，而意图不产生事件。

这也解释了为什么这类问题的清单几乎只能靠外部研究获得。你自己的数据能告诉你哪里流失了，但告诉不了你为什么，而在没有为什么的情况下，团队会自然而然地把流失归因于自己已经知道的那几个原因——价格、库存、竞品。这个归因过程没有人作恶，但它的输出永远不会包含你压根没意识到的那个原因。

安装横幅那两个数的出处

横幅那笔账里的53%和47%，来自Baymard专门讲弱化安装App广告或者干脆别放的那一篇。它的建议本身就是弱化或者不放，理由包括这类广告与隐私提示等非商品内容叠加之后，能把用户可见的页面内容压掉一半以上。

而装机率与主要购买渠道那一组数，来自前面提过的原生App研究。把这两篇放在一起，就是那句难看的话的完整依据。

如果要给这一段一个更中性的表述：推装量与做App体验这两件事，通常由两个不同的组负责，各自有各自的指标，而没有任何一个指标横跨两个容器。 中间那段落差不是谁不称职造成的，是因为它落在了所有人的考核范围之外。

这一层组织问题在其他场景也反复出现。同一个数字被两个团队按不同口径算出相反结论那件事，两套报表都没算错却结论相反那篇讲得比较细，机制是一样的：只要没有一个人的指标横跨那条缝，缝里发生什么都不会有人报。

保哥的失手：一条缓慢上升的曲线，其实是两条平线

改动上线后指标连涨四周，团队判断在持续生效。按版本号切开之后才发现，新版本第一天就跳完了，旧版本一动没动。

改了两件事，曲线开始缓缓往上走

去年帮一个做汽车配件与改装件的客户看App。这个品类有它自己的性格：SKU多得离谱，同一个零件按车型年款分出十几个版本，用户是发烧友，复购频率高，而且极度依赖看图确认这个件装得上装不上。

体检下来问题一堆，我们只挑了两件最便宜的先做：在搜索框右边加一个提交按钮，并把软键盘的换行键改成搜索；给商品图和图库加上捏合缩放，双击也支持。 前后不到两周，发版上线。

然后指标开始动了。App内的搜索转化率从上线那周起往上爬，第一周涨了一点几个百分点，第二周继续，第四周累计涨了大约5个百分点。团队看着这条曲线很高兴，会上的说法是这个改动在持续生效、用户在慢慢适应新的界面。

我当时也没觉得哪里不对。曲线在涨，方向是对的，涨幅也是真的，数据口径没有任何问题。

那条曲线到底在描述什么

大约第六周，我们准备写复盘，想拆一下哪个品类涨得最多，就把数据按App版本号切了一刀。切完之后那条漂亮的曲线散架了。

真实情况是：装了新版本的用户，搜索转化率在他们更新完的那一天就跳了大约18个百分点，之后一直平着；装着旧版本的用户，四周里一动没动。 整体那条缓慢上升的曲线，是这两条水平线按人数比例混出来的——新版本用户的占比在缓慢爬升，混出来的均值就跟着缓慢爬升。

更难看的是分母：上线四周之后，仍然有大约四成用户在旧版本上。 这个品类的用户不是天天开App的人，装了不用、几周才想起来打开一次很常见，而不打开就不会触发商店的更新。

于是那句永久性的判断就来了：一条缓慢上升的曲线，可能是两条水平线的加权平均，权重在动而值一点没动。

判据只有一句话

这件事之后我给自己留了一条硬判据，很短，可以直接抄：

如果一个改动是瞬时生效的——代码上线那一刻它就在起作用，不需要用户学习、不需要数据积累、不依赖任何冷启动——那么它的效果曲线就不应该是渐进的。看到渐进，先怀疑分母里混了两个群体。

加一个按钮属于瞬时生效：用户不需要学，他本来就在找它。所以那条爬了四周的曲线，从第一天起就该被当成一个异常，而不是当成一个好消息。

这条判据的适用范围不限于App。灰度放量、多语言分批上线、缓存逐步过期、CDN节点逐个刷新，任何一次分批到位的变更都会制造出这种混合曲线。它跟仪表盘全是绿灯生意却没动那类问题是同一族：数字没有错，错的是它在替两个不同的群体说同一句话。

低估比高估更贵

这次失手的代价不在数字本身，在数字导致的那个决定。

团队看到的是5个百分点，实际效果是18个百分点，真实收益被低估了三倍以上。而在他们看来，两周的开发换5个百分点属于还行但不惊艳，于是下一个季度的排期里，App那一摊被降了优先级，人挪去做别的了。

如果第一天就看到18这个数，后面那份清单——分类入口、横向滚动区、图上文字——大概会一路做下去。一次低估比一次高估更贵，因为高估会被现实很快纠正，低估会安静地关掉一整条路。

还有第二个被漏掉的问题，那个更糟：还有多少人正在受这个苦，这个问题从头到尾没有人问出来。 四成用户在旧版本上，意味着我们上线了一个修复，然后有四成的人继续用着坏的那一版，而在整体曲线上升的气氛里，没有人想到该去数一下他们有多少。

这次预警的形态，和以前几次都不一样

我复盘失手的时候习惯先给预警形态归个类，因为这决定了下次该在哪儿设卡。以前遇到过的几种是：根本没有预警；预警用了另一个部门的语言，听的人没听懂；预警被读成了捷报；修好之后监控跟着失明；预警被转给了另一个科室；预警被降级成一次沟通问题；预警被当成怀旧带过；还有一次是预警响了、内容也准确，只是响在一个不认识这件事的人的收件箱里。

这一次是全新的一种：指标是对的，方向是对的，涨幅是真的，它只是在描述一个混合群体，而混合的比例本身在动。 没有任何一个环节出错，没有任何一个人失职，报表也没坏。它甚至不是一次预警的失败，是一次好消息的失败。

改了三条

后来在这个客户那边落了三条规矩，都不需要新工具。

第一条：任何App端改动的效果，必须按App版本号切分来看，不许只按日期切。版本号在埋点里早就有了，不需要新增字段，只是从来没有人拿它当维度。

第二条：把旧版本用户占比单独画一条曲线挂在看板上。它是所有App指标的隐藏分母，不看它，你看到的每一个整体数都是一次口径不明的加权平均。

第三条：瞬时生效的改动如果画出渐进曲线，按口径故障处理，不按效果曲线处理。这条写进了他们的发版复盘模板，就一行字，位置在效果评估那一栏的上面。

为什么没有人在第一周就发现

复盘的时候把这四周还原了一遍，四道关口全都没拦住，而且每一道的失守都很合理。

第一道是数据看板。看板上那条搜索转化率是全量口径，从建站起就是这么定的，没有任何人改动过它。它没坏，它只是从来没有被要求区分版本。

第二道是发版复盘的模板。模板上那一栏叫效果评估，问的是涨了还是跌了、涨了多少。这个问题被完整地、准确地回答了。模板没有问过这个涨幅是在谁身上发生的。

第三道是我自己。我看到曲线在爬，第一反应是用户在适应新界面，这个解释听起来很顺——它甚至符合一种常见的直觉，就是新东西需要时间被接受。而这个直觉恰好把一个应该报警的形状，解释成了一个正常的形状。

第四道是客户那边的技术。他们清楚知道有多少人在旧版本上，这个数在他们的发版后台上摆着。但那个后台是运维视角的，看的是崩溃率与升级覆盖，而看转化率的人不看那个后台，看那个后台的人不关心转化率。

四道关口，没有一道是失职。这也是这类问题最难防的地方：它不需要任何人犯错就能发生。

这个形状还会出现在哪些地方

混合曲线不是App特产，把它的触发条件抽出来，就能提前认出它。触发条件是两个：一次改动只对一部分人生效，而这部分人的占比随时间变化。

符合这两条的场景比想象的多。灰度放量，比例每天在调；多语言站分批上线，语种一个个铺；缓存逐步过期，老页面还在服务一部分人；CDN节点分批刷新；A/B实验的流量分配被中途改过；甚至只是某个改动依赖用户下一次登录才生效。

每一种都会画出一条漂亮的渐进曲线，而每一条都不是效果曲线。识别它只需要一个动作：找出那个正在变化的比例，把它和效果曲线画在同一张图上。 如果两条线的形状高度相似，那你看到的不是效果，是覆盖率。

这跟缓存那一侧的老问题是同一族。多层缓存下同一个页面对不同用户呈现不同版本，TTFB与多层缓存那一篇算的是它对指标口径的影响，本质上也是一次覆盖率被误读成效果。

如果当时按版本切了，会看到什么

值得把正确的那张图描述一遍，因为它长得跟错的那张完全不同，而且更好用。

正确的图上有两条线：新版本用户的搜索转化率，上线次日跳升18个百分点然后走平；旧版本用户的搜索转化率，一条水平线。两条线之间那个18个百分点的间距，就是这次改动的真实效果，而且它在第二天就已经完整呈现，不需要等四周。

这张图能支撑的决策也完全不同。看到5个百分点，你会讨论要不要再优化一下；看到18个百分点加上四成用户还在旧版本，你会讨论两件事：后面那份清单要不要一口气做完，以及怎么把这四成人推上新版本。第二件事在错的那张图上压根不会被提起。

顺便说，18这个数还有一个用处：它成了后续所有App改动的对照基线。有了一个真实幅度的锚点，下一次某个改动只涨了2个百分点，你就知道那不是App没潜力，是这个改动本身不重要。 没有锚点的时候，两个都长得像还行。

这也是我后来做任何一次改造都会先挑一个预期效果最明显的动作打头阵的原因：第一枪的意义不只是拿结果，是给后面所有的枪定一把尺子。 尺子定错了，后面每一次评估都会跟着错，而且是往同一个方向错。

哪五个指标不用新增埋点就能看？

五个数全在你已经存了很多年的东西里：埋点里的版本号、搜索日志、标签点击、订单表上的客户端标识。

一、按版本号切开的那份老指标

这不是一个新指标，是给旧指标换一种切法。把转化率、搜索使用率、加购率这几个数按App版本号分开看，而不是按日期。版本号躺在你的埋点里很多年了，从来没被当成维度用过。

用处有两个：一是能看清一次改动的真实幅度；二是能看清一个老问题还在多少人身上活着。这两件事按日期切都看不见。

二、旧版本用户占比

单独一条曲线，画的是当前有多少比例的活跃用户还在旧版本上。它是App所有整体指标的隐藏分母。

这条线还有一个副产品：它能告诉你一次修复的兑现周期到底有多长。如果你的品类是几周才打开一次的那种，兑现周期可能长达两三个月，那么任何一次上线后四周内做的效果评估，都是在一个混着旧版本的池子里做的。评估窗口应该按这条线定，而不是按会议排期定。

三、搜索词被清空的次数

这个数不需要新埋点，你的搜索日志里已经有了。找那种模式：同一个会话里，连续两次搜索，后一次的词是前一次的前缀或者干脆是空的，中间间隔只有几秒。 这就是用户打了一半、手一抖点到清除、又重打的痕迹。

它是那个缺失的提交按钮在数据上唯一的影子。搜索日志本身就是被严重浪费的一份第一方数据，站内搜索数据怎么挖关键词那篇讲的是它的选词价值，这里用的是它的可用性诊断价值，同一份日志两种用法。

四、更多标签里那些项的点击率

如果你的标签栏有溢出，把被折进更多里的那几项的点击率，跟留在外面的那几项对比着看。差距通常大得让人不舒服。

这个对比的价值在于它能把一个设计争论变成一个数字。标签栏放什么这件事在会上争起来往往靠嗓门和职级，而这个数字能直接回答被折进去等于损失多少。 顺便说，如果你的App在小屏或者横屏下才发生折叠，这个数要按设备分组看，否则会被大屏用户的数据冲淡。

五、装了App却在移动网页上下单的人

这一条我认为是五个里最狠的。找出那些明确装过你App的用户，看他们有多少比例的订单是在移动网页上完成的。客户端标识在你的订单表里已经存了很久。

为什么狠？因为一个装了你App的人选择打开浏览器去下单，是他用行动告诉你App更难用。 这句话不会出现在任何一份满意度问卷里，问卷上他大概只会勾一个还可以。行为数据在这里比态度数据可信得多。

这个数还有一个用法：把它和推装量的KPI放在同一页上。前面算过那笔账——首屏那个横幅把用户从79%的地方请到了10%的地方，这个指标就是那笔账的收据。

怎么排先动哪一格

四格交叉，横轴是App装机率，纵轴是App内购买占比，先动装机率高但App内购买占比低那一格：这批人已经装了、说明有意愿，却不在App里买，落差就是体验债。

两个提醒。第一，装机率低而购买占比也低的那一格别急着下结论，它可能只是你压根没推过装，跟体验没关系，看一眼推装的历史投放就能分辨。第二，不建议算App平均搜索次数这类数：一半用户压根不用搜索、少数重度用户一次会话搜十几次，平均下来那个数不描述任何真实的人，而且对改造极不敏感。长尾极不均匀的时候放弃平均值，去看形状。

验收只需要一个动作

所有这些之前，有一件五分钟就能做完的事，而且比任何看板都直接：拿一台不是你主力机型的手机，装上你自己的App，横过来，把底部标签栏拍一张照。

数一下有几个标签在外面，几个躲进了更多里，然后问一句：一个第一次用我们App、想随便逛逛看有什么的人，从这一屏出发，几步能走到全部分类？

这个动作不需要预算、不需要排期、不需要任何一个人的批准。它没有被做过，不是因为难，是因为在那间会议室里，所有人手上拿的都是同一款手机，而且都是竖着拿的。

这十一条按什么顺序做

指标定完，剩下的问题是清单怎么排。按没做比例排是最常见的做法，也是错的——比例高只说明同行也没做，不说明它对你的用户最重要。

我用的排法是两个维度相乘。第一个维度是这件事在你的容器里默认存不存在：默认不存在、而用户预期是百分之百的那几条排最前，因为它们的失败方式是用户认定你压根没这个功能。搜索提交和捏合缩放都落在这一格。

第二个维度是失败之后有没有痕迹。 有痕迹的可以后放，因为你随时能发现；没痕迹的要提前，因为不做它你永远不知道自己在损失什么。图上文字读不清有痕迹——用户会放大、会问客服；找不到分类入口没有痕迹，他就是退出了。

两个维度都占的那几条最先做。两个维度都不占的，比如首页广告太抢眼，可以留到有一次首页改版的时候顺手处理——不是它不重要，是它的解决方式不在这份清单的语境里，它要动的是位置分配的权责。

把这份清单变成上新流程的一部分

做完一轮之后真正的风险是复发。App这一侧的复发概率比Web更高，因为每一次新功能都可能加一个新页面、一个新的图片展示位、一个新的输入框，而新东西默认不带这些能力。

所以最后一步是把检查挂到流程上，位置选在提测之前而不是上线之前。挂在上线前的检查项，发现问题的代价是延期，于是它会被商量掉；挂在提测前，发现问题的代价是改两行代码。

清单可以很短，四行就够：这个页面有输入框吗，有的话提交动作在哪；这个页面有图片吗，有的话能不能放大；这个页面有新的标签或入口吗，加进去之后标签栏总数是几个；这个页面上有没有把文字烤进图片里。

四个问题都能在提测前三分钟内回答完。它们值钱不是因为难，是因为提问的时机比问题本身重要。 这份清单要是放在设计阶段问，答案会是我们会注意的；放在上线前问，答案会是下个版本改；只有放在提测前，答案才会是我现在就补。

最后留一句可以直接搬进评审的话

整篇文章如果只留一句话带进你们下一次的评审会，我建议是这一句：

这件事在我们上一个容器里，是我们做的，还是它白送的？如果是白送的，现在这个容器里谁负责它？

问出来通常会有几秒钟的安静。这不是因为难回答，是因为在那之前，没有人把白送的东西当成需要有人负责的东西。 而这份清单上90%那一条、80%那一条，全都是这样丢掉的。

这句话还有一个附带的好处：它把讨论从谁做错了挪到了这件事归谁。前者会让会议进入自证清白的模式，谁都不肯先开口；后者只是在分派一件还没有主人的活，认领的成本低得多。一份清单能不能被执行下去，往往不取决于清单写得多好，取决于它上面每一行有没有一个具体的名字。

常见问题解答

电商App的体验为什么普遍不如移动网页？

准则不是两套，Baymard逐条核过之后发现移动网页的准则有98%同样适用于App，所以不能用平台不同来解释。真正的差别在于容器替你做掉了哪些决定。浏览器和HTML规范免费提供了一批能力，比如回车提交搜索、页面默认可以捏合缩放、嵌套滚动的手势仲裁，做网页的人没有机会不做。这些能力在原生环境里必须有人主动想起来、写进需求、排进工期。一件从未被提出的事不会有人反对也不会有人支持，它在评审、验收、复盘里全都是缺席的，所以它不是做错了，而是压根没发生。

为什么同一条准则，移动网页21%没做，App却是90%没做？

因为Web上有一条规范级的兜底。HTML规范的隐式提交一节规定，表单即使一个提交按钮都没有，只要阻止隐式提交的字段不超过一个，按回车也要提交这个表单，而一个站内搜索表单里这样的字段正好是一个。所以在Web上你需要主动做错才能让搜索提交不了。原生这一侧没有这条兜底，苹果对搜索框的定义只包含搜索图标、清除按钮和占位文字，提交动作被交给了软键盘。结果用户在输入框旁边找确认，摸到的是清除，把自己刚打的词删了。

App里为什么要专门实现捏合缩放，网页上不用？

视口参数里控制缩放的那一项默认就是允许，也就是说不写任何代码页面也能放大。后来一批站主动关掉它，于是从iOS 10开始系统直接忽略这个关闭指令，你想禁都禁不了。CSS那一侧同理，触摸行为属性的默认值就是让浏览器处理所有平移与缩放。所以这个能力在Web上走完了默认给你、你可以关掉、你关不掉三个阶段，用户的预期被拉到百分之百。原生环境里它得从零搭：可缩放容器、缩放上下限、双击手势、放大时换高清图，每一步都要有人想到。

差值全是App更差吗，有没有反过来的例子？

有，而且这一条比前面几条更能说明问题。结果页保留用户搜索词这件事，桌面站33%会清空，移动网页42%清空，App只有33%没保留，App跟桌面持平、比移动网页好出9个百分点。原因是原生环境里那串字天然待在控件属性上，什么都不做它也不会消失，要清空反倒得有人主动写。而网页的结果页通常是一次全新的文档加载，上一页的输入框连着整个页面一起没了，得从查询参数里把词取出来再回填进去。方向能反过来，说明这套解释描述的是默认值归谁，不是团队水平谁高谁低。

底部标签栏最多放几个，放不下的分类入口怎么办？

苹果建议默认清单控制在五个以内，而且明确写了：可见的标签数可能少于你设的总数，取决于设备尺寸与方向，横向空间不够时最后一个会变成更多，剩下的收进单独列表。同一份代码在小屏或横屏下折叠点就不一样，而验收通常只在一台主力机型竖屏上做过。Baymard测到60%的用户在Amazon的App里找不到浏览分类的入口，那个入口就藏在底部导航的汉堡图标后面。稳妥的做法是把去全部分类这条路明确标成分类或者选购，占住一个格。

无障碍标准里那条免责条款为什么在App里用不上？

WCAG 2.2的两条触达尺寸准则，AA级要求至少24×24个CSS像素，AAA级要求44×44，两条都带同一个例外：目标尺寸由用户代理决定且作者未做修改。这条免责在Web上真实有效，表单控件、下拉项、日期选择器的默认尺寸确实是浏览器给的。可App里几乎没有哪个像素不是你画的，系统控件也总会被改高度、字号和内边距，一改就不再是未做修改。容器替你做决定的时候也替你担了责，而你接管这个决定时不会同时收到那份责任的通知。

不新增埋点，先看哪几个数能判断App体验的欠账？

五个都在你已有的数据里。按App版本号切开转化率与搜索使用率，而不是按日期，能看清真实幅度；单独画一条旧版本用户占比曲线，它是所有整体指标的隐藏分母，也决定了效果评估的窗口该开多长；从搜索日志里找连续两次搜索、后一次是前一次前缀且间隔只有几秒的模式，那是提交按钮缺失留下的影子；如果标签栏有溢出，对比更多里那几项与留在外面那几项的点击率；最后看装了App却在移动网页上完成订单的比例，那是用行为而不是用问卷说出来的差评。不建议算平均搜索次数这类数，长尾极不均匀时平均值不描述任何真实的人。

权威参考资料