同一根手指要负责翻页、握住手机和下单，而你的界面只认得最后那一种

摘要：桌面站上，用户手里有鼠标悬停、滚轮、右键、键盘焦点、窗口缩放、开新标签页并排比较这一整套动作。搬到手机上，这套动作被压缩成点一下和滑一下两个。于是桌面上由两个不同动作分别表达的两个意图，在手机上只能挤进同一个手势里，站点被迫替所有人挑一个——被挑掉的那个意图，从此在界面上没有任何一个动作能表达它。它不会变成一条报错，也不会变成一次投诉，只会变成用户去做了别的事，而那件别的事在日志里是一条完全正常的记录。

本文把这套动作差集列成表，给出意图重载点的盘点方法、两类损失的拆分口径，以及一份按投入排序的落地清单。

手机上那一下点击，你的页面到底收到了什么？

四条记录，每一条都健康。可用户真正想说的那句话，一个字都没传过来。

先说一个很小的场景。有人在手机上打开你的分类菜单，看到一行写着“钓竿”，右边还有一个朝下的小箭头。他想看这个大类下面全部的竿子，于是抬手点了那一行。菜单展开了，露出七个子分类：路亚竿、矶钓竿、海竿、溪流竿……他要的那个“全部”，不在这七个里面。

他没有报错，页面也没有卡。他只是往回退了一步，又点开搜索框，输入了“rod”。

这一整段过程，在你的埋点里长这样：菜单被打开一次，菜单项被点击一次，返回一次，站内搜索被使用一次。四条记录，每一条都健康。

问题不在那一行字上，在他手里只有一个动作

如果这件事发生在桌面站上，它根本不会发生。桌面上，鼠标移到“钓竿”两个字上面，子分类会自己浮出来，用户不用点任何东西就看完了七个选项；确认里面没有自己要的，他再把鼠标挪到“钓竿”三个字上单击，就进了大类列表页。悬停和单击，是两个完全不同的动作，分别表达了两个完全不同的意图：我先看看下面有什么，和我要进这一层。

到了手机上，悬停这个动作没了。剩下的只有一个“点”。而“点”要同时表达“看看下面有什么”和“我要进这一层”这两件事。你的菜单必须替全站所有用户选一个——绝大多数站选了前者，于是后者被挤了出去。

被挤出去的那个意图，不会在任何地方留下痕迹。它不产生错误码，不触发告警，不进漏斗的任何一环。它只是变成了一次返回、一次搜索、或者一次关掉页面。

这篇文章要谈的和不谈的

移动端这个话题太大，容易一路谈成大杂烩，所以先把边界划清楚。

• 不谈移动端的搜索引擎优化。移动优先索引、移动友好检测、核心网页指标这套东西，是另一条线上的事，已经在移动端SEO十大致命错误里拆过，本文一个字都不碰排名。
• 不谈性能。低端机、弱网、首屏时间这些，走的是弱网低端机的性能优化那条路，和本文说的动作数量是两回事——一个页面可以快得飞起，同时让用户表达不出自己想干什么。
• 不谈报错文案怎么写。校验失败时该说什么、怎么按子规则分档，自适应报错文案那一篇已经写透了，本文只关心报错之前那一步。
• 不谈筛选器的状态展示。已应用筛选该怎么在列表上方摊开，这一篇讲得比我细，本文不重复。
• 不谈控件选型。下拉框还是单选按钮、要不要用原生控件，下拉框那一篇是专门的，本文谈的是同一个控件上挂了几个意图。

剩下的那件事，才是本文的主题：用户手里可用的动作变少了，而你的界面还是按动作充裕的那套逻辑设计的。

触屏上没有点击这回事，只有接触

大规模的移动端可用性测试里，有一条观察被反复记录：用户经常会误触。而误触发生的时机很有意思——不是手抖，是他们正在用手指辅助阅读（顺着一行字往下划）、正在换个姿势握住手机、或者正打算滚动、刚滚动完。

把这几种情形排一排，会发现一件事：在手机上，同一根手指同时承担了阅读辅助、握持、滚动、点击这四种角色。而在桌面上，这四件事分给了四个不同的执行者——眼睛负责读，手掌负责扶，滚轮负责滚，左键负责点。滚轮的动作永远不会被误判成一次点击，因为它物理上就是另一个零件。

永久原语一：在触屏上，你的界面收到的不是“用户点了这里”，是“有一次接触落在了这里”。把接触翻译成意图这一步，是设备替你猜的，而它没有告诉你它的置信度。桌面端的输入设备天然携带角色标签，触屏上的每一次接触，系统都得猜一次。

这句话听起来有点玄，但它有非常具体的后果：你的转化漏斗里每一个“点击”事件，在移动端都是一个猜测结果，而不是一个观测结果。你拿它去算按钮的点击率、去做A/B测试的判定、去给两个位次排名——都是拿一堆猜测在算加减法。

先把两边手里有什么，老老实实列一遍

这件事最省力的开头，是列一张动作对照表。不谈设计，不谈版式，只列“用户能做出哪些不同的动作”。

这张表最值得盯的是最后一行。前面九行讲的都是移动端少了什么，只有这一行讲的是移动端多了什么——而多出来的这一个，恰恰是唯一一个不需要任何人按下去就会发生的动作。

永久原语二：桌面端有一批“零动作信息”——常驻的主导航、一直在的滚动条、悬停浮出的预览、光标形状的变化。它们不消耗用户任何一个动作，所以从来没有人把它们写进过功能清单；移动端把它们全删了，而删掉的东西不在任何一份需求文档里，因为它们从来不是被做出来的，是平台白送的。

白送的东西被收回时，没有人会发通知。这就是为什么移动端改版的评审会上，讨论的永远是“这个模块放哪儿”“字号要不要再大点”，而不是“用户现在还剩几个动作可用”。

评审会在27寸显示器上开，用户在等地铁

还有一件事值得单独拎出来说，因为它解释了为什么这类问题能长期存在：做移动端界面的评审，几乎总是在桌面上进行的。

设计稿挂在大屏上，一屏能同时看见三个状态；开发用浏览器的设备模拟器调试，鼠标一划就是悬停，鼠标一点就是精确点击；产品经理在自己机器上把页面缩到手机宽度，然后说了句“看着挺好”。

整个链条上，没有一个人是站着、单手、在晃动的车厢里、用一根拇指、屏幕上还有一半被键盘占着的状态下看这个页面的。

更要命的是浏览器的设备模拟器：它能模拟宽度，能模拟像素密度，能模拟慢网速。但它模拟不了“你手里只有一根手指”这件事——你在模拟器里操作，用的仍然是鼠标，仍然有悬停，仍然能精确点中一个十像素宽的箭头。它把屏幕缩小了，没把你的动作缩小。

所以这套方法的第一条操作要求是硬性的：拿真机，用一只手，别把手机放桌上。这不是仪式感，是因为握持姿势直接决定了拇指够得着屏幕的哪一块——单手握住一部大屏手机，右上角那块区域实际上是够不到的，而很多站把关键入口正好放在那儿。这类“看着无关紧要、真做了却有效”的细节，我在那些被低估的反直觉设计杠杆里聊过一批，本文这条属于同一类：成本极低，但你不换个姿势就永远发现不了。

桌面端白送给你的那几样东西，搬到手机上要花多少钱？

常驻的导航、一直都在的滚动条、悬停浮出的预览。它们从没被写进任何需求文档，因为它们不是被做出来的。

先挑一样最容易被忽略的：主导航。

桌面站上，主导航横在页头，一直都在。用户不需要做任何动作就能看见它，也能顺带看见自己当前在哪一栏底下——那一栏通常有个下划线或者换了个底色。这两件事，都不花用户一个动作。

手机上，主导航被折进了汉堡菜单。想看见它，先付一次点击。而大规模移动端测试里有一条观察特别值得琢磨：不少受试者打开汉堡菜单，压根不是想去别的地方，是想搞清楚自己现在在哪。尤其是那些从站外直接落在商品页上的人——他们对这个站一无所知，打开菜单是为了看一眼这个站的骨架长什么样。

然后他们看到一列平铺的分类名，没有任何一项被标出来。菜单不告诉他此刻站在哪儿。

一个被设计成出发的控件，被用户当成了定位

这是一次典型的意图错配。产品经理心里，汉堡菜单是“去别处”的入口；用户手里，它同时还是“我在哪”的唯一答案——因为桌面上负责回答这个问题的那个常驻横条，已经不在了。

行业里的实现情况相当难看：主导航里高亮当前所在范围这件事，桌面端有三分之二的站不做，移动端这个比例更高，接近全部。而它的实现成本，大概是给当前那一项加个不同的样式。

更麻烦的是，本该分担这个任务的面包屑，在移动端也常常缺席、实现得不一致、或者被截断成“…>钓竿”。于是“我在哪”这个问题，在移动端同时失去了两个答案来源。

需要说清楚的是，面包屑本身怎么做、要不要上结构化数据、四种类型分别管什么，那是面包屑导航SEO那一篇的事。本文只关心一件事：当用户手里能用的动作变少之后，原本由零成本渠道传递的信息，现在由谁传递、要付几个动作。

免费的边界信号：滚动条

桌面上还有一样东西是白送的，白送到没人会把它写进需求文档——滚动条。

它一直在那儿，宽度告诉你内容有多长，位置告诉你你在哪一段。你不用做任何动作，它自己就把“还有多少没看”这个信息推到你眼前。

移动端的滚动条是瞬时的：你滑动的时候它闪一下，停下就淡出。绝大多数时候，屏幕上没有任何东西告诉用户“这一排右边还有”。

