集团翻译应用的交互优化与量化验证（下）
背景
在上一篇文章里，我分享了如何通过设计「目标语言自动切换机制」来杜绝同语言翻译问题和减少用户手动切换语言的频次，以及通过一个自动聚焦策略来减少用户在使用翻译中的交互成本。
这次我将聚焦翻译应用里核心功能「切换语言」的交互。主要改动点有两个：
- 默认翻译语言的槽位数量和默认值修改；
- 下拉选择语言面板的 UI 优化和选项排序优化。
值得一提的是，在做这两个优化之前我明确地带有设计目标 —— 就是奔着减少费力度、提高用户使用效率来的。所以在开始设计之前，我进行了用户调研，以及使用谷歌的 GSM 框架来定义和拆解指标，将逐条指标与设计决策绑定，让每一次决策都有依据。
一、默认翻译语言槽位修改
调研/思考阶段
与一些外部翻译应用（有道翻译、搜狗翻译等）不同，我们公司内部翻译应用的界面上会分别在「源语言」和「目标语言」模块里各提供 3 个语言槽位。让需要同时处理多个语言的岗位同事可以直接在界面上切换，不必每次都在下拉面板里选择。
我们在外部提供几个槽位便于用户快捷切换，同时也有下拉面板展示全部语言。这个主要的模式不会改变，但主要问题是：
设计能做些什么来降低用户在翻译任务中手动切换语言的成本？
迷茫之际，我又搬出 AI 时代之前那套的东西：谷歌 GSM 设计框架。并进行拆解：
- Goal：降低用户在翻译任务中手动切换语言的成本
- Signal：用户触发下拉菜单展开更多选项的行为减少
- Metrics：下拉菜单人均触发次数
然后基于 Signal 进行反推：
- 用户为什么需要通过下拉菜单手动切换语言？—— 当前槽位无法满足使用需求；
- 为什么当前槽位无法满足使用需求？ —— 数量不够或者默认提供的选项不精准；
- ...
我推理出来语言槽位的设计机会点有这两个：槽位数量和默认值。
设计阶段
通过 GSM 框架拆解后，设计方向明朗了很多，逐个击破即可。针对这两个问题，我先会分析用户切换「源语言」和「目标语言」的使用情况：
两份口径不同的图表都展示了一个很明显的结果：用户极少切换「源语言」，所以我有以下推断：
- 源语言切换次数非常少，代表默认选中的「自动识别」已经能满足绝大用户所需。
- 目标语言切换次数较多，而且有不少人是需要通过下拉菜单来切换语言（印证了默认槽位提供的语言选项无法满足工作所需）；
目标语言槽位改造
目前「目标语言」槽位数量是三个，我想着如果想要减少用户在下拉菜单里切换语言。多提供几个槽位会不会是一个比较好的方式。一个很简单的逻辑推断：外部展示的选项更多且更精准，就有更多的用户无需通过下拉菜单来完成任务。
基于这个逻辑，我也找了一些高频使用翻译功能的用户去调研了他们的使用场景和习惯。下面是一部分的内容：
调研得知高频用户里会存在一些角色是需要同时处理多种外语的。而目前仅提供三个槽位是肯定不够的，因为中文肯定会占用一个，剩下可用于外语的只有两个槽位。
所以基于数据分析、调研结论和界面可用空间考虑，我将槽位从 3 个扩展为 5 个。
槽位数量扩展了，那默认提供什么选项以及他们的顺序，是接下来要考虑的事情。我希望能够：
提供对用户最有价值的 5 个语言选项。
最开始我只是简单的想到：“只要选最多人用的那 5 个语言就行啦！“。但是真正进行取数的时候才想到，其实是有好几个口径的，而且每张表的 TOP5 都不同。我陷入了沉思：这 5 个默认槽位到底该怎么选？
- 取切换数 TOP5：一个语言被切换到的次数多不代表进行翻译的次数多，无法确保覆盖面；
- 取翻译量 TOP5：可能出现一小撮人但大量使用的现象，这种语言覆盖面较窄（比如越南语）；
- 取用户数 TOP5：可能出现很多人切换到该语言，但真实翻译量很少的 “假热门“ 现象（比如繁体中文）。
我觉得默认槽位里应该放既多人用，又会被高频使用的选项。这时仅看单一维度的数据是片面的，所以我想到可以用一个加权公式。
既然我两个维度都想兼顾到，那干脆公平一点：用户覆盖面和真实翻译频率各占比 50%。定义两个指标：
- M1 用户广度：使用该语言翻译的去重用户数 / 总用户数
- M2 转化效率：该语言的真实翻译次数 / 该语言被选中次数
归一化后进行相加，取排名最高的前五位。这里我用了 Claude Code 来帮我计算，加权公式计算后最终的如下图。
前五个槽位默认值锁定为：英语、中文简体、西班牙语、阿拉伯语、葡萄牙语。我稍微调整了下排序，将西班牙语和葡萄牙语放一起，因为这两个都属于欧洲语言包。
源语言槽位改造
目前「源语言」默认槽位是自动检测、英文、中文简体、中文繁体。 此前分析的结论是自动识别已经能满足绝大多数的翻译任务，所以这里的槽位我的设计思路与目标语言的槽位相反，这里我想的是简化。
由于「中文繁体」已被证明是假热门语言：源语言为中文繁体的翻译量排名第 8 —— 不值得占据一个默认槽位。于是我决定将其移除（槽位还在）。
最终的优化动作
- 目标语言的槽位：数量从 3 个扩展至 5 个，默认提供中文简体、英语、西班牙语、葡萄牙语、阿拉伯语。
- 源语言的槽位：数量不变，去掉中文繁体的选项。
数据验证
数据显示在上线后 40 个工作日：
- 用户在外部槽位切换语言的占比 88.7%。即每 10 次切换语言，有接近 9 次是发生在外部槽位。虽然新旧版从数值上看对比不明显，但旧版有大量脏数据 —— 同语言翻译 BUG 导致用户每次翻译后必须手动切换目标语言。
- 通过外部槽位切换语言的人均次数从 20.2 上升至 27.3 人，提升了 33%。符合增加槽位暴露后带来更多直接切换的预期。
二、选择语言面板 UI 交互优化
调研/思考阶段
其实无需过多的用户访谈、调取数据，只要用设计经验、对比竞品就能判断到改版前的选择语言框选择效率是低下的，最关键的问题是：打开面板后一屏只能看到 7 个语言选项，比其他同类型翻译产品少了很多。
既然用户触发了下拉面板，这意味着外部槽位的语言不能完全满足他们当时的需要，用户要在下拉菜单的全量数据里寻找目标语言。我要做的就是让用户在下拉面板进行选择时更高效。
具体要做什么优化点？我的设计目标是明确的，可以继续用 GSM 框架拆解：
- Goal：降低用户在下拉菜单里切换语言的成本
- Signal：用户在下拉菜单里的停留时间和行为减少
- Metrics：下拉菜单停留时间 / 搜索功能使用率 / 搜索输入成本
然后基于 Signal 进行反推：
- 用户为什么在下拉菜单里要停留这么久？—— 当前一屏展示数量少，需滚动查找；
- 用户为什么在下拉菜单里行为这么多？—— 搜索功能做得不够方便。
我推理出来语言槽位的设计机会点有这两个：面板坪效优化和搜索交互优化。
设计阶段
面板坪效优化
对于坪效优化，我的改动很直接：将下拉菜单布局改为多列、同时将高频语言选项前置，让其更容易被发现。
至于选项排布，我分为三层展示：
- 第一层：属于常用模块，放翻译量 TOP 12 的语言；
- 第二层：属于全部语言模块，放翻译量 TOP 13~24 的语言；
- 第三层：按首字母排序放剩余的全部语言。
在排序的决策中，有三点额外的考量可以在此分享：
- 根据使用数据显示，TOP 9 之后的语言使用量差异已经不大了，所以我这里就没有复用之前的权重公式，仅简单地按翻译量排序；
- 中文、英语放在靠后的位置是因为这是在默认槽位里靠前的语言，比较难被替换走 —— 换句话说，在大多数情况下都会在槽位里出现，所以在下拉菜单里的位置不需要太靠前；
- 在每一层我都有手动地微调了一些排序，让地理位置相邻的语言更靠近。
同时有一个额外的优化点：由于面板展开位置非右对齐 —— 会占用右边空间。所以让前端做了个识别浏览器边界自动偏移面板，确保用户在绝大多数情况下都能完整看到面板。
搜索交互优化
其实我们在坪效优化中已经将绝大多数用户会用到的语言选项进行了曝光。用户如果也还是不想在里面找，习惯用搜索来精准定位某语言，那么他就会用到搜索功能，需要在文本框里输入内容。
以下的优化就是针对这部分的用户进行的，旨在减少他们在「搜索 -> 选择语言」这个链路中的交互成本。这部分的优化可以拆解为三步：
1. 输入前：
打开面板时以及页面可见性发生变化时自动聚焦到输入框，这个是已有逻辑；
2. 输入中：
现在搜索仅支持字符匹配，比如我想搜西班牙语，就必须输入带有 “西班牙语“ 这四个字里至少一个字才能匹配到。
我想到可以支持更多搜索方式，比如：
- 语言代码：用户输入
zh就会出现简体中文/繁体中文，输入es，就会出西班牙语，旨在减少用户在搜索时的输入量； - 拼音：用户输入
xi就会出现西班牙语、希伯来语等，拼音里 xi = 西/希，包含在 "西班牙语" 内。做这个兼容的目的是希望用户不用来回切换输入法。
并把这个新能力在输入框占位符文本（用户未输入任何文字之前看到的内容）里进行曝光。
3. 输入后：
用户在输入时，双手一定会在键盘上。所以我对搜索结果列表做了一个优化：支持键盘 ↑ ↓ 键聚焦选项 + 回车键选中的逻辑，旨在减少用户在键盘和鼠标之间来回切换的情况。
整体使用体验会比较丝滑，看视频操作：
数据验证
下面来看改版后 40 个工作日的数据，设计意图都直接或间接地证明了是有效果的：
- 用户停留在下拉面板的时间缩短了： 停留时间中位数从 3.5 秒下降至 2 秒，缩短了 43%；
- 用户需要搜索来找语言选项的情况变少了： 无搜索完成率从 42.2% 升至 66.7%，提升了 24.5 个百分点；
- 即使仍然要搜索，用户的搜索成本也降低了： 搜索框内键盘录入次数从 9.1 次降至 4.7 次，打更少的字找到了目标；而中位数从 8 降至 0 更是佐证了大多数用户已经不需要搜索就能找到目标了。
原来用户找语言需要滑动列表或依赖搜索，现在更多高频语言直接暴露在第一屏，用户打开下拉就能直接点选，既缩短了操作时间，也降低了对搜索功能的依赖度。
经验总结
我觉得在数据回收、验证和归因这个知识块还有很多可以研究、学习的空间。现在有 AI 之后，数据分析已经不是问题了，但是在「基于目标给出可度量的设计方案」这个阶段，还是需要人脑大量介入的。希望之后有更多的机会做类似的事情吧。
下面单独说几点我做这次设计改版收获比较大的地方。
灵活运用加权公式
我们可以利用「加权」的方式来对多个方案做优先级、做排序。比如这次优化我想在「很多人用的语言」和「被用了很多次」的语言中取舍，我觉得这两个维度都重要，于是我就各取了 50% 的权重。
工作中我也发现好像一个设计方案挺难做到所有角度都是完美的，总会有些侧重，有些牺牲。比如某个交互虽然能把步骤减少了，但可能会导致某个想推广使用的功能被无视掉。「加权」不是为了找到完美答案，而是能让决策更有依据。
这次例子我简单地用了 5:5 的权重，不过我问了下 AI，如果情况复杂点或者维度更多一点，权重比例的分配还是挺有说法的。下回有类似场景再学习学习吧。
用户行为具有惯性
数据会随着用户习惯的迁移持续向好。在上文提到「选择语言面板优化」的 40 天数据中，每隔约 10 个工作日就能看到一次增长。
| 指标 | 1-10 天 | 11-20 天 | 21-30 天 | 31-40 天 | 40 天平均 |
|---|---|---|---|---|---|
| 停留时长 | |||||
| 🔸 旧版 | 3.50 秒 | 2.96 秒 | 3.48 秒 | 3.67 秒 | 3.46 秒 |
| 🔷 新版 | 2.18 秒 | 2.16 秒 | 1.95 秒 | 1.80 秒 | 1.99 秒 |
| 无搜索完成率 | |||||
| 🔸 旧版 | 37.1% | 47.2% | 43.1% | 42.1% | 42.2% |
| 🔷 新版 | 65.2% | 63.8% | 65.9% | 72.4% | 66.7% |
虽然新版优势一开始就存在，但期间内用户停留时间中位数连续四段下降，无搜索完成率连续上升，说明用户越用越熟练，已经培养出用户的操作惯性。
体验优化的本质？
其实我在这家公司做了挺多像这次分享文章中的优化案例，虽然都是小场景的优化，但基本上都是可衡量的。当然，有拿到正向结果的，也有没什么明显效果的。同一种事情做多了之后，相关的经验多了，我就会想这种事情的本质是什么。
设计师天天喊的「体验优化」，到底是在做什么？
我有一阵子天天想这个事情，目前为止暂时想到有两大类。
一、降门槛
第一类是「降门槛」。我的理念里可以很宽泛的理解「门槛」这个词，所有减轻做某件事的「费力度」的努力 —— 包含行为上的、认知上的等等 —— 都认为是在「降门槛」。尤其是 B 端设计领域，这种设计任务太常见了。
同义词有很多，比如「提效率」、「降低费力度」、「提高易用度」等等，不过抛这种名词没意思，我下面记录下我对这种事情的理解吧。「降门槛」一类的行为，我想到可以包括：
- 降低使用门槛： 比如根据用户当前状态来自动填入某些信息。常见指标是操作步骤数量、鼠标点击次数和停留时长等；
- 降低认知门槛： 比如通过一些配图、视频、情景式的提示 等来让用户更好地上手或了解某个概念。常见指标是首次完成某功能的时长，任务首次通过率/报错率，某类型问题的客服咨询频率等等。
做增量
另一大类我觉得是「做增量」，比如想要触达到更多用户、某功能的使用率提升等等。不过我在这家公司做的大多是内部系统，没有什么需要衡量这个指标的场景。
最后感悟
还有最后一点感悟是，如果要做「体验量化」相关的事情，有三点很重要：
- 选容易衡量的，数据直观的和容易归因的方向来做。不然后面很多棘手的事情，容易陷入自我拷问的环节；
- 做设计方案的时候就要想到用什么指标来衡量，并以文字形式记下来。因为开发完还要上线一阵子才能回收数据，到时候很容易忘掉最开始的目标；
- 公司的埋点标准、取数平台要用好用熟。一开始先做点简单的，把流程熟悉了、跑通了，后面做复杂的事情才会更加游刃有余。