分享工作中的一个设计案例，文章多语言功能的设计我是如何从零开始做设计方案的，本文将分成三个阶段概述：

Part 1: 需求沟通及设计阶段

对外：沟通与功能效果设计

随着我们公司文章站点的流量不断增加，我们拓展了德语和法语等语言站点，而英文网站的流量较高，小语种编辑们希望可以通过英文文章的流量带动一下其他语言流量的增长，所以提出了希望添加文章多语言功能的需求。

我最直观的想法是，直接在文章某处地方显示语言切换按钮，因为这种做法最为普遍。

但是，后来通过德语编辑了解到，小语种文章基本都不是直接翻译英语的，它们的标题、内容、配图、排版等都会有所不同，站在用户体验的角度来说，我感觉直接显示语言切换按钮并不是一个好的解决方法。

在沟通需求的时候，德语编辑向我展示了谷歌搜索引擎用德语搜索的情况 (见下图)，图中最开始就有一段话的提示：“把搜索结果限制在德语的结果，你可以在语言设置里面修改你的搜索语言”。

我关注到的是，Google 直接给出有德语的提示，同时它看起来像是德语与英语的混合搜索结果。灵光一闪，我冒出了一个新的想法，我们也可以在页面上给用户一个还有其他语言版本的提示，然后把多语言的功能做成像常见的推荐文章的形式。于是，我根据自己的想法写了标题文案 (我更喜欢和习惯自己去思考应该放置什么样的内容，之后再找文案负责人按照大致意思重新编写更地道的表达) 以及绘制了下面的图 ↓↓↓

因为日常在解决问题时，看到很多的一些帮助文档多语言的切换都是放在末尾的，所以我把这个功能也放置在文章末尾，我直觉问题不大，并且这种设计放在末尾也是比较合适的位置。

这个设计方案没有听到反对的声音，但是他们对这个功能放置的位置提出了很大的异议：

有没有想过把多语言站点互链的位置放到文章开头上面（或是让读者一打开就可以看到的地方），而不是像当前那样放到文末（因为放到文末的话读者需要翻到最下面才能看到该文章有不同语言版本

我也觉得可以根据 accept-language 和 ip 来弹出气泡或者像接受 cookies 那样的小框告诉读者有其他版本

如果是这样那其实这个功能没有存在的必要啊。读者英语都看完了为什么还要看一遍重复的内容？就因为是母语吗?

感觉放在末尾的话读者都读完了应该不会有很大欲望想看了，比如我搜到的英语结果，读完之后发现有德语，就都看完了也不是很想去看了叭。

这些建议我最终都没有采纳，原因大致可以总结为几点：

  1. 首屏是一个很重要的位置，而这个功能占据的空间不算小，我对它的定位更像是推荐文章的作用，只是作为文章的附加存在的，它不值得我将其放置在首屏这种重要的位置。
  2. 读者通过 Google 搜索进来，通常都代表着这就是用户要的语言和结果 (起码占比有 80% 以上)，或者用户可能根本不太在意是否是自己的母语，同时，我相信 Google 搜索引擎的算法是足够成熟的，它可以把用户熟悉 (或想要) 的语言推荐给用户。我不想为了满足少量用户的需求而影响了绝大部分用户的体验感受。
  3. 通过 IP 判断用户的国家语言，自行跳转或弹出窗口，提示用户还有其他的语言版本也许是可行的，但是，这个功能还不成熟，我不知道用户对于多语言的需求是否强烈。所以，我并不想过多浪费我们的开发资源在这些未确定的事情上，用最简单的形式快速上线才是比较合理的状态。
  4. 添加这些链接可以丰富我们的页面内容，丰富文章内链。该功能是以推荐文章的形式存在的，而在之前 Google Ads 提供的推荐文章功能的测试报告中有提到，它的推荐文章功能让用户访问页面的数量增加了 9%，用户在网站上的停留时间增加了 10%。因为有这样的一个数据参考，我可以合理假设多语言以这种形式存在同样有其价值和意义的。

对内：后台管理设计

对外展示给用户的设计有了，那么这个功能对内的设计要如何处理呢？也就是说我们如何让作者将这些多语言关联到对应的文章上，这就是接下来需要思考的问题了。