这件事在视觉驱动的品类上代价特别大。列表项里那排颜色色卡，如果只露出四个、剩下的藏在横向滚动区里，会有相当一部分用户默认这四个就是全部——他们不是懒得滑，是不知道这里可以滑。行业里，把全部色卡都放进移动端列表项这件事，超过一半的站没做到。

顺带说一句，“+7”这种角标看着是个解法，但测试里被快速扫列表的人成片地漏掉。它是个字符，不是个动作提示；用户的眼睛在滚动时是按块扫的，两个字符宽的东西进不了他的注意力。

并排比较：这一样在手机上基本被判了死刑

桌面用户有一个几乎不花钱的动作：开两个标签页，或者把两个窗口拖成左右两半，然后来回看。

手机上，这个动作实际上不存在。分屏在多数机型上要走系统手势、成功率低、而且两个半屏都太窄，实际没人这么用。

所以在移动端，任何需要“把两块信息对着看”的判断，最后都只剩一条路：把上一块压缩成记忆，带着它去看下一块。

这里要和另一件事划清界限。横向标签页那一篇谈的是同一个页面内部的容器几何——两块信息都在页上，但容器规定了一次只能亮一块。本文谈的是另一层：用户手里少了“同时打开两个窗口”这个动作，所以连“把两个页面并排”这个逃生通道也一起没了。前者是容器问题，后者是动作问题；一个站可以把标签页全拆成常驻区块，仍然解决不了跨页面对照。

把白送的东西折算成动作，账就清楚了

把上面几样列进一张表，用“要花几个动作”当单位重新算一遍，会得到一张挺刺眼的账单。

最后一列是这张表的重点。凡是写着“没有人承载”或者“只能靠记忆”的行，都是一次静默的降级——它不会触发任何监控，因为它降的是用户的能力，不是你的服务。

我见过一种很常见的反驳：用户不是都习惯了吗？这话半对。用户确实习惯了，代价是他们把标准降低了——他们不再指望在手机上把事情弄清楚，而是“差不多就下单，不对再退”。这个降级的成本不在转化率上，在退货率上、在售前咨询量上、在复购上，也就是说，它落在了另外三张表里。

返回键：移动端唯一多出来的免费动作，也是唯一你管不了的

说了半天减法，得公平一点：移动端确实白送了一样东西回来，就是系统级的返回。安卓有手势或者实体返回，苹果有边缘侧滑，用户几乎不用瞄准就能触发。

这是移动端唯一一个比桌面还便宜的动作——桌面上的浏览器后退按钮在屏幕左上角，得把鼠标挪过去。

问题在于，它便宜得过头，而且完全不归你管。

• 它不知道你的页面状态。用户在一个列表页上滚了三屏、点开了筛选面板、又展开了一个手风琴，然后返回一下——他期待的是回到刚才那个状态，实际拿到的往往是回到页面顶部，筛选全丢。
• 它会一次退掉太多。如果你的筛选面板、图片浏览层、加购成功弹层都没有各自的历史记录，用户在弹层里按一次返回，直接离开了整个列表页。
• 它让“退出去看看”这个动作的成本变得极低，低到用户会用它来替代思考。这就是为什么移动端的会话页面数比桌面高，却不代表参与度更好——很多时候那只是同一批人在反复进出。

这件事的处理原则很简单：凡是你在页面里制造的“层”，都应该在历史记录里留一格。筛选面板打开算一格，图片全屏浏览算一格，商品快速预览算一格。这样返回键退掉的是那一层，而不是整个页面。

这一条的收益不容易在转化率上直接看到，但它对埋点口径的影响很大：没有分层的历史记录，你在数据里看到的“页面浏览”和用户实际经历的“屏”根本对不上号，后面所有基于页面数的判断都会歪。

同一套内容，在两种设备上不是同一份信息架构

有一个说法流传很广：移动端和桌面端应该是同一套内容、同一套结构，只是排版不同。这话在内容层面成立，在结构层面不成立。

原因还是动作。一套目录结构好不好用，取决于用户在里面移动的成本；而移动的成本在两种设备上差着好几倍。桌面上多一层几乎不要钱，因为悬停能让人在不进入的情况下把整层看完；移动端多一层就是实打实多一次点击，而且是一次带着不确定性的点击。

所以同一份目录，在桌面上可能是合适的深度，在移动端就偏深了。站点架构该扁平还是该深这个老问题，通常是从抓取效率的角度讨论的，但它在体验这一侧有一个完全独立的理由，而且两侧的结论碰巧一致。

几个连带的地方也一样：

• 中间分类页。桌面上它是个方便的落脚点，移动端它常常变成一层纯粹的过路费——用户想要的是商品，得到的是又一屏分类入口。
• 分页。分类页分页怎么做在桌面上有很多种选择，移动端实际能用的只有无限滚动和加载更多两类，而这两类都会破坏返回后的位置恢复。
• 集合页的组织方式。同一批商品，桌面上可以靠左侧栏承载一整套维度，移动端要把这些维度折起来，折的顺序就是一次隐含的取舍。类目页的机制那一篇讲的是它凭什么被单独收录，本文关心的是它在小屏上还剩几个可用的入口。
• 筛选产生的地址。移动端用户在筛选面板里点得更随意，产生的组合更多，分面导航的抓取治理这条线上的压力，某种程度上也是动作成本变化带来的。

结论不是要给移动端单做一套目录——那维护成本太高，也会让两边的口径长期分家。结论是：定目录深度的时候，用移动端的移动成本当尺子，而不是桌面端的。因为桌面端能承受的，移动端不一定；反过来，移动端能承受的，桌面端一定能。

为什么规范专门造了一个语法，用来问能不能悬停？

两份出自不同工作组、服务不同目的的文件，在描述同一个麻烦时，收敛到了同一个词。

上面这些话，听起来像是体验设计里的主观判断。其实不是。把“用户手里有哪些动作”当成一项需要单独查询的设备能力，这件事早就被写进了万维网联盟的规范正文里。

媒体查询规范第四版有专门的一章，叫交互媒体特性。里面定义了四个东西：pointer、hover，以及它们的“任意设备”版本any-pointer和any-hover。

换句话说，层叠样式表专门造了一个语法，让你可以问一句：这台设备上，用户能不能悬停。

规范怎么定义粗指针，比你想的严格得多

pointer这个特性有三个取值：none（主输入方式里根本没有指点设备）、coarse（有，但精度有限）、fine（有，且精确）。

关键在coarse的定义原文。规范说的不是“手指比较粗”，而是这样一句：如果用某个指点设备，在缩放系数为1的情况下，很难或者根本不可能可靠地从几个相邻的小目标中挑中一个，那它就算粗指针。

把这句话和前面那个钓竿菜单摆在一起看。那一行里有两个热区：文字那块是“进入大类列表”，右边小箭头是“展开子类”。它们相邻，它们都小。规范里定义粗指针的那句话，几乎就是照着这个界面写的。

规范后面还跟了一句给作者的要求，措辞是“预期作者应当针对coarse这个取值做出反应，把页面设计成不依赖精确点击就能操作”。这不是建议某个视觉风格，是要求你重新考虑交互的组织方式。

能做，但不是常规用法，规范直接判定为没有

hover只有两个取值：none和hover。而none的定义里藏着本文最想引用的一句话。

规范原文的意思是：那些能够悬停、但悬停对它们来说很不方便、并且不属于它们正常使用方式的指点设备，同样匹配hover: none。规范还专门举了例子——一块把长按当作悬停来处理的触摸屏，匹配的是hover: none。

这句话的分量得掂一掂。技术上，触屏是能模拟悬停的，长按就行。但规范不认。规范的判据不是“理论上做不做得到”，是“它是不是这台设备上的常规用法”。

永久原语三：一个动作能不能算数，看的不是用户理论上能不能做出来，而是它是不是这台设备上的常规用法。凡是要靠“用户可以长按”“用户可以横着滑”“用户可以捏合放大”来兜底的设计，在规范眼里，那个动作等于不存在。

顺带说一句，规范里给@media (hover)配的那个代码示例，注释写的是“只在能方便悬停的设备上使用悬停触发的下拉菜单”。规范自己举的例子，就是导航菜单。

同一台电脑，可以对不同的人报出不同的答案

还有一条更值得琢磨的规定。规范说：出于无障碍方面的考虑，即便一台设备的指点设备完全够得上fine，用户代理也可以给出coarse甚至none，用来表示这位用户在精确操作上有困难。同理，即便设备支持悬停，也可以主动报hover: none，好让页面切到不依赖悬停的那套版式。

这条规定把这个媒体特性的性质彻底讲明白了：它问的不是这台设备是什么，是坐在这台设备前面的这个人此刻能做出哪些动作。

拿它跟屏幕宽度对比一下，差别就很刺眼了。宽度是一个物理量，一台设备永远报同一个数，跟用的人是谁毫无关系。

尺子：你的媒体查询问的是屏幕有多宽，从来没问过用户手里有几个动作。而这两个问题的答案并不相关——一台横过来的平板，宽度足够宽，悬停能力却是零。

这也是为什么“响应式做完了”这句话经常什么都不代表。绝大多数响应式改版的断点全部建立在宽度上，那意味着整套适配逻辑从头到尾只回答了一个问题：屏幕多宽。至于用户手里少了哪些动作，代码里没有任何一处问过。

两份规范在同一个词上撞到了一起

现在把另一份文件摆过来：无障碍指南第2.2版的成功准则2.5.8，目标尺寸（最小值），级别是AA。

它要求指针输入的目标尺寸至少达到24×24 CSS像素，并列了五条例外——间距足够、同页有等效控件、行内目标、尺寸由用户代理决定且作者未改、以及呈现方式本身是必需的或法律要求的。

