谷歌翻译为什么不自动翻译页面（几亿人都在用的谷歌翻译网页版）

@C7210 ：这是一篇来自 Google Translate 团队设计师的改版经验分享。

Google Translate改版经验谈

2018 年底，我们上线了基于响应式布局和 Material Design 打造的全新网页版本 Google Translate。

鉴于 Google Translate 在全球拥有的庞大用户量，我们从一开始就知道必须为「改版厌恶症」做好准备。很多文章对这一话题进行过探讨，譬如通过什么策略才可以尽可能减少用户对于产品改版的负面反馈。但对于 Google Translate 这种量级的产品，很多经验也只有在实际项目过程中才能获取。以下就是我在这次改版当中学到的最重要的一些东西。

以用户为镜

如果你了解过「改版厌恶症」，那么对于下面这张图表可能并不陌生。

图中所展示的是产品改版可能带来的不同类型的结果。不过显然，你无法通过图表对你的改版结果进行预测。对于改版结果缺乏明晰的认知与控制力，这使我在项目初期感到无所适从。但随着每一次试验性的迭代，我逐渐意识到，我们的用户一直在通过他们的实际行为与反馈来指导着我们的前进方向。

在改版试验阶段，用户会向我们提交反馈，各类意见褒贬不一，有些读起来并不舒服，但我们还是花费了大量的时间去阅读，然后在内部报 bug 或是调整设计方案。譬如在读过一些反馈意见之后，我们才发现，我们对于 tab 次序的调整严重影响了一部分重度用户的工作效率，于是我们立刻回滚了方案。此外，我们了解到很多用户在实际场景中都需要看到更多的信息，于是我们在接下来的迭代方案中提升了页面的信息密度。

作为设计师，我们总会希望一次性将最完美的设计方案呈现给用户。然而对于产品设计而言，分阶段进行试验，通过用户的真实反馈进行校验和迭代，才是更为有效的方式。一旦在这方面建立起成熟的机制，你的用户就会成为产品设计最有效的指引。

定性研究中的陷阱

可用性测试可以帮助你发现设计当中的重大问题，为设计方案带来多方面的评估。通常，这类测试的规模都不大，每次的被测对象不超过十名。在测试期间，你总会忍不住想要问被测对象更喜欢哪个设计方案，但这种问题的结果往往并不可靠，甚至有可能将你引向歧途。

我们在 Google Translate 改版过程中做过很多轮的定性用研，以此来发现和改正先前设计当中的一系列可用性问题。期间，我们也会征询被测对象对于新旧版本设计方案的倾向性，绝大多数人都会选择新版方案。但我们对这类倾向性始终保持谨慎，不想将其作为设计决策的直接依据。

事实证明，新版方案第一次上线测试时，用户们通过实际行为所表达出的倾向性，并不像我们在定性研究中所了解到的那样高度一致地倾向于新版方案。

A/B测试，可靠的伙伴

我们希望新版 Google Translate 的页面具有更高的色彩饱和度。

在早期迭代当中，我们使用了一系列色彩丰富的图标，这些图标在我们的移动端 app 当中的表现不错。但通过 A/B 测试，我们发现这些图标在网页版本中的表现并不理想，于是最终仍采用了简洁的 Material Design 风格图标。

此外，我们还曾经尝试将翻译后的文字呈现在蓝色背景当中，就像我们在移动端 app 当中做的那样。而当译文长度超过一定的篇幅时，我们则会将底色改为浅灰，使其更易阅读。

但是我们的一些设计师始终对蓝色底色的方案抱有质疑，于是我们决定通过 A/B 测试来进行验证。其中 A 方案采用了前文描述的模式（根据译文篇幅调整内容字色与底色），B 方案仅使用浅灰底色。测试结果很明确，A 方案下的用户使用频次明显降低了。

或许对于网页版的 Google Translate 来说，人们真的不喜欢饱和度如此之高的视觉风格。不过我们也在其他地方继续尝试着色彩更为丰富的元素，例如在运营内容卡片或空状态页面中使用的插图等等。

总结

产品改版通常会带来很大的挑战，特别是当你无法预先了解人们可能产生怎样的反应时。通过这次 Google Translate 改版，我所学到的最重要的一课，就是你必须将用户可能产生的反馈视为设计过程的重要组成部分，而非试图去控制或避免那些不确定的要素。

既然产品以用户为本，那么就让用户来帮助我们更有效地进行设计。认真规划每一次的迭代试验，在足够大量的样本当中进行测试，获取真实用户的反馈意见，进而提炼出最有价值的数据与信息，用以制定设计决策。