这里不展开过多的细节描述，大致有以下几点思考是值得提及的，因为这些类似的考究日后也许会对阅读这篇文章的人有所帮助，然后将其应用到其他的项目设计上。

  1. 是否会存在什么问题？这个问题基本面对任何设计方案都是需要思考的。
    通过需求沟通了解到，一篇文章可能有对应多篇语言文章的情况存在，如果要满足一对多的问题，那么势必会增加项目复杂度和周期，基于初始阶段的简单性原则，我毫不犹豫地砍掉了。还有一些更偏技术性的问题，比如作者修改了链接而这个管理后台的链接是否还能正常访问等等一些实现逻辑则留给开发去思考和处理。

    注意：像一些偏专业技术性的问题设计师这方面专业认知水平有限，其实无需提出具体的技术解决方案，这留给技术更专业的开发者去思考和规划，你只需向他们沟通问题和提出自己的疑惑和需要即可。不然可能就会导致一个情况：可能原本有更好的技术解决方案，或者实现复杂耗时会偏长，根据 2/8 法则重要程度等，可以砍掉不必花时间去处理的细节问题，判断失误就容易造成不必要的浪费。如果合作的是一个有足够开发经验和项目管理经验的人，他可以向你提出更好的建议和反馈来弥补，但是如果合作的是没有足够经验的人，那么，导致对方完全按照你的解决思路来处理可能就会耗费很多时间。
  2. 是否可实现自动化或者方便作者自己维护管理？
    这些文章语言的链接都是完全不一样的，经过了解，我们很难通过技术手段实现自动匹配，所以需要提供一个输入框，让作者自己输入对应的文章链接。为了方便日后的维护和管理，我最终决定添加一个统一的管理入口。

因为这是我们内部人员自己使用的管理后台，UI 好看与否并不重要 (我就是懒，理直气壮.jpg)，所以为了节省时间，以及结合前面的一些考虑，我最终绘制了这个功能的草图布局，而没有进行 UI 设计。

Part 2: 项目推进阶段

我心里会大致有一个直觉的判断，这个功能直接上线是没有什么问题的，但实际上，我并不知道它最终会如何表现。在具有不确定性的环境中，首要的问题不是直接埋头苦干，而是尽可能通过一些简单的方式和手段来降低这种不确定性，从而避免造成资源的浪费。降低这种不确定性的方式有很多种，我们可以通过找更有经验的人去探讨或者经过大量的资料收集看是否有一些类似的研究案例，或通过 A/B 实验的方式进行测试。

我直接选了一篇高流量的文章，然后使用 Google Optimize (GO) 进行了 A/B 测试。因为使用 GO 设置这个实验预估最多只需花费半个小时的时间，代价小成效高。

实验结果表明，添加多语言的表现略好，但是并没有达到显著性的差异，对转化率没有影响。而鉴于添加多语言能增加小语种文章曝光率，丰富文章内链等 SEO 的好处，我最终决定按照现有的方案添加这项功能。

Part 3: 上线后回顾和优化

在多次跨部门沟通，推动功能上线后，我们选取了 30 篇文章进行多语言的关联，并进行为期 1 个月的观察。从最终观察到的情况来看，它并没有带来什么负面影响，小部分文章的用户会使用此功能进行语言的切换，从 Google Analytics 的数据上看，单篇文章的多语言点击率在 5% 以下，整站文章多语言的点击率在 0.01%

另外，我留意到一个 Google 搜索的现象，比如，输入英德混合的关键词搜索，出现的是英文站点的文章，但是，描述的地方会显示有我们添加的德语标题，如下所示 ↓↓↓

于是，我对原有的功能设计进行了迭代优化，添加 meta description 显示更多的内容，优化后的设计如下所示 ↓↓↓

这次的测试我把上一次的版本也拿过来同时做了对比测试，从 GO 的实验结果表现上看，依然没有达到显著性的差异，显示标题和显示标题&描述的版本表现不相上下，而没有多语言的版本胜率不足 1%，而从前面 Google 搜索的角度方面考虑，带描述的版本表现可能会更好，最终考虑使用 Variant – Display meta description 版本。

在上线了这个迭代版本后，观察到整站的多语言点击率提升到了 0.03%，此功能的设计迭代暂时告一段落。