它的意图声明写得很直白：确保目标能够被轻松激活，而不会意外激活相邻的目标。

停一下。前面那份规范定义粗指针，用的判据是“难以从几个相邻的小目标中挑中一个”；这份规范定义最小命中区，用的判据是“不会意外激活相邻的目标”。

两份文件出自不同的工作组，服务的目的也不同——一份是给样式表用的能力查询，一份是给无障碍合规用的验收准则。它们在描述同一个麻烦时，收敛到了同一个词：相邻。当两条互不相干的推理路径落在同一个词上，通常说明那个词指向的是问题的本体，而不是某一方的表述习惯。

这条准则顺手给了你一个免费的排查入口

2.5.8有个很实用的副作用：它把“两个意图挤在一行里，靠一大一小两个热区区分”这件事，从体验建议变成了可验收项。

那个只有十几像素宽的小箭头，如果它旁边紧挨着另一个可点击的目标，间距也不够，那它就是一条AA级的不合规项——不需要你去论证用户体验，直接量尺寸就行。

更妙的是那条叫“等效”的例外：如果同一页面上有另一个符合尺寸要求的控件能完成同样的功能，就算过。这条例外反过来正好是本文要的解法：与其把那个小箭头做大，不如给被挤掉的那个意图配一个够大的、独立的入口。合规和体验在这里指向同一个动作，这种时候不多，遇上了就别浪费。

三行代码，比再开一次评审会管用

既然规范给了这个语法，那就用起来。实际写法非常朴素：

• 只在能方便悬停的设备上启用悬停触发的交互。用悬停能力做条件，而不是用屏幕宽度。一台接了鼠标的平板宽度可能只有八百多，但它的悬停能力是完整的；一台横过来的大屏手机宽度可能过千，悬停能力却是零。
• 指点精度为粗时，把命中区放大。规范文档里自己给的示例就是这个——检测到粗指针，就把复选框和单选按钮的最小尺寸调上去。这一条尤其适合处理那些“设计稿上看着很精致”的密集控件。
• 查询所有可用设备而不只是主设备。规范建议作者认真考虑用查询全部指点设备的那两个特性，因为一台触屏笔记本的主输入方式可能被判定成触屏，但它同时还接着一个鼠标。

这三条加起来的代码量，大概比一次评审会的会议纪要还短。它们不解决全部问题——最难的那部分是信息架构，不是样式——但它们能把一大类“在我电脑上明明好好的”问题一次性挡掉。

还有一个常被忽略的搭配：颜色对比度。移动端的使用场景包含大量强光环境，而设计稿是在室内屏幕上评审的。当前范围高亮如果只靠一个浅灰底色，在阳光下等于没有。这类问题拿对比度换算工具量一下就有结论，比争论好看不好看快得多。

顺带一提，无障碍这条线上的很多要求，本质上都在做同一件事：假设用户手里的动作比你以为的更少。这也是为什么按无障碍标准做完的界面，通常对健全用户在颠簸车厢里的体验也更友好——两拨人面对的是同一个问题，只是原因不同。

一个手势要同时表达展开和进入，你的站替用户选了哪一个？

选完之后，另一个意图并没有去别处。它被留在了原地，而且不会有人替它投诉。

回到开头那个钓竿菜单。现在可以把它的机制说透了。

桌面站上，主分类这一项挂着两个动作：悬停展开子类，单击进入该类的列表页。两个动作，两个意图，各走各的，谁也不挡谁。

移动端只剩一个“点”。于是每个站都必须做一个二选一的决定：用户点主分类，是展开它下面的子类，还是直接带他去这个大类的商品列表？

行业里的实际选择高度一致：绝大多数站选了“继续下钻”。用户一层一层点下去，只有当某一层再也没有子分类可展开时，才终于落到一个商品列表上。

选了下钻，另一个意图去哪儿了

它没去哪儿。它被留在原地了。

大规模移动端测试里能反复看到两种人卡住：一种是想要最宽的那个范围的——“所有男鞋”“所有背包”“所有钓竿”，他不知道自己要哪个子类，他要的就是全部；另一种是一路点得太深，掉进了一个又窄又偏的子分类里出不来的。

行业不达标比例在四成上下：这么多移动站，在商品目录的各个层级上没有提供“查看全部”这个选项。而把它在每一级都做对的，只有约四分之一。

有意思的是那些“技术上能做到”的实现。有的站，用户进到某个大类的子分类列表后，点一下顶部那个大类名字，是可以看到全部商品的。功能在，路径通。但测试里几乎没有人想得到要那么做——用户不会假设“想看全部，就去点当前所在这一级的标题”。

功能存在和意图可表达，是两件事。前者写在需求文档里可以打勾，后者要看用户能不能在不被教的情况下想到那个动作。而验收环节通常只验前者，因为后者没法用打勾的方式验。

另一种更糟的实现：把两个意图挤成两个相邻的小热区

还有一类站选择了折中：一行里，点文字进列表，点行末的小箭头展开子类。听着挺聪明，两个意图都留下了。

但这正好撞在前面那两份规范上。同一行里两个相邻的、都不大的热区，一个粗指针要可靠地挑中其中一个，规范认为很困难；无障碍准则则要求它们要么够大，要么彼此间距够开。

测试里的表现也印证了这一点：这种细微的、而且是多个的命中区，会被相当一部分用户直接忽略掉——他们根本没意识到一行里有两个可点的地方。结果是这个设计对懂它的人是好设计，对不懂它的人等于不存在，而后者是大多数。

把重载点列成清单，这件事就能排期了

光讲道理没用，得能数出条数来。意图重载点盘点是本文给的第一个具体动作：拿一部手机，把主要模板走一遍，凡是发现“同一个手势可能被用来表达不止一件事”的地方，就记一行。

每一行记五样：位置、这个手势承载了哪几个意图、你的站选了哪一个、另一个意图现在由什么承载、那个承载物有多大。

这张表的第四列是全表的重点。凡是写着“没有承载物”的，就是一个用户表达不出来的意图；凡是承载物只有十几像素宽的，等价于没有承载物；凡是写着“因站而异”的，用户得靠试，而试错在移动端要付返回的成本。

第一次跑这张表，你大概会数出比预想多一倍的条数

这件事的成本低得不像话：一部手机，半天时间，不需要埋点，不需要等数据，不需要跟谁申请预算。做完你手里就有一张按位置排好的清单。

经验上，第一次跑完的条数通常是团队开会拍脑袋估计的两倍上下。原因不难理解——做这个界面的人，脑子里装着完整的设计意图，他点每一下都知道自己在点什么。这种知识一旦有了就卸不掉，所以自查永远查不出这类问题。能查出来的唯一办法是把它变成一件机械的事：不判断好坏，只数条数。

顺带一提，这张表里有一行的答案格外扎眼——搜索框那行的第四列写着“不在你的页面里”。那不是个玩笑，是HTML标准的正式规定。下一节专门说它。

导航还不是重灾区，结账流程才是

导航上的重载点显眼，是因为它每天被所有人用。但真正代价最高的重载点，往往藏在结账流程里——那里的每一次误解都直接对应金额。

几个常见的：

• 数量框。它承载“改数量”和“删掉这一行”两个意图。多数站只做了前者，删除靠减到零——但减到零在很多实现里会触发一次确认框，也有的直接刷新页面，用户不知道自己刚才做了什么。
• 优惠码输入区。它常常同时是“我有码要填”和“我想看看有没有码”两个意图的入口。后者会让用户离开结账页去别的网站搜码，然后就不一定回来了。
• 配送方式那一组选项。点一下到底是“选中它”还是“展开它的详细说明”，很多站在这里做得不一致——同一页上有的选项点了展开，有的点了直接选中。
• 已保存地址的卡片。点卡片是“用这个地址”还是“编辑这个地址”，这两个意图在移动端经常挤在同一块区域里，而误解的后果是包裹寄到了旧地址。

结账页的特殊之处在于，这里的第二类损失几乎全部会在两周后以物流问题的形式回来，而那时候没有人会把它和一个界面上的歧义联系起来。关于结账页上那些“看着填好了、其实还差一步”的东西，配送时效那一篇拆的是另一个角度，两篇合起来看会更完整。

如果你的站结账放弃率一直下不去，除了常规的那几个成因，值得拿本文这张表把结账流程单独跑一遍——结账放弃的九个真实成因里没有专门讲重载点这一类，因为它不是一个成因，它是一批成因背后的同一个结构。

分类命名的容错度，两种设备差得很远

重载点是结构问题，命名是内容问题，但它们在移动端会互相放大。

道理前面说过：桌面上悬停一下就知道一个陌生词后面是什么，命名差一点也能糊弄过去；移动端弄清楚一个词的唯一办法是点进去，所以命名的每一次含糊都要收一次点击费。

具体到几类容易出事的名字：

• 内部黑话。公司里叫惯了的品类名，未必是用户搜的那个词。这件事在站内搜索词挖掘里能直接看出来——用户在搜索框里打的，往往和你菜单上写的不是一个词。
• 翻译过来的名字。多语言站尤其明显，一个在英文里清楚的分类名，直译成德语或法语之后可能又长又怪。长词在小屏上还会撑破布局，有人为此往标题里塞不可见字符，这个做法带来的麻烦比它解决的更多。
• 被平台锁死的字段。有些建站平台对某些位置的文案改不动，哪些能改哪些锁死要在方案阶段就查清楚，别等到开发说做不了才回头改设计。

还有一条判断标准，简单到可以写进验收清单：把主导航的每一项单独拿出来，问一个从没来过的人，不点进去他能不能说出里面大概有什么。说不出来的，要么换名字，要么在菜单里配一行说明。

