> ## 文章索引 > 在这里获取全部文章的索引：https://lrd.im/blog/llms.txt > 这是 lrd.im 的个人博客，记录设计、技术与思考。 # 集团翻译应用的交互优化与量化验证（下） ![封面图](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/01.png) ## 背景 在[上一篇文章](https://lrd.im/blog/2026-07-09)里，我分享了如何通过设计「目标语言自动切换机制」来杜绝同语言翻译问题和减少用户手动切换语言的频次，以及通过一个自动聚焦策略来减少用户在使用翻译中的交互成本。 ![系列文章结构概览图：上篇涵盖「目标语言自动切换机制」和「自动聚焦策略扩展与优化」，下篇涵盖「默认翻译语言槽位修改」和「选择语言面板 UI 交互优化」，共四个优化点。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/02.png) 这次我将聚焦翻译应用里核心功能「切换语言」的交互。主要改动点有两个： 1. 默认翻译语言的槽位数量和默认值修改； 2. 下拉选择语言面板的 UI 优化和选项排序优化。 ![语言切换功能改版前后对比：旧版下拉列表单列展示语言选项，搜索框仅支持语言名称搜索，槽位显示 3 种语言；新版槽位扩展至 5 种语言，选择面板改为三列网格布局，搜索支持拼音和语言代码。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/03.png) 值得一提的是，在做这两个优化之前我明确地带有设计目标 —— 就是奔着减少费力度、提高用户使用效率来的。所以在开始设计之前，我进行了用户调研，以及使用谷歌的 GSM 框架来定义和拆解指标，将逐条指标与设计决策绑定，让每一次决策都有依据。 --- ## 一、默认翻译语言槽位修改 ### 调研/思考阶段 与一些外部翻译应用（有道翻译、搜狗翻译等）不同，我们公司内部翻译应用的界面上会分别在「源语言」和「目标语言」模块里各提供 3 个语言槽位。让需要同时处理多个语言的岗位同事可以直接在界面上切换，不必每次都在下拉面板里选择。 ![语言槽位对比示意图：集团翻译应用在源语言和目标语言模块各提供 3 个语言槽位（多个语言槽位），而搜狗翻译、Google 翻译等外部应用仅提供单个语言槽位用于切换源语言和目标语言。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/04.png) 我们在外部提供几个槽位便于用户快捷切换，同时也有下拉面板展示全部语言。这个主要的模式不会改变，但主要问题是： > 设计能做些什么来降低用户在翻译任务中手动切换语言的成本？ 迷茫之际，我又搬出 AI 时代之前那套的东西：**谷歌 GSM 设计框架**。并进行拆解： 1. Goal：降低用户在翻译任务中手动切换语言的成本 2. Signal：用户触发下拉菜单展开更多选项的行为减少 3. Metrics：下拉菜单人均触发次数 然后基于 **Signal** 进行反推： - 用户为什么需要通过下拉菜单手动切换语言？—— 当前槽位无法满足使用需求； - 为什么当前槽位无法满足使用需求？ —— 数量不够或者默认提供的选项不精准； - ... 我推理出来语言槽位的设计机会点有这两个：**槽位数量**和**默认值**。 ![GSM 框架拆解示意图：Goal 为降低手动切换语言成本，Signal 为用户通过下拉菜单切换语言的行为减少，Metrics 为外部语言槽位使用量增加，由 Signal 推导出两个设计机会：扩展槽位数量和修改默认值。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/05.png) ### 设计阶段 通过 GSM 框架拆解后，设计方向明朗了很多，逐个击破即可。针对这两个问题，我先会分析用户切换「源语言」和「目标语言」的使用情况： ![两组对比柱状图：用户切换「源语言」的人均次数（3.6 次切换、1.6 次下拉菜单触发）远低于「目标语言」（16.2 次切换、11.3 次下拉菜单触发），表明用户极少切换源语言，但频繁手动切换目标语言。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/06.png) 两份口径不同的图表都展示了一个很明显的结果：用户极少切换「源语言」，所以我有以下推断： 1. **源语言切换**次数非常少，代表默认选中的「自动识别」已经能满足绝大用户所需。 2. **目标语言切换**次数较多，而且有不少人是需要通过下拉菜单来切换语言（印证了默认槽位提供的语言选项无法满足工作所需）； #### 目标语言槽位改造 目前「目标语言」槽位数量是三个，我想着如果想要减少用户在下拉菜单里切换语言。多提供几个槽位会不会是一个比较好的方式。一个很简单的逻辑推断：**外部展示的选项更多且更精准，就有更多的用户无需通过下拉菜单来完成任务。** 基于这个逻辑，我也找了一些高频使用翻译功能的用户去调研了他们的使用场景和习惯。下面是一部分的内容： ![用户调研表格：客户维护岗需处理英语、越南语、泰语、阿拉伯语、日语、西班牙语；法务岗需处理英语、波兰语、瑞典语、西班牙语；KOL 运营岗需处理英语。高频用户普遍需同时应对多种外语。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/07.png) 调研得知高频用户里会存在一些角色是需要同时处理多种外语的。而目前仅提供三个槽位是肯定不够的，因为中文肯定会占用一个，剩下可用于外语的只有两个槽位。 所以基于数据分析、调研结论和界面可用空间考虑，我将槽位从 3 个扩展为 5 个。 槽位数量扩展了，那默认提供什么选项以及他们的顺序，是接下来要考虑的事情。我希望能够： > 提供对用户最有价值的 5 个语言选项。 最开始我只是简单的想到：“只要选**最多人用**的那 5 个语言就行啦！”。但是真正进行取数的时候才想到，其实是有好几个口径的，而且每张表的 TOP5 都不同。我陷入了沉思：这 5 个默认槽位到底该怎么选？ ![高频翻译语言 TOP9 排序对比表：按切换次数，中文简体居首；按翻译量，英语居首；按用户数，英语居首。越南语在切换次数排第 3 但用户数仅第 9，繁体中文切换次数排第 8 但用户数排第 3，单一维度存在明显偏差。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/08.png) 1. **取切换数 TOP5**：一个语言被切换到的次数多不代表进行翻译的次数多，无法确保覆盖面； 2. **取翻译量 TOP5**：可能出现一小撮人但大量使用的现象，这种语言覆盖面较窄（比如越南语）； 3. **取用户数 TOP5**：可能出现很多人切换到该语言，但真实翻译量很少的 “假热门” 现象（比如繁体中文）。 我觉得默认槽位里应该放既多人用，又会被高频使用的选项。这时仅看单一维度的数据是片面的，所以我想到可以用一个加权公式。 既然我两个维度都想兼顾到，那干脆公平一点：**用户覆盖面**和**真实翻译频率**各占比 50%。定义两个指标： ![加权公式示意图：权重 = 用户广度 + 转化效率。用户广度指使用该语言翻译的用户占比，转化效率指切换到该语言后产生真实翻译的比率，两者各占 50%。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/09.png) 1. **M1 用户广度**：使用该语言翻译的去重用户数 / 总用户数 2. **M2 转化效率**：该语言的真实翻译次数 / 该语言被选中次数 归一化后进行相加，取排名最高的前五位。这里我用了 Claude Code 来帮我计算，加权公式计算后最终的如下图。 ![加权公式（用户广度 M1 与转化效率 M2 各占 50%）计算后的语言排序结果：前五名依次为英语、中文简体、西班牙语、阿拉伯语、葡萄牙语，第六名起为越南语、中文简体、日语、意大利语，虚线分隔入选与未入选槽位。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/10.png) 前五个槽位默认值锁定为：英语、中文简体、西班牙语、阿拉伯语、葡萄牙语。我稍微调整了下排序，将西班牙语和葡萄牙语放一起，因为这两个都属于欧洲语言包。 #### 源语言槽位改造 目前「源语言」默认槽位是自动检测、英文、中文简体、中文繁体。 此前分析的结论是自动识别已经能满足绝大多数的翻译任务，所以这里的槽位我的设计思路与目标语言的槽位相反，这里我想的是简化。 由于「中文繁体」已被证明是假热门语言：源语言为中文繁体的翻译量排名第 8 —— 不值得占据一个默认槽位。于是我决定将其移除（槽位还在）。 #### 最终的优化动作 ![默认槽位改版前后对比：旧版目标语言槽位 3 个（中文简体、英语、中文繁体），新版扩展至 5 个（英语、中文简体、西班牙语、葡萄牙语、阿拉伯语）；源语言槽位数量不变，均移除中文繁体。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/11.png) 1. 目标语言的槽位：数量从 3 个扩展至 5 个，默认提供中文简体、英语、西班牙语、葡萄牙语、阿拉伯语。 2. 源语言的槽位：数量不变，去掉中文繁体的选项。 ### 数据验证 ![上线后 40 个工作日数据对比柱状图：外部槽位切换语言占比改版前 88.1%、改版后 88.7%，变化不显著；人均切换次数从 20.2 升至 27.3 次，提升约 35%。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/12.png) 数据显示在上线后 40 个工作日： 1. 用户在外部槽位切换语言的占比 88.7%。即每 10 次切换语言，有接近 9 次是发生在外部槽位。虽然新旧版从数值上看对比不明显，但旧版有大量脏数据 —— 同语言翻译 BUG 导致用户每次翻译后必须手动切换目标语言。 2. 通过外部槽位切换语言的人均次数从 20.2 上升至 27.3 人，提升了 35%。符合增加槽位暴露后带来更多直接切换的预期。 --- ## 二、选择语言面板 UI 交互优化 ![旧版语言面板为下拉列表，一屏仅显示约 7 个选项；外部翻译应用（搜狗翻译）采用字母索引网格布局，同屏可展示 20+ 语言，信息密度显著更高。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/13.png) ### 调研/思考阶段 其实无需过多的用户访谈、调取数据，只要用设计经验、对比竞品就能判断到改版前的选择语言框选择效率是低下的，最关键的问题是：打开面板后一屏只能看到 7 个语言选项，比其他同类型翻译产品少了很多。 既然用户触发了下拉面板，这意味着外部槽位的语言不能完全满足他们当时的需要，用户要在下拉菜单的全量数据里寻找目标语言。我要做的就是让用户在下拉面板进行选择时更高效。 具体要做什么优化点？我的设计目标是明确的，可以继续用 GSM 框架拆解： 1. Goal：降低用户在下拉菜单里切换语言的成本 2. Signal：用户在下拉菜单里的停留时间和行为减少 3. Metrics：下拉菜单停留时间 / 搜索功能使用率 / 搜索输入成本 然后基于 **Signal** 进行反推： - 用户为什么在下拉菜单里要停留这么久？—— 当前一屏展示数量少，需滚动查找； - 用户为什么在下拉菜单里行为这么多？—— 搜索功能做得不够方便。 我推理出来语言槽位的设计机会点有这两个：**面板坪效优化**和**搜索交互优化**。 ![GSM 框架拆解图：Goal 为"降低用户在下拉菜单切换语言的成本"，Signal 为"用户停留时间和行为减少"，Metrics 为菜单停留时间、搜索使用率、搜索输入成本，由 Signal 推导出两个设计机会：面板坪效优化和搜索交互优化。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/14.png) ### 设计阶段 #### 面板坪效优化 对于坪效优化，我的改动很直接：将下拉菜单布局改为**多列**、同时将高频语言选项前置，让其更容易被发现。 ![选择语言面板改版前后对比：旧版为单列下拉列表；新版改为三列网格布局，常用区展示翻译量 TOP 12 语言，全部语言区分第二层（TOP 13–24）和第三层（其余语言），同时搜索框支持拼音和语言代码输入。](https://lrdim.oss-accelerate.aliyuncs.com/blogimg/2026-07-14/15.png) 至于选项排布，我分为三层展示： 1. 第一层：属于**常用**模块，放翻译量 TOP 12 的语言； 2. 第二层：属于**全部语言**模块，放翻译量 TOP 13~24 的语言； 3. 第三层：按首字母排序放剩余的全部语言。 在排序的决策中，有三点额外的考量可以在此分享： 1. 根据使用数据显示，TOP 9 之后的语言使用量差异已经不大了，所以我这里就没有复用之前的权重公式，仅简单地按翻译量排序； 2. 中文、英语放在靠后的位置是因为这是在默认槽位里靠前的语言，比较难被替换走 —— 换句话说，在大多数情况下都会在槽位里出现，所以在下拉菜单里的位置不需要太靠前； 3. 在每一层我都有手动地微调了一些排序，让地理位置相邻的语言更靠近。 同时有一个额外的优化点：由于面板展开位置非右对齐 —— 会占用右边空间。所以让前端做了个识别浏览器边界自动偏移面板，确保用户在绝大多数情况下都能完整看到面板。