集团翻译应用交互优化实践案例分享（上）
背景
集团内部有一个能提供翻译能力的 API 及相关的接入文档。这里面一个简单的功能体验页面，嵌在 API 接入介绍页，是给各中心、业务团队在接入 API 前简单体验用的，属于「体验型 DEMO」，定位是「能用就行」。
但后面集团需要一个面向全公司员工的翻译工具，所以要将翻译功能独立成为一个应用，有专属的页面，这时候就不是「能用就行」了，需要开始考虑用户体验。
翻译应用属于一个小工具，不像一个大系统里的业务模块。这个小工具比较有特点：功能不多、交互简单；但用户使用习惯高度相似，而且会在一段时间内高频使用。
我觉得这里可以有点设计机会，能做些比较纯粹的、和设计职能关联度较高的体验优化，就在这半年内陆陆续续提了点迭代优化。过程中做了些用户调研、数据分析，也曾经对某些点比较纠结。过程还是比较充实的，所以打算写一篇文章来记录一些有意思的点。
这里不会像 Case Stduy 那样去高谈阔论全局思维、顶层视角...，而是朴素且切实落地的设计思考和体验细节，而且每个优化点都有上线后的数据。
一、目标语言自动切换机制
发现问题
其实我提早了一些知道旧版的翻译功能页需要做升级，所以我前置做了些埋点来记录用户行为和使用数据。用户每一次翻译文本，都会上报这些内容：
- 用户信息（工号、设备、岗位名称、办公地点等基础数据）
- 源语言
- 目标语言
- 翻译模型（我们支持多个供应商的翻译服务切换）
最开始我是想看看哪个翻译组合（比如中译英、中译日等）用得比较多，好让我修改默认翻译语言的选择。使用数据如下图：
其中，中译英和英译中作为最常见的翻译组合并不让我感到意外。让我意外的是：为什么有约 15% 的翻译任务是源语言 = 目标语言？
定位问题
我决定顺藤摸瓜，搞清楚同语言翻译原因。正好我工位附近坐了几个负责全球 IT 业务的同事，他们会经常用这个翻译工具，所以我就把凳子搬过去他们旁边，看看他们平时怎么用的。最后终于找到原因了
我们的源语言会默认选中自动检测（翻译供应商接口提供的能力），同时也会默认会选中英文作为默认翻译的目标语言。如果用户将一段英文文本粘贴到源语言的文本框，翻译工具识别到文本框有内容，就会自动提交翻译。此时就会出现源语言和目标语言是同一个的问题。
上面说得可能有些抽象，试想下这个常见的场景：
- 你收到了一封英文邮件，想翻译看看。你复制了邮件内容到待翻译文本框，源语言自动检测为英文。你想要将其翻译成中文，于是你在「目标语言」里设置了中文；
- 接下来你需要回复邮件。你在文本框里输入了一段中文，系统自动检测为中文。但是你没有修改目标语言（仍然是中文）；
- 停止输入 300ms 后，系统自动提交了翻译行为，将你输入的中文翻译为中文；
- 发现翻译结果不符预期，原来是目标语言没有选择对。你重新选择了一个目标语言，短暂的加载后，界面出现了一次新的翻译结果。
解决问题
我激进地认为同语言的翻译获得的结果一定不是用户想要的。看了同事的操作，他们在遇见这个问题时，也是要手动修改目标语言的。
为了减少用户进行翻译任务时的摩擦，我要给个兜底的处理逻辑。既然要避免同语言的翻译整理了一下思绪，兜底方案需要回答这个问题：
当
自动检测到的语言和翻译目标语言一致时，目标语言应该怎么处理才能避免同语言翻译？
我觉得这个问题应该不是只有我们团队遇到，所以我也去看了看市面上几个翻译产品：
- Google / Bing 翻译：不处理，任由同语言翻译现象发生；
- 搜狗 / 有道翻译：源语言为中文时，目标语言切为英文；源语言为非中文时，目标语言切为中文。
搜狗/有道翻译的做法确实是解决了同语种翻译的问题，知道国内用户最高频是中/英互译，所以兜底语言选了这两个。但我们公司用到其他语种的用户也着实不少（高频用户里同时处理三种或以上语言的用户占 32%），所以还有其他做法能照顾到这些用户吗？
虽然我们没办法准确预测用户下一次进行翻译任务时的目标语言是什么，但我们至少能确定是有一种常用的场景 —— 两种语言互译。即中英互译、中葡互译或中日互译等这种需要两个语言之间来回翻译的场景，比如回复邮件、与老外对话等。
所以我在方案里更进一步，让回退语言首选用户上一次选择的目标语言。检测到同语言翻译时，需要帮用户用户切换到上一次翻译的目标语言。这对中英互译，以及非中英互译的场景都非常友好，用户基本上不用手动切换目标语言了。
但是事情没有那么快结束，遇到了两个问题：
一、边缘场景
用户可能没有选择过任何语言，或者上一个语言刚好也是当前的源语言。
这意味着我们设计的兜底逻辑里需要再有一个兜底逻辑。因为我们大多数用户都是中英互译，所以根据用户当前源语言来决定回退到中/英的其中一种语言。也符合国内主流翻译应用的做法。
- 如果当前源语言 = 中文(简体) —— 目标语言切换至英语
- 如果当前源语言 ≠ 中文(简体) —— 目标语言切换至中文(简体)
最终效果：如果你输入中文且当前目标语言为中文时，
- 上一个目标语言不可用： 如果你从未切换过目标语言，或之前切换过的语言也是中文，将自动翻译成英文；
- 上一个目标语言可用： 如果你之前切换过其他非中文语言，将自动翻译成你上次选择的语言。
二、前端实现受限
因为
自动检测是接口的功能，只有等翻译接口返回了内容时，前端才能判断到是否属于同语言翻译。
所以当时我们的自动转换逻辑只能后置，在第一次获得翻译结果时，检测是否属于同语言翻译，如果是：
- 本次翻译结果不展示给用户
- 触发转换逻辑，转换设置后再次提交翻译任务
- 显示返回结果
全程用户无感知。用户看上去还是只执行了一次翻译，但背后我们已经帮用户进行了兜底处理，进行了语言切换。
最终的逻辑图会是这样：
最后，用户在使用时的感觉会非常丝滑，请看视频：
数据验证
功能上线后，我调取了两个月的使用数据。
数据表明，通过这次完整的发现问题—定位问题—解决问题过程，已经基本杜绝了同语言翻译的情况。而同步新增的自动切换语言的逻辑，也显著减少了用户在翻译任务流中需要手动切换目标语言的次数。
- 同语言翻译的任务占总翻译任务的比值从 14.68% 下降到 0.05%；
- 人均目标语言手动切换次数从 32.7 次降至 5.4 次，每个人需要手动切换语言的次数都降低了。
二、自动聚焦策略扩展与优化
设计思路
最开始我为翻译页面设定了一个逻辑：每次访问/刷新页面，都将光标自动聚焦到待翻译文本的文本框。这是一个很常见的交互细节，我经常也会用在一些需要简单输入的弹窗、浮层当中。
但这次我面对的是翻译应用，里面最最最主要的操作都集中在文本框，用户每次使用也一定会输入待翻译的文本。所以对于一款翻译应用，上面提到的常规自动聚焦做法我觉得是不够的，要做就做到极致，把场景想周全。
所以这个优化点我的设计目标很明确：
尽量减少用户翻译的交互摩擦 —— 提供尽可能多的自动聚焦触发机会，减少用户需要手动聚焦文本框的次数。
设计过程
针对这一目标，我先想到的是将所有小功能的点击后都自动聚焦到文本框。比如：
- 每次修改源语言或目标语言
- 每次交换语言
- 每次清空文本
- 每次复制译文
- 每次切换翻译模型
这里我把能想到的触点都列出来让开发帮我实现了。实际上这属于一个冗余设计，即用户不一定进行上述操作后仍然需要继续执行翻译任务 —— 聚焦逻辑在一些情况下是多余的。
不过即使用户不需要，也不会干扰用户的后续操作；如果用户正好要继续翻译，还能帮他们省掉点击输入框的一步。
还能更进一步吗？
我希望做到的是：只要用户当前的网页从不可见或失焦状态再切回来时，都要聚焦到文本框。
这里我用到了两个浏览器原生 API: Window Focus 和 Page Visibility。
Window Focus 是用来监听当前浏览器是否处于焦点状态。如果用户最小化浏览器或者切到了另一个软件（比如通过 cmd + tab 的方式），就会进入失焦 blur 的状态。反之如果当前用户正在使用浏览器，则进入 focus 状态。这是浏览器维度的。
Page Visibility 则是检测这个网页是否处于可见状态。比如切走了标签页、锁屏、最小化窗口或整个浏览器都被其他软件覆盖等，监听页面是否可被看见。与上一个 API 不同，窗口失焦不代表页面不可见。这两个 API 有少量重叠的部分，Page Visibility 这是页面维度的。
利用这两个 API，我能够实现任何时候用户回到翻译界面时，光标都会聚焦到待输入文本框中。
但是事情又没有那么快结束，需考虑焦点冲突的情况 —— 用户在切走窗口前，光标可能已经聚焦到其他输入框了。比如顶部导航栏的全局搜索、切换翻译语言面板里的搜索、各种系统弹窗等等...
所以还要做个逻辑来限制刚刚提到的自动聚焦行为，不能抢走用户之前聚焦的焦点。
总的来说，最终我们文本框的自动聚焦逻辑是这样：
原有基础交互： 在页面访问/刷新时自动聚焦；新增冗余设计： 每次进行功能交互后（如切换语言、清空文本框、复制译文等）光标自动聚焦；新增支持失焦检测： 来回切换窗口/标签页时，如果当前处于失焦状态，那么下一次切回来时自动聚焦到待翻译文本框。
数据验证
在本次优化上线后，我调取了 30 天的数据进行对比。
- 每 100 次翻译的有效聚焦次数从 24.48 次下降到 6.94 次，降幅高达 71.65%，证明这次我做的交互优化确实是有效的 —— 需要手动聚焦输入框的场景显著减少；
- 但用户惯性仍然存在。即便设计中已经做到了很多场景用户不需要手动点击，但无效点击占比仍然高达 81.29% —— 每 10 次点击输入框的行为里，有大约 8 次都是多余的操作（实际上已经提前自动聚焦了）。
这个数据表现是在我意料之内的。我确实在很多交互触点里都做了自动聚焦的策略，范围已经覆盖了我能想到的所有场景了。但用户有自己的习惯，操作惯性每次输入前多点一次或多次输入框。我觉得倒是不用强行去修改用户的操作习惯，毕竟属于冗余设计 —— 有更好，没有也无伤大雅。
经验总结
实践了新的发现体验问题的方式
在以前的工作中，我会通过好几种方式来挖掘线上产品体验问题，包括但不限于：
- 参考竞品。 同一个功能，竞品的交互和我们自家产品的交互有没有不同？如果有，我会尝试分析两者的优缺点，结合自身产品的业务属性、用户特点等再做判断；
- 模拟路径。 给自己安排几个任务，模拟真实用户的使用情况。在不同的现实条件下（比如不同设备、不同数据源等）把整个路径走一遍，自己就能感受到哪里有卡点，哪里不够顺畅；
- 用户访谈。 通过对话访谈、观测用户操作等方式，可以知道用户真实的工作流，他们的习惯、卡点等等，基于此也可以有很大的发挥空间。这一点我在现在的公司做得比较多，我也很喜欢做这个事情，能了解到其他岗位平常在做什么也挺有趣的。
但是这次我多了新的方式就是「看埋点数据」。最开始只是做版本迭代，通过用户的行为数据，发掘到一些数据异动，顺藤摸瓜找到了一个体验问题。
同时在发现问题后，我完整、独立地实施了一次体验优化闭环，包含：
- 通过分析用户操作定位问题；
- 代入用户视角思考方案、提供解决方案；
- 回收上线数据验证改版成效
埋点 = 行为 ≠ 真实意图
基于翻译软件功能的交互特点（输入内容后停留若干时间会自动进行翻译），会出现很多重复的埋点上报。比如用户只修改了一两个字，然后停顿一下，触发了自动翻译，此时就会触发埋点上报。
但其实这都只算一次翻译意图/任务。如果想要更精准地看翻译使用情况，可以设定一个间隔，比如：15 / 30 秒内重复进行的翻译任务只算最后一次。
不过我发现清理前/后对「目标语言自动切换机制」的模块的数据统计部分影响几乎没有，为了方便起见就没有多做这一步了。理论上想准确点统计数据是要这么做的，能减少很多噪音。
顺带一提：这些目的明确的数据清洗任务可以全部交给 AI 来做，我目前在用公司提供的 Claude Code，觉得体验挺好。
利用浏览器 API 提升设计细节
Page Visibility 这个 API 能让前端知道当前网页是否不可见或被隐藏。查到这点的时候，突然想起很多年前 QQ 空间或者以前的博客网站，当你切走了窗口时， Tab 的网页标题文案会自动修改。
突发奇想：我发现在 AI 时代，这个小交互似乎变得更重要了。现在很多 AI 功能的入口都是输入框，很多用户的第一次页面交互就是要在输入框里打字。
就像这次我做的翻译优化那样，要减轻用户的交互成本，我们可以利用这两个 API 做到用户任何时候切换到网页时，都能自动聚焦到输入框，减少一次鼠标点击。
同时，很多 AI 助手为了显得亲和力更强，会有一个 IP 角色，做得细一点的还会给角色做点动画，显得更加生动活泼。
我们同样也可以利用这个 API，在用户切进来网页时，播放一次角色的动画，比如微笑、欢迎招手，或者出现点提示文案引导用户下一步等等。刚好最近我就在公司一个 AI 数据查询助手里实践了该功能，感觉效果还不错。下方视频分别展示了切换浏览器标签页、切换窗口和打开最小化窗口时，都会自动播放一次卡通角色招手的动画。
利用系统、浏览器特性来为体验设计增添色彩，是我很喜欢做的事情之一。
用户的操作习惯具有惯性
自动聚焦优化的案例就是一个很好的证明。自动聚焦的设计方案解决了「不点就没法输入」的硬性步骤，所以有效激活点击骤降七成；但用户早就已经有「要输入就先点输入框」的肌肉记忆，哪怕输入框已经被自动聚焦了，手还是会下意识点击。
如果目标是短期汇报、快速拿亮眼成果，就尽量避开高用户惯性的优化方向。转而聚焦步骤删减、流程简化这种能显著减少在必经路径环节的内容。
下一期内容
下一篇文章]会分享我是如何用谷歌的 GSM 框架来定义和拆解指标，并基于定性/定量数据和一个纠结很久的加权公式来设计翻译产品里的高频功能 —— 语言选择。