配说明这条路的好处是它绕开了改地址的全部麻烦。改名字要动地址、动跳转、动外链，是一件周期以季度计的事；加一行说明只动前端。而它承载的信息，恰恰就是悬停原来承载的那些。这也是为什么本文一直说，移动端补悬停的办法只有一个——把悬停里的东西变成常驻。

搜索框旁边那个提交键，为什么不在你的页面里？

标准用属性的名字承认了这件事——它叫提示，不叫设定。这家供应商你既考核不了，也换不掉。

先说现象。用户在手机上点开搜索框，敲完关键词，然后……卡住了。

他在页面上找不到任何一个写着“搜索”的按钮。答案其实在屏幕下半部分——系统弹出的那块软键盘上，右下角那个键已经变成了“搜索”。但他没往那儿看。

测试记录里，这类人不在少数：他们的注意力锁在网页本身，把系统键盘当成了一块“打字用的地方”，而不是“界面的一部分”。于是提交一次搜索这么基础的动作，能让人绕一大圈、烦躁半天。行业里，移动端搜索框旁边不给提交按钮的站，比例在两成到三成之间。

这事儿的根子不在用户笨。在于那个键，压根就不属于你。

标准把这块地的产权写得清清楚楚

HTML标准里有一个属性叫enterkeyhint，专门用来控制虚拟键盘上回车键呈现成什么样。它有七个取值：enter、done、go、next、previous、search、send。

但真正值得看的是这条属性的名字，和标准里描述它的每一句话的语气。

属性名的后半截是hint——提示。标准里对七个取值的说明，格式是统一的：用户代理应当呈现某个操作的提示。同一段里还写着：当这个属性没有指定、或者处于用户代理不支持的状态时，由用户代理自行决定呈现哪个操作标签。

把这几句话翻译成人话：你能做的，是建议那个键上印什么字。你不能决定它印不印、印成什么样、放在哪个位置，更不能决定用户会不会往那儿看。

它旁边那个inputmode属性也一样——你可以说这个字段适合数字键盘、适合邮箱键盘、适合搜索优化过的键盘，措辞依然是用户代理“应当”显示。整套机制从头到尾是一场协商，不是一道命令。

永久原语四：搜索提交这个动作的控件，产权不在你的页面里。标准用属性名字承认了这一点——它叫提示，不叫设定。凡是一个关键动作的唯一入口落在你控制不了的那块地上，你就等于把这个动作的成败外包给了一家你既不能考核、也不能更换的供应商。

这家供应商的历史成绩，有人替你统计过

触摸键盘的适配质量是有长期观察的。有一份跨越十几年的对比给出的结论相当直白：触摸键盘的实现水平在十几年里只提升了不到一成，而做错的站仍然占六成。

这里说的“做错”，指的是最基础的那些事：数字字段弹出全字母键盘、邮箱字段的键盘上找不到at符号、卡号字段弹出带字母的键盘。

这个数字有点残酷，但它给了一个很实际的判断依据：如果一件事在十几年里只改善了不到一成，那说明它不在任何人的绩效指标上。指望它自己变好是没戏的，你只能自己在页面里补一个。

解法很土，但它是唯一一个产权清楚的解法

在搜索框紧挨着的位置，放一个你自己的提交按钮。就这么简单。

它的价值不在于更快——习惯用键盘回车的人本来就很快。它的价值在于，这个动作从此有了一个你能控制的入口，而不是只有一个你控制不了的入口。两条路并存，用户走哪条都行；只留一条，而那条还不归你管，就是把风险全押在别人身上。

顺便，这个按钮还有个副作用：它让搜索这件事在页面上“看得见”。移动端的搜索框经常被收成一个放大镜图标，点开才展开——一个可见的提交按钮，等于给这条路径又加了一次可见性。至于搜索框本身该怎么设计、结果页怎么组织、零结果怎么兜，那是站内搜索框设计那一篇的范围，本文只谈“提交”这一个动作归谁管。

顺手做对的两件小事

既然标准给了协商的余地，那就把该说的话说全：

• 该配的属性配齐。搜索字段给enterkeyhint=“search”，多步表单中间的字段给next，最后一个给done或send。这是零成本的，配了大概率生效，不配就完全交给对方猜。
• 但绝不把校验建立在它之上。它是提示，不是保证。任何“因为我设了搜索键，所以用户一定会提交”的推理，都是在拿一个不受你控制的环节当前提。

这两件事合起来是一个通用姿势：凡是落在别人地盘上的能力，配置它，但不要依赖它。下一节要讲的那个动作更极端——它不但不归你管，而且根本不是用户发起的。

键盘弹出来的那一刻，你的页面少了一半

还有一件跟这个键盘有关、但方向完全不同的事：它一弹出来，就吃掉了屏幕的下半部分。

这件事的后果比想象中大：

• 提交按钮被压在键盘下面。用户填完最后一个字段，抬头找按钮，找不到——他得先收起键盘。而收起键盘这个动作本身在很多机型上要点屏幕空白处，而屏幕空白处可能又是别的可点元素。
• 报错信息出现在看不见的地方。字段在上，报错在下，键盘在更下——三者能同屏的情况并不多。
• 粘在底部的那个按钮会跟着键盘往上跳。这是布局偏移最常见的来源之一，而偏移的直接后果就是误触：用户瞄准的是甲，跳完之后手指落在了乙上。布局偏移那一篇讲的是它对指标和体验的影响，本文关心的是它制造的那一类误触——它是第二类损失的一个纯技术来源。

处理办法都不新鲜：表单字段获得焦点时把它滚进可视区的上半部分；提交按钮不要粘在底部，或者粘的时候要处理好键盘弹出的重排；报错信息放在字段上方而不是下方。

但这些事情之所以经常没做，还是因为前面那句话——评审的时候没有人真的在手机上填过那个表单。设计稿上不会画出键盘，所以设计稿上的那个页面永远是完整的。

用户没按下去、设备自己按下去的那个动作

整张动作表上唯一一个反方向的条目。规范对它的措辞是绝不可以，而且替三类字段单独挡了子弹。

前面那张动作对照表的最后一行，写的是自动更正。它是整张表上唯一一个反方向的条目：移动端不是少了它，是多了它。

而它的特别之处在于，这是唯一一个不需要任何人按下去就会发生的动作。用户没发起它，你也没调用它，它自己就把用户敲进去的字改了。

标准对这件事的态度，比多数人想的强硬

HTML标准里有一个autocapitalize属性，用来控制自动首字母大写的行为。标准在介绍它的时候提到了一个前提：某些输入法会以一种不给用户先行干预机会的方式施加大写。这个属性的存在，就是为了让作者能对这种行为说点什么。

然后是关键的那一句。标准明确写道：由于这个属性在物理键盘上通常不起作用，加上用户在某些情况下可以覆盖自动大写行为、也可以在输入后自行编辑文本，因此这个属性绝不可以被当作任何形式的输入校验的依据。

请注意那个措辞的强度。这不是“建议不要”，是标准正文里的禁止性表述。翻译过来就是：你在移动端收到的那串字符，中间经过了一个你控制不了、也不允许假设的环节。

标准替三类字段挡了子弹，而收货地址不在名单上

同一段规范里还有一条容易被划过去的规定：当输入框的类型是网址、邮箱或密码时，这个属性永远不会启用自动大写。

停下来想想这份名单的逻辑。为什么是这三个？因为它们都是格式严格、且一个字符错了就整体失效的字段。标准的制定者认为，这三类字段被自动大写改坏的风险高到值得单独豁免。

然后看看谁不在名单上：收货地址。

永久原语五：收货地址是一个既有严格格式、又长得像自然语言的字段。它的格式严格程度接近邮箱，外形却接近一句普通的话——于是自动更正把它当成了后者，你的校验把它当成了前者，两边的坑它同时踩上。

这也解释了一个长期存在的观察：移动端用户填地址时出错的频率，比桌面端高出一大截。原因是三重的——键盘小、拇指粗、自动更正在旁边帮倒忙；而屏幕又太窄，用户看不到整块地址的全貌，于是错了也不容易发现。

你把地址切成五个字段的那一刻，也堵死了唯一一条低成本路径

这里要引一份和电商无关的资料。英国政府的设计系统里，有一个专门讲“向用户索取地址”的模式页。它列出了多个文本框方案的优点，也老老实实列了缺点，其中一条是：用户无法轻松地从剪贴板粘贴地址。

同一页还有一句更狠的：没有任何保证说用户会按照你设想的方式使用这些输入框。

把“无法轻松粘贴”这条放到本文的框架里看，分量就出来了。粘贴在桌面上是一个快捷键，一个动作，零思考。在手机上，它是长按、等系统菜单弹出、再点选粘贴——三个动作。而“长按”这个动作，前面已经说过，规范明确把它归进了“不属于常规使用方式”那一类。

换句话说：用户手里本来有一条低成本路径，就是从记事本或者别的订单里整块复制过来。你把地址切成了五个框，这条路径就废了——因为整块内容没法拆着粘。他只能一个框一个框地重新敲，而每敲一个框，自动更正就有一次机会插手。

地址校验器：一件被半数站省掉的事

行业观察里，超过半数的移动站没有地址校验或地址查找功能。用户填了错的地址，页面照样放行，一路走到下单成功。

这件事的代价不落在结账页上。它落在两周之后：包裹派送失败、客服工时、二次运费、退回入库、以及一条写着“东西根本没到”的差评。转化率报表上，这一单是漂亮的成功；成本落在物流和客服的账上，中间隔着两周和三个部门。

校验器不复杂：拿用户输入的地址去比对邮政数据，能不能对上。它当然不完美，但它抓的是本文最关心的那一类错误——不是用户不知道自己家在哪，是这一路上有个东西替他改了几个字符，而他没机会先看一眼。

• 能上校验器就上。这是唯一一个能在提交前把“设备替用户做的那个动作”抓回来的环节。
• 给地址相关字段配好自动填充用途。浏览器知道用户以前填过什么，让它整块填回来，比让用户在小键盘上重打十遍强。
• 但不要把校验逻辑建立在“用户会规规矩矩填”这个假设上。标准和政府设计系统在这一点上说的是同一句话，只是措辞不同。

自动填充是同一枚硬币的另一面

自动更正是设备替用户改字，自动填充是设备替用户打字。同一类东西，一个添乱，一个帮忙——区别只在于你有没有把接口对好。

浏览器手里有用户以前填过的地址、电话、邮箱。它愿意整块填回来，条件是你得告诉它每个框装的是什么。这件事有一套标准化的取值，姓、名、地址第一行、城市、邮编，各有各的写法。

这里有个值得注意的细节：英国政府那套设计系统在讲这件事的时候，特意提到在正式环境里这么做还是满足无障碍标准里那条识别输入用途的要求的必要条件。也就是说，配好这些属性不只是让用户少打几个字，它同时是一条合规项。

一个字段配对了，用户零动作就填完；配错或者没配，他要在小键盘上敲二十来个字符，而自动更正在旁边随时准备插手。这两种情况之间的差距，在桌面端不算大，在移动端是决定性的。

还有一条经验：不要为了自己后台好处理，把地址切得比必要的更碎。每多一个框，就多一次自动更正的机会，多一次跳字段的动作，也多一次用户放弃的可能。跨境场景下这一点更明显——不同国家的地址结构差别很大，硬套一套五个框的模板，总会有一批用户填不进去。降低退货率这件事，很多人的注意力全在尺码和产品图上，其实派送失败这一类的占比往往被低估了，而它的源头就在这几个框里。

表单之外，还有几个地方是设备替用户做的决定

自动更正只是最显眼的那个。移动端还有几个环节，同样不由用户发起，同样会改变他看到的东西。

• 按位置自动切换语言或币种。用户人在德国出差、账号和收货地址都在英国，站点按网络位置把他切到德语版。这件事对体验的伤害已经够大，按IP自动跳转的另一重代价是它会让相当一部分页面进不了索引，两头都亏。
• 同意管理弹窗。它是合规必需品，但它出现的时机、占屏比例、以及关闭方式，在移动端和桌面端差别巨大。同意管理平台怎么选这件事通常由法务和技术决定，很少有人从小屏体验的角度参与意见，结果就是一块占掉半屏、按钮还挤在一起的东西。
• 各种自动弹出的营销层。邮件订阅弹窗在桌面上是个小方块，在手机上常常是全屏。弹窗的时机与字段设计有专门的讲究，这里只补一句和本文相关的：全屏弹层的关闭按钮如果只有十几像素，它同时踩中了前面说的所有坑——命中区太小、位置在拇指够不着的角落、而且没有第二条退出路径。
• 浏览器的省流或阅读模式。它会重排你的页面，把某些元素直接扔掉。你控制不了它，但你可以确保关键信息不只存在于被它扔掉的那类元素里。

这几件事的共同点是：它们都发生在用户和你的页面之间，都不由用户发起，而且都不会在你的日志里留下“这里发生了一次改动”的记录。你能做的，是在设计的时候假设它们都会发生，而不是假设它们都不会。

横着滚的那一排，用户凭什么知道后面还有？

三种边界信号，效力差着量级。差别不在显眼程度上，在它跟那个动作是不是同一类东西。

横向滚动区是移动端一个非常特别的容器。它几乎是小屏上唯一一个能装下任意多内容的地方——只要用户愿意一直滑，色卡可以有三十个，尺码可以有二十档，谁也不挤谁。

代价是：它默认不告诉任何人自己有多长。

用户不是懒得滑，是不知道这里能滑

视觉驱动的品类上，这件事的账很好算。一件商品有十一个颜色，列表项里只露出四个，剩下七个躺在滚动区右边看不见的地方。

测试里能观察到两种人：一种飞快扫过列表，把露出来的四个当成了全部；另一种意识到可能还有，但要确认就得点进商品页——而他这一趟点进去，可能只是为了确认“没有我要的颜色”，然后退出来。

行业里，把全部色卡放进移动端列表项这件事，超过一半的站没做到，在某些品类上比例更高。而这件事的后果不是“用户少看了几个颜色”，是他基于一份不完整的清单，得出了一个“这家没有我要的”的结论，而且他相信这个结论。

三种边界信号，效力差得很远

解决这件事的办法都不新鲜，但它们的效力不在一个量级上。

为什么差这么多？我的判断是这样的：

永久原语六：一个提示要起作用，它必须和它提示的那个动作落在同一个感知通道上。横向滚动是一个空间动作，所以有效的提示必须是空间的——半个色卡露在边缘、一个指向右侧的箭头。而“+7”是文字，它跨了通道，得先被阅读、被理解、再被翻译成“那我滑一下试试”，这条链子在快速扫视里断得干干净净。

这条判据的用处不止于色卡。任何时候你想用一行小字去提示一个手势，都可以先问一句：这个提示和这个动作，是不是同一类东西？答案通常是否定的，而这就是那些“我们明明写了啊”的功能没人用的原因。

要和另一件事划开：横向标签页那一篇谈过文本被截断时要留信号，那说的是一段文字被省略号砍断、用户不知道后面还有多少字。本文这一节谈的是一个空间容器的长度未知，判据也不同——那边的判据是“用户能不能知道内容被砍了”，这边的判据是“提示和动作在不在同一个感知通道上”。

手势本身也是一次赌博

同一个逻辑往前推一步，就到了手势。

商品图的放大就是典型例子。行业观察里，相当比例的站不支持在商品图上做捏合放大或者双击放大——大约四成。而这类站通常的辩解是“我们有专门的放大按钮”。

问题在于，用户手里的习惯不是你的界面教的，是他每天用手机养成的。看到一张图想看细节，他的手指会自己做出捏合这个动作，这是肌肉记忆，不经过判断。捏合没反应的那一瞬间，他得到的结论不是“这个站要点按钮”，而是“这张图就这样了”。

反过来说，凡是你打算用手势承载的功能，都得默认有一部分人不会做出那个手势。手势可以是加速通道，不能是唯一通道。这话和前面说搜索提交按钮时的姿势是一样的：给一条你控制得住的明路，再给一条快的暗路。

默认露出来的那几个，选法有讲究

还有个细节值得单独说。既然横滚区只能露出前几个，那露哪几个就是一个真实的决策，不是随机。

• 要么选差异最大的几个。让用户一眼看出这条产品线的色彩跨度——露出黑白灰三个近似色，用户会以为这个款只有素色。
• 要么选卖得最好的几个。命中率最高，代价是长尾颜色更藏得深。
• 不要按后台录入顺序露。这是最常见的实现，也是最没有道理的一种——它露出来的那几个，唯一的共同点是被谁先录进系统的。

顺带说一句，这一节讲的所有事情，本质上都在做同一件事：把一个只有靠试探才能发现的东西，变成一个不用试探就能看见的东西。试探这个动作在桌面上几乎免费（鼠标划过去就行），在移动端要付出真实的代价——所以移动端界面的信息密度可以低，但确定性必须高。

粘性元素：另一个被空间信号坑掉的地方

横滚区的问题是“不知道右边还有”，粘性元素的问题正好相反：用户知道它在，但不知道它盖住了什么。

移动端常见的粘性元素有三层：顶部的精简页头、底部的加购条、还有各种促销横幅和同意管理弹窗。它们各自都有理由，加起来能吃掉屏幕的三分之一。

被盖住的东西里，最容易出事的是这几样：

• 锚点跳转的落点。用户点了页内目录跳到某一节，结果那一节的标题正好被粘性页头盖住，他看到的是第二段。
• 表单的最后一个字段。被底部粘条盖住，用户以为表单到此为止。
• 页脚里的政策链接。退换政策、尺码说明这类东西经常只在页脚有入口，而页脚常年被底部粘条压着一截。页脚该怎么设计是另一个话题，但至少得保证它能被完整看到。

还有一个更隐蔽的：粘性元素会让“我滚到底了吗”这个判断失效。桌面上滚动条到底了就是到底了，移动端没有滚动条，用户判断到底的依据是“页脚出现了”——而页脚被盖住半截时，这个信号也是含糊的。

处理原则和前面一致：每加一个粘性元素，就问一句它盖住了什么，以及被盖住的那样东西还有没有第二个入口。大多数情况下答案是没有，那这个粘性元素就得重新考虑。同意管理弹窗尤其值得单独看一眼，它在跨境站上是必需品，但它的默认样式经常是按桌面设计的，搬到手机上能占掉半屏。

图片这一块，移动端的信息损失最容易被低估

视觉驱动的品类上，图片承载的信息量常常超过文字。而移动端在图片这一环节的损失，是复合型的。

• 尺寸。一张在桌面上占半屏的细节图，在手机上只有拇指那么大，纹理、做工、材质这些东西直接丢了。这就是为什么放大手势不能可有可无。
• 数量。桌面上一排缩略图能同时看见八张，移动端能看见的通常是一张加半张。用户要知道总共有几张，靠的又是那个空间信号。
• 加载。压得太狠，细节没了；压得不够，弱网用户看到的是一片灰。图片压缩这件事的反直觉之处在于，画质拉满反而可能更小，凭感觉调参数经常适得其反。
• 替代文本。图没加载出来的时候，替代文本是唯一还在的信息。它在移动端的价值比桌面高，因为移动端图加载失败的概率更高。批量体检替代文本顺带能查出尺寸属性缺失，而那正是布局偏移的主要来源。

还有一件正在变得更重要的事：用户开始拿图去搜东西了。拍一张、圈一块、找同款，这套动作在手机上比在桌面上自然得多——它甚至是移动端少有的、比桌面端更强的能力。视觉搜索这条入口对出海品类的意义还在涨，而它依赖的正是你放在页面上的那些图。

顺带说一句价格区域。划掉的原价、每单位价格这类信息在小屏上经常被挤成一行小字，而它们各自都有独立的合规要求——划线价要拿自己的价格历史证明，每单位价格的分母有明确规定。挤成小字不会让这些要求消失，只会让用户看不见。

表达不出来和表达错了，这两类损失怎么分开量？

一类在日志里是一段路径异常，另一类在日志里是一次顺顺利利的会话。四个数今天就能开始收。

到这一步，得把损失拆开了。因为这两类损失的成因、可观测性、以及修起来的难度，完全不在一个量级。

永久原语七：第一类损失会让用户当场去做别的事，第二类损失会让用户带着一个错误的结论继续往下走。前者在日志里是一段路径异常，后者在日志里是一次顺利的会话——而后者的账，两周后在退货或者客服那边结。

这里要和另一件事分清楚。列表项静默否决那一篇谈的是“事件压根不产生记录”——用户扫完一整屏什么都没点，系统那儿一片空白。本文这两类损失都是产生记录的：第一类产生的是一条语义被误解的正常记录，第二类产生的是一条彻底正确的成功记录。空白和误解，排查方法完全不同。

误触是第二类损失最容易观察的入口

关于触屏上的误触，有一份整理得很清楚的分类，把处理策略分成三种，各有各的代价。

• 认了。什么都不做，误触就误触。对非关键、且需要频繁重复的动作，这是合理的；对删除、发送、支付这类动作，一次误触的严重度高到无法接受。
• 要求用户表明意图。弹确认框、要求长按、加一道二次确认。它确实能挡住真正的误触，代价是所有人都要多付一次成本，包括那些本来就想这么做的绝大多数人。而且它挡不住走神的人——处在自动驾驶状态的用户，会顺手把确认框也点掉。
• 允许撤销。让用户事后能反悔、能改。它的好处是不给任何人加摩擦，只给倒霉的那少数人一条退路；坏处是实现起来最麻烦，尤其是牵涉到已经写进库的状态。

这三条摆在一起，选择的本质就露出来了：你是在“给全体用户加成本”和“给少数倒霉蛋加成本”之间选。确认框选的是前者，撤销选的是后者。而移动端因为误触本来就多，前者的总成本比在桌面端高得多——因为你要乘的那个基数是所有人。

四个能今天就开始收的数

这件事最难的地方在于，前面讲的全是机制，机制没法排期。所以得有几个数把它变成可跟踪的东西。这四个数都不需要新建埋点体系，用现有的东西拼一下就有。

• 指标一：意图重载点密度。拿前面那张盘点表，除以该模板上主要可点元素的总数。它不是用来跟同行比的，是用来跟自己上个季度比的——它唯一的用途是防止这个数在一次次迭代里悄悄涨回去。
• 指标二：被压掉那一侧的替代路径长度。用户想表达被挑掉的那个意图，最短要做几个动作（含返回）。零是理想，一到二是可接受，三以上基本等于没有。这个数是手工量的，一个模板几分钟。
• 指标三：短命会话页。进入某个页面后一点五秒内就触发返回的比例。这是误触和“点错了”的最好代理——真正想看这一页的人，不会在一点五秒内决定离开。按页面模板切开看，高得离谱的那几个模板，多半就是重载点密集的那几个。
• 指标四：菜单空转率。打开了汉堡菜单、没点任何一项、又关掉的比例。这个数直接量化了本文前面那句话——一个被设计成“出发”的控件，被多少人当成了“定位”在用。它高，不是说明菜单没用，是说明用户在拿它回答另一个问题，而那个问题它答不好。

两个数交叉着看，才不会把方向做反

单看一个数容易得出反过来的结论。把指标一和指标三放进一张交叉表，四个格子的处置方式完全不同。

右上那一格值得展开说。重载点很多，用户却不怎么点错——听上去像是好消息，实际上通常意味着这些入口根本没人在用。

用户早就绕过去了：他们不点导航，直接用搜索；或者压根不在你的移动站上做决策，只是把它当成一个下单终端，选品在别处完成。这时候导航的各项指标都很干净，因为它已经退出了这场比赛。

判别方法很简单：把这一格的模板拿去跟站内搜索使用率对着看。如果搜索使用率明显高于同类站，那不是“我们的搜索做得好”，是导航已经被放弃了。这两种解释导出的动作完全相反——前者会让你继续投搜索，后者要求你回头修导航。而团队默认会选前者，因为它更好听。

实验怎么设计，才不会只测到第一类损失

这类改动很适合做对照实验，但有三个坑踩上去就白做。

• 分流单位必须是用户或者会话，不能是页面浏览。本文讲的所有问题都跨页面：用户在菜单里表达不出意图，后果落在两个页面之后。按页面浏览分流，同一个人会在两个版本之间来回横跳，什么都测不出来。
• 观察窗口必须覆盖一个完整的退货周期。第一类损失当天就能看到，第二类损失要等货到、要等用户拆开、要等他决定退不退。用两周的窗口去看一个平均三十天才结算的损失，你只会看到收益。
• 别拿完成率当唯一成功指标。这一条最阴险：几乎任何减少步骤的改动都能让完成率变好看，而第二类损失恰恰是以“顺利完成”的形式出现的。虚荣指标那一篇讲的是同一个道理，这里只是它在移动端界面上的一个具体形态。

配套要跟着改的是客服记录的标注方式。给对话加两个标记：找不到型（他知道要什么，但找不着），对不上型（他找到了，但理解成了别的）。这两个数改造后应该走向相反——前者下降是收益，后者跟着下降才说明第二类损失也修到了。只有前者掉，说明你只做完了一半，而季度总结会把这一半算成全部。

差评那边也有个免费的信号：把差评按有没有提到具体操作分两堆。“网站不好用”是情绪，“我点了那个分类结果它给我展开了一堆子分类”是证据。后者数量少，但每一条都直接指向一个重载点，比任何一份满意度评分都精准。这类文本本身也是资产，用户生成内容怎么用是另一条线上的事，这里只用它的诊断价值。

第一次拿到这四个数，怎么读才不会读反

这四个数都有一个共同的脾气：它们的绝对值几乎没有意义，方向和构成才有意义。第一次拿到手，最容易犯的是下面几个错。

• 拿重载点密度去跟同行比。比不了。一个卖三千个配件的站和一个卖二十款订阅套餐的站，模板复杂度根本不在一个量级。这个数只跟自己的上一季度比。
• 看到菜单空转率高就急着改菜单内容。先分清是哪种空转：打开又关掉、一项没点，说明他在找位置信息；打开、滚了很久、还是没点，说明是命名或者层级的问题。这两种的解法完全不同，而它们在同一个数里。
• 把短命会话率当成页面质量分。它测的是误触和点错，不是内容好坏。一个内容很差但入口很清楚的页面，这个数会很漂亮。
• 只看总量，不看构成。售前咨询总量降了不一定是好事，得看降的是哪一类。这点最容易被季度总结抹平。

还有一条读法上的经验：这四个数应该一起动。如果只有一个在改善，其他三个纹丝不动，多半说明你改的那个点不在主路径上。真正命中的改动，会同时让重载点密度降、替代路径变短、短命会话减少、菜单空转下降——因为它们量的本来就是同一件事的四个侧面。

最后一句：别急着建看板。这几个数在头两个季度手工算就够了，一个人半天。太早做成自动看板，会让它变成一个没人看的绿灯，而这类指标的价值恰恰在于每次都得有人亲手去数一遍——数的过程本身就是那次走查。这个道理在砍掉虚荣指标那一篇里也提过，只是那边说的是选指标，这边说的是别让指标脱离动作。

怎么排期，才不会把重载点拆成一堆新控件？

分堆的判据只有一条。分错了，本来两周能上的八条会跟着躺一个季度。

先说一个非常容易走错的方向，因为它看上去完全合理。

团队拿到重载点清单，第一反应通常是：既然一个手势承载了两个意图，那就给每个意图各配一个控件呗。于是菜单每一行从一个可点区变成两个，商品图旁边多一个放大按钮，列表项右下角多一个快速查看的角标。

结果是每屏的可点元素数量翻了一倍多。而可点元素一多，误触率就跟着涨；误触一涨，就有人提议加确认框；确认框一加，全体用户开始为少数人的失误买单。转一圈回到原地，还多了一堆控件要维护。

拆开重载点，不等于增加控件。前者是把两个意图分开表达，后者只是把界面变复杂。这两件事的区别在于：拆开之后，用户在任何一个瞬间需要做的选择是不是变少了。如果一行里从选一个变成了选两个，那不叫拆开，叫加负担。

三种拆法，成本差着量级

按投入从低到高排，实际上只有三种做法，而绝大多数收益集中在前两种上。

第一种：改默认，不新增任何控件。点主分类的默认行为从“展开子类”改成“直接进入这个大类的商品列表”，然后把子类做成列表页顶部的一条横向快捷入口。这样一来，“看全部”变成零动作（默认就是），“下钻”变成一个可选的旁路。可点元素数量没变，被压掉的那个意图却从不可表达变成了默认结果。

第二种：给被挤掉的意图配一个够大的独立入口。在每一级分类的菜单里放一项“查看全部XX”，写清楚是哪一级的全部——不是光秃秃的“查看全部”，是“全部钓竿”“全部路亚竿”。它新增了一个控件，但它足够大、语义明确，而且正好落在无障碍准则那条“等效控件”的例外里。

第三种：把该常驻的信息常驻起来，一个可点元素都不加。当前所在范围在菜单里高亮；陌生的分类名下面加一行不超过十二个字的说明；横滚区最右边那个元素露出半个。这一类改动完全不涉及交互逻辑，改的是“不做动作就能看见什么”。

永久原语八：悬停的本质是按需显示——用户想看的时候它出现，不想看的时候它不占地方。移动端没有“按需”这个动作，所以真正的选项只剩两个：常驻显示，或者不显示。而团队默认会选第三个根本不存在的选项——放到点开之后。放到点开之后，那就不叫按需了，那叫收费。

把改动分成两堆，这一步决定了排期会不会烂掉

分堆的判据只有一条：这个改动动不动分类的命名和链接地址。

第二堆之所以慢，不是因为技术难。改个分类名是几分钟的事，难的是链接地址变动之后的那一整套善后——跳转、外链、已有排名，每一样都要人盯。

常见的翻车方式是：把这两堆写进同一张需求单。于是第一堆里那八条本来两周就能上的改动，跟着第二堆一起躺了一个季度，因为整张单子在等一个“分类命名方案确认”的会。

按投入排序的落地清单

下面这份按投入从小到大排，前四条通常能吃掉一大半收益。

• 拿一部手机把主要模板走一遍，只数重载点，不做判断。半天。
• 给主导航当前所在的那一项加个不同的样式。这是全清单里投入产出比最高的一条，改的是样式表。
• 搜索框旁边补一个提交按钮，顺手把键盘提示属性配齐。半天。
• 横滚区最右边露出半个元素，两侧加箭头。把“+7”这类文字角标降级成辅助，不再当主信号。
• 在每一级分类里加“查看全部XX”。要动菜单数据结构，一到两周。
• 把点主分类的默认行为改成进列表，子类下沉成列表页顶部的快捷条。这条改动最大，也最值得，因为它一次性消掉了整个站最密集的那个重载点。
• 上地址校验，配好地址字段的自动填充用途。一到两周，收益落在物流和客服那边。
• 给高严重度的动作补撤销，而不是补确认框。按前面那三条策略选。
• 把陌生分类名的说明行做进菜单。不改名字，只加说明，绕开了第二堆的所有麻烦。
• 把重载点密度写进设计评审的验收项。零成本，防的是三个季度后它悄悄涨回去。

三档投入，按你手里真实的人力挑

只有最小档预算，就老老实实只做最小档。最忌讳的是拿最小档的人力去啃默认行为改造——那是一个牵涉到菜单数据、列表页模板和埋点口径的活儿，做一半比不做更糟，因为它会留下两套并存的导航逻辑。

三条停手信号

• 重载点密度已经很低，短命会话率还是高。问题不在这条线上，去查加载过程中的元素移位、以及命中区尺寸，别在这儿继续投入。
• 改完之后，导航的层级点击数上升，但加购率和搜索使用率同时改善。点击数上升不是退步，是用户开始用横向快捷条换范围了——这个动作原来根本发生不了，所以它没有历史基线。
• 清单里只剩第二堆了。该停下来去开那个命名方案的会了，继续在前端上打补丁只会让两套命名并存的时间更长。

季度复查，半小时三件事

做完之后真正让它失效的，从来不是某一次大改版，是十几次各自都有理由的小调整——这个模块要加个入口、那个按钮要挪一下、这里空间不够先折起来。每一次都合理，加起来重载点就回去了。

• 重新数一遍重载点密度，跟上季度比。
• 抽三个改动最多的模板，量一次替代路径长度。
• 看一眼菜单空转率，它是最灵敏的那个数。

这件事该拉谁进来

最后说组队，因为这类项目最容易变成前端一个人的事，然后做不下去。

• 客服必须在场。他们手里有全站唯一一份关于“用户以为自己在干什么”的记录。第二类损失在数据里是隐形的，在客服对话里是显性的。
• 做搜索流量的人必须在场，而且要在第一次会上。不是为了让他审批，是为了在早期就把第二堆改动识别出来——哪些名字能改、改了要付什么代价，越早知道越好。事后才拉他进来，通常意味着方案要推倒重做。站点架构的深度与扁平这条线上的取舍，跟本文的导航层级取舍高度重叠，两边最好一次谈完。
• 商品数据的人要在场。分类名、属性名、色卡名这些东西的源头在他们那儿，改菜单显示名而不改数据源，就会出现同一个东西三个名字的局面。
• 不需要拉设计做全套新稿。清单里前四条基本不动版式，动的是默认行为和样式细节。一上来就立项做整站重设计，是这类问题最常见的死法——重设计周期长、风险大，而且新稿里通常会引入一批新的重载点。

还有一条关于立项的实话：这笔钱已经在账上了，不用估。拿一个季度的售前咨询按“找不到型”切一刀，再拿一个季度的退货按“与描述不符、买错型号、配件不全”切一刀，这两堆的金额是财务已经认过的数。归因模型那套东西在这里派不上用场，因为你要的不是把功劳分给谁，是把一笔已经在流失的钱指出来。

三个月后回头看，通常是哪几件事没守住

这类改造的失效方式很有规律。把它们提前写下来，比事后复盘省事得多。

• 新加的营销位又把重载点带回来了。某次活动要在列表项上加个角标，角标可点，于是列表项从一个意图变成两个。活动结束角标留下了，因为下架没人排期。
• 组件库升级把默认值改了。那个控制横滚区是否显示箭头的开关，在新版本里默认关掉了。没人会为这个开发个回归用例。
• 命名又开始分家。新上的品类沿用了旧的黑话，因为那条验收规则写在体验团队的文档里，而新品类是运营那边直接建的。
• 移动端的验收退回到模拟器。这是最常见的一条。项目结束后，真机走查这件事没有归属人，慢慢就没人做了。

防这几件事的办法，是把检查项挂到已经存在的流程上，而不是新建一个流程。新建的流程一定会死，挂上去的检查项能活得久一点。

具体挂法：模板评审清单里加一行重载点检查；发版前的走查清单里加一条真机单手操作；季度的页面结构体检顺手把这几项一起扫了——页面骨架体检本来就要看标题层级和语义标签，多看一眼命中区尺寸不费事。

最后提一句心态。这套东西不会给你一个能写进汇报首页的大数字，它给的是一堆小数字的同时改善。但它有一个别的项目少有的性质：改动都很小、都可逆、都不需要等一个大版本。在预算紧的时候，这种性质本身就很值钱——预算为零也能做的那些事里，绝大多数都有同一个共性，就是不依赖别人先点头。

保哥踩过的坑：那个七成是真的，只是它产自另一台设备

四个方向全绿，转化率从头到尾一个点都没掉。第六个月，先变的是客服对话的内容。

这一节讲一次我参与过的改造。方向是对的，执行也没走样，前两个季度所有指标都往好的方向走。错在别的地方——错在我们拿来做决策的那个数，产自另一台设备。

客户是一家做户外钓具的出海站，卖钓竿、卷线器、线组和一堆配件，主要市场是英德法，客单价从二十多欧到一百八十欧不等。移动端占了将近八成流量，是个典型的“手机上选、手机上买”的盘子。

改造本身：完全照着上面那套做的

接手时的状况很标准：移动端主导航一层层下钻，点大类展开子类，不高亮当前位置，行末有个小箭头没人点。我们做的事就是前面清单里那几条——每一级加“查看全部”，当前范围高亮，把那个小箭头砍掉，改成整行只有一个含义。

唯一一个需要拍板的地方是：点主分类，默认是展开子类，还是直接进大类列表？

我们没有拍脑袋。我们去看了数据——桌面端的数据，因为只有桌面端能把这两个意图分开统计（悬停和点击是两个不同的事件）。数据很清楚：桌面用户点主分类之后，超过七成继续往下钻到二级，只有不到三成停在大类列表页上。

结论看起来毫无争议：既然七成以上的人是要下钻的，那移动端点主分类就默认展开子类，“查看全部”做成子类列表的第一项。这样多数人的路径最短，少数人也有明确入口。

会上没人反对。我也没反对——这个推理里的漏洞，我是六个月之后才看见的。

前两个季度：四个方向全是绿的

分类页到达率涨了，跳出降了，站内搜索的使用率降了（当时解读成“导航变好用了，用户不用被迫搜索”），加购率涨了。移动端的涨幅比桌面明显，符合预期，因为改的就是移动端。

季度总结写得很顺，图表也好看。

第六个月，先出异样的不是转化率

转化率一直很稳，从头到尾没掉过。先变的是客服对话的内容。

“你们有没有卖导环？”“竿稍单独卖吗？”这类问题变多了。这些东西站上全都有，货就在架子上，分类页也在线，链接点进去正常。

而且这些问题高度集中在一类商品上：配件。钓竿本身、卷线器这些大件几乎不出现这个问题。

第一层：那个七成，是在有悬停的世界里测出来的

后来复盘时把这件事想通了，说起来简单得让人难受。

桌面用户点主分类之前，鼠标已经在那一项上停留过了——子分类列表早就浮出来给他看过一遍了。他是看完七个子类、确认自己要去哪个，才点下去的。所以他点完继续下钻，当然是七成以上。

那七成不是“用户偏好下钻”，是“用户已经用悬停完成了一次侦察，剩下的部分才叫下钻”。

而悬停这一步，不产生任何点击事件，不发一次网络请求，不进任何一张报表。

永久原语九：你从桌面端拿到的每一个行为漏斗，都少了一层——悬停侦察层。它不产生请求、不产生事件、不进任何报表，但它决定了后面每一步的分母。你看到的那个比例，是侦察完成之后的比例；而移动端用户点下去的时候，侦察那一步还没发生。

更一般地说：你从一个有甲动作的环境里测出来的行为比例，不能拿去配置一个没有甲动作的环境，因为那个比例本身就是甲存在的产物。数据也有产地，而产地这一栏，报表上从来不写。

第二层：为什么偏偏是配件

因为配件的分类名对普通用户是陌生词。

导环、竿稍、卡座、前打轮——玩得深的人一看就懂，第一次买竿的人完全不知道那是什么。而配件恰恰是新手最需要买、也最容易买错的部分。

在桌面上，陌生词的成本几乎为零：鼠标划过去，子类里冒出几张缩略图，一眼就明白了。在移动端，弄清楚一个陌生词的唯一办法是点进去看；点进去发现不是自己要的，再退出来，是三个动作。

于是新手用户在菜单里遇到一串看不懂的词，选择了最省事的做法：不点了，去搜索框打一个自己知道的词，比如“line guide”。搜不到（因为站上那个东西叫别的名字），得出结论：这家没有。

用陌生词做分类名这件事，在有悬停的环境里是一个可以承受的选择，在没有悬停的环境里是一场赌注。而这套分类命名，是桌面时代定下来的——定它的时候，那个环境确实能承受。

第三层：想改名，然后卡了半年

看清楚问题之后，方案很显然：把陌生的分类名改成大白话。

然后就卡住了。改分类名要动链接地址，动地址就要处理跳转、外链和已有排名，这条线上有一批词是站里的主要流量来源。做搜索流量那边的同事很谨慎，这个谨慎是对的。

会开了几轮，方案改了几版，最后落地的是一个妥协：只改移动端主导航里的显示名，站内其他地方的名字不动。

于是出现了一个很尴尬的局面：移动端菜单里写着“竿稍与配件”，用户点进去，面包屑上写的是另一个词，商品标题里写的是第三个词。同一个东西，用户在三屏之内看到了三个名字。

这个妥协当时被认为是“先解决最急的”，事后看它制造的困惑不比原来少。

预警其实响过，被归错了科目

翻记录的时候发现，第四个月的运营周会上有人提过：站内搜索里“竿稍是什么”“导环是干嘛的”这类词涨得挺明显。

当时的处理方式是：这是用户教育问题，排进内容计划，写几篇科普文，顺便做点自然流量。

科普文写了，也确实带了点流量。但没有一个人回头去看一眼菜单。

永久原语十：当一个团队把界面问题排进内容计划，说明这个问题已经被正确识别了，只是被归进了另一个部门的预算科目。它不像被忽略，反而像被重视——有人立项、有人排期、有产出物，只是那个产出物解决不了它。

这一点和“被当成怀旧带过”或者“降级成沟通问题”不太一样。那两种是问题被弱化了，这一种是问题被转科了：它从一个界面缺陷，变成了一个内容缺口。转科之后，它在内容那边的完成率是百分之百，在界面这边的完成率是零，而没有任何一张表会同时显示这两个数。

最后改了三处

• 点主分类的默认行为改成直接进大类列表，子类下沉成列表页顶部的横向快捷条。展开从一个必须的前置动作，变成了一个可选的旁路。
• 在菜单里给每个陌生分类名加一行不超过十二个字的说明。不改名字，只加说明——这样绕开了地址变动的全部麻烦，而它承载的正是悬停原来承载的东西。移动端补悬停的唯一办法，就是把悬停里的内容变成常驻。
• 定了一条新增分类名的验收规则：不点进去，能不能猜对里面是什么。猜不对的，要么换名字，要么必须配说明行。这条规则写进了模板评审清单。

结果里有一个数，一开始被当成了退步

配件类的分类页到达率明显回升，“你们有没有卖XX”这类咨询回落。这两个是预期内的。

预期之外的是：主导航的平均层级点击数上升了。因为不再一步展开，用户多点了一下。有人立刻提出这是体验倒退。

拆开看才发现，多出来的那部分点击里，有相当一块是用户在列表页顶部的横向快捷条上换类——从“路亚竿”切到“矶钓竿”再切回来。这个动作在改造前根本不可能发生，因为换范围必须退回菜单重走一遍。它没有历史基线，所以在任何同比里都只能表现为“点击数变多了”。

这也是我后来一直提醒团队的一句话：凡是改造让一个原来不存在的动作变得可能，你的同比数据就会先把它算成成本。

如果重来一次

只需要在那次会上多问一句：这个七成，是在用户手里有几个动作的时候测出来的？

问出这一句，就会发现桌面端那两个事件（悬停、点击）在移动端只剩一个，那个比例的分母根本对不上。代价只是当时多花半天做一次移动端的小样本观察，而不是六个月之后再回头拆一遍。

那次改造本身没有错，“查看全部”是对的，当前范围高亮是对的，砍掉小箭头也是对的。我们错在以为一个行为比例是关于用户的——它其实是关于用户当时手里有哪些动作的。桌面端那份数据里，最关键的一步从头到尾没有留下过任何记录，因为它连一次网络请求都没发出去。

这套方法在什么样的站上最该先做

不是所有站都值得马上排这件事。按优先级排一下：

• 最该先做：品类词对普通用户陌生的站。钓具、汽配、五金、实验器材、乐器配件这类，分类名本身就是专业词汇。桌面端靠悬停消化了这个成本，移动端没有这个缓冲。
• 其次：目录层级深、子类多的站。层级越深，一个手势承载两个意图的代价被乘的次数越多。
• 再次：视觉驱动、变体多的站。颜色、尺码、材质这些需要横滚承载的东西越多，边界信号的问题越突出。
• 可以往后放：单品牌、少SKU、订阅制的站。目录只有一两层，用户没有太多可迷路的地方；这类站的移动端问题通常集中在结账和账户，不在导航。

另外有一类站需要单独提醒：刚从桌面时代改过来、但分类体系一个字没动的站。这类站最容易出现本节说的那个问题——版式改了，命名逻辑还是老的，而老的命名逻辑是建立在“用户能悬停”这个前提上的。判断方法很简单：把主导航的每一项拿出来问一句，一个第一次来的人不点进去，能不能猜对里面是什么。

最后补一句关于优先级的实话。这套东西的收益不会体现在某一个惊艳的数字上，它体现在一堆小数字的同时改善：分类页到达率、售前咨询构成、退货理由分布、菜单空转率。正因为它不产生一个能写进汇报第一页的大数字，它才长期排不上队。而它的成本，前四条加起来不过两三个人周。

常见问题解答

移动端和桌面端的界面，是不是应该尽量做成一样的？

该保持一致的不是版式，是意图能不能被表达。桌面上用户能用两个动作说出两件事，移动端只能用一个动作，那就必须换一种方式让第二件事仍然说得出来——可能是改默认行为，可能是加一个独立入口，也可能是把原来悬停才显示的东西改成常驻。硬把桌面版式等比缩小，看起来最一致，实际上是把一整套动作悄悄收走了却没给替代品。

我们已经做了响应式，这些是不是就自动解决了？

不会。绝大多数响应式适配的判断条件全部建立在屏幕宽度上，而宽度和用户手里有几个动作没有相关性——一台横过来的平板宽度够宽，悬停能力却是零。层叠样式表里其实有专门的语法可以查询悬停能力和指点精度，但真正在代码里用到它的站是少数。做完响应式只说明版式塞进去了，没说明动作补回来了。

点主分类，到底该展开子类还是直接进列表？

更好的做法是让这个问题不需要二选一：默认直接进入这个大类的商品列表，把子类做成列表页顶部的一条横向快捷入口。这样想看全部的人零动作就到了，想下钻的人多点一下也到了，而且他还多了一个原来不存在的能力——在列表页上直接横向换范围。如果暂时改不动默认行为，退而求其次是在每一级菜单里放一项写清楚范围的“查看全部XX”。

搜索框旁边再放一个提交按钮，会不会显得冗余？

不冗余，因为这两个入口的产权不一样。系统键盘上那个回车键不在你的页面里，标准里对它的措辞全都是“用户代理应当呈现某个提示”——你能建议它印什么字，不能决定它印不印、在哪、用户看不看。页面里那个按钮是你自己的。把一个关键动作的唯一入口放在你控制不了的地方，风险和收益完全不对等。

怎么判断一个手势能不能当作某个功能的唯一入口？

有一条现成的判据可用：媒体查询规范在定义悬停能力时明确写了，那些能做、但做起来不方便、并且不属于该设备常规使用方式的操作，一律按“不具备”处理——它甚至专门举了例子，把长按当悬停用的触摸屏，仍然算作不能悬停。照这个标准，长按、捏合、双指、横向滑动这一类都不该是唯一入口，它们可以是加速通道，但每一个都得有一条明路兜着。

意图重载点密度这个数，多少算高？

这个数不适合跟同行比，因为不同品类的模板复杂度差得太远。它的用法是跟自己上个季度比：只要它在涨，就说明这几个月里又有新的意图被塞进了已有的手势。真正要盯的是配套那个数——被压掉那一侧的替代路径长度。零到一个动作是健康，两个勉强，三个以上基本等于那条路不存在。

移动端的表单，为什么不能靠自动更正来兜底？

因为标准里明确禁止这么做。控制自动首字母大写的那个属性，规范正文写着它绝不可以被当作任何形式的输入校验依据，理由是物理键盘上它通常不生效、用户也能覆盖或事后编辑。更值得注意的是，规范替网址、邮箱、密码这三类字段单独关掉了自动大写，而收货地址不在这份名单里——它格式严格得像邮箱，外形又像一句普通的话，两边的坑同时踩，所以它才是移动端最容易被改坏的那个字段。

权威参考资料