您肯定见过它。也许您没有刻意留意，但您肯定见过它。那个要求您验证自己是真人用户的小部件。访问网站之前，需要进行整页安全检查。如果您经常上网，应该看到过 Cloudflare Turnstile 小部件或质询页面，而且次数可能多到数不清。
Turnstile 小部件，数百万个网站的常见情况
我们说很大一部分互联网流量都离不开 Cloudflare 平台，这是真心的。Cloudflare Turnstile 小部件和质询页面每天的服务次数高达 76.7 亿次。这不是笔误。数十亿次。这可能是互联网上最常见的用户界面。
而这也伴随着巨大的责任。
设计一款吸引数十亿用户关注的产品，不仅充满挑战，而且需要采用截然不同的方法。每一个像素、每一个单词、每一次交互都必须满足不同用户的需求：这些用户可能是日本乡村的祖母、圣保罗的青少年、柏林的视障开发人员，以及拉各斯忙碌的高管。同时服务所有这些用户。在他们感到沮丧的时候。
今天，我们将分享重新设计 Cloudflare Turnstile 和质询页面的故事。这个故事分为三个部分，由三人讲述：一是影响决策的设计流程和研究 (Leo)；二是以空前规模部署变更的工程挑战工程难题 (Ana)；三是这对数十亿用户的可衡量的影响 (Marina)。
首先，介绍我们如何从设计角度解决这个问题。
说实话，没人喜欢系统要求证明自己是真人用户。您知道您是真人。我知道自己是真人。似乎唯一不相信这一点的是那个挡在您与您尝试访问的网站之间的小部件。最好的情况下，这只是一个小小的不便。最坏的情况下会发生什么呢？您可能气得想把电脑扔出窗外。我们都经历过这种情绪。没有人会责怪您。
Turnstile 集成到登录流程
鉴于世界开始逐渐接受看似不可避免的 AI 革命，安全验证需求只会与日俱增。Cloudflare 发现，机器人攻击显著增加。为此，企业正在加大投资来部署安全措施。这意味着，更多最终用户需要更频繁地接受更多质询。
数据说明了一切：
2023 年：每天 21.4 亿次
2024 年：每天 30 亿次
2025 年：每天 53.5 亿次
也就是说，安全检查次数平均同比增长 58.1%。安全检查增多，则意味着最终用户感到沮丧的可能性更大。集成这些验证系统来保护自身及其客户的公司越多，用户在某个场景获得糟糕体验的可能性就越高。
我们意识到，是时候认真审视我们的旗舰产品并扪心自问：对于获得这种体验的数十亿用户而言，我们是否做了正确的事？我们是否履行了帮助构建更好的互联网的使命，不仅是更安全，而且是更人性化的互联网？
我们发现，答案是：我们可以做得更好。
在重新设计任何产品之前，我们需要了解现有的产品。首先，我们对 Turnstile 与质询页面的每一种状态、每一个错误消息和每一个交互进行了全面审核。
我们发现，情况并不理想。
Turnstile 小部件中的状态不一致。多种状态，没有统一的方法
各种不一致非常明显。我们没有采用统一的方法来应对众多不同的错误场景。一些提示消息过于冗长且技术性过强（例如“您的设备时钟设置错误”或“此质询页面被中间服务器意外缓存且不再可用”）。另一些消息则过于模糊，毫无帮助（例如“已超时”）。视觉语言形式各异：不同的布局、不同的层次结构、不同的语气。
我们还仔细检查了在线收到的反馈，包括社交媒体、支持工单、社区论坛，我们认真阅读了所有内容。用户的沮丧之情显而易见，而很多问题原本可以避免。
以我们的反馈机制为例。我们为用户提供了反馈选项，例如“小部件有时故障”与“小部件总是故障”。但两者之间到底有何实质区别呢？用户应该怎样判断小部件的故障频率呢？我们要求用户在他们最沮丧的时刻解读模棱两可的选项。留下的解读空间越大，反馈的实用性越低；在各种社交频道上看到的用户沮丧体验也越多。
之前的反馈界面：“小部件有时故障”与“小部件总是故障”有什么区别？
质询页面（当检测到可疑活动或网站所有者启用了更高级安全设置时，显示的整页安全阻止提示）也存在类似的问题。有些状态令人困惑。有些状态使用了过多技术术语。许多提示未能在用户最需要的时候提供可执行的指导。
质询页面上的状态不一致。多种状态，没有统一的方法
这次审核我们感到惭愧。但它也让我们清楚地了解了需要重点关注的方向。
为了改善体验，我们首先需要了解用户可能选择的每一条路径。什么是理想路径？是否存在理想路径？哪些路径会导致用户越来越沮丧？
绘制完整的用户旅程图：从初次遇到各种错误场景开始，并进行情绪跟踪
这需要真正的跨职能合作。我们与像 Ana 这样的工程师紧密合作，她了解各种极端情况的技术细节；也与产品团队的 Marina 合作，她不仅了解产品的工作原理，还了解用户的产品使用感受，包括我们在网上看到的爱与恨。
Cloudflare 拥有一些最优秀的机器人防护专家。但智慧与清晰不是一回事。技术复杂性与用户易用性之间存在微妙的平衡。只有当这两者完美融合时，我们才能以真正易于用户理解的方式传达信息。
关键在于：信息必须对所有用户有效。任何年龄的人。任何身心能力的人。任何文化背景的人。任何技术水平的人。这就是规模化设计的真正含义：不能忽视极端情况，因为在如此规模上，它们已不再是极端情况。
用户体验设计中最具影响力的书籍之一是 Steve Krug 撰写的《Don't Make Me Think》。核心原则非常简单：用户试图解读、理解或解码界面的每一刻，都会产生一次摩擦。而摩擦，尤其是在令人沮丧的时刻，会导致用户放弃。
我们通过审核发现，要求用户考虑的太多。在不同状态下，不同的信息占据了用户界面的相同空间。缺乏一致的视觉层次。在 Turnstile 中遇到错误状态的用户，可能会发现此类信息的位置与其在质询页面上找到的信息位置完全不同。
我们做出了一个基本的决策：采用统一的信息架构。
视觉图显示了统一的信息架构，在 Turnstile 小部件与质询页面中保持一致的结构
如今，Turnstile 与质询页面都遵循相同的结构模式。相同的视觉层次。相同的操作、说明文本和文档链接位置。
这是否限制了我们的设计方案？当然。我们不得不拒绝许多不符合该框架的创意。但限制并不是优秀设计的敌对面，反而往往是优秀设计的最佳伙伴。通过限制设计方案，我们可以更深入地研究真正重要的细节。
对用户来说，好处显而易见：他们无需重新学习用户界面中每个部分的含义。错误状态看起来是一致的。帮助链接始终位于同一位置。一旦理解了一种状态，就会理解所有状态。这可以最大限度地降低认知负担，正是安全验证过程中应有的水平。
在重新设计数十亿用户会看到的界面时，您如何承担自身责任？测试。海量测试。
我们招募了来自 8 个不同国家/地区的 8 位参与者，刻意寻求参与者的年龄、数字素养和文化背景方面的多样化。我们并不是为了寻找精通技术的早期采用者，而是希望了解重新设计后的界面如何适用于每一位用户。
我们的方法非常严谨：参与者既体验了现有功能，也体验了改进方案，但他们并不知道哪个是“旧版”，哪个是“新版”。我们通平衡了两种方案的呈现方式，以消除偏见。我们不仅测试了新创意，还挑战了最初关于哪些方面需要改进的假设。
A/B 测试中测试的两个不同 Turnstile 版本
一种假设：我们是否应该与竞争对手保持一致？大多数验证码提供商在所有状态下都会显示“我是真人”。我们使用不同的内容，首先显示“验证您是真人”，然后“正在验证…”，然后“成功”！
是否使事情过于复杂化？我们进行了直接对比测试。
我们的方法以压倒性优势胜出。对于交互状态，“验证您是真人”获得了 5 分（满分 8 分），而“我是真人”只得了 3 分。对于验证状态，差距更加显著，7.5 分对比 0.5 分。用户想要知道正在发生什么，而不仅仅是被告知发生了什么。
用户测试结果：用户非常喜欢我们的方法，而不是竞争对手的设计风格
这个实验最终没有作为一项功能发布，但它非常有价值。它让我们确信，我们并不是为了标新立异而与众不同。有些方面已经做得很好。
研究发现，我们在四个方面未能满足用户需求：
提供帮助，而不是繁琐的流程。当用户遇到错误时，我们提供了“发送反馈”选项。在测试过程中，他们感到困惑不解。“我应该把反馈发送给谁？网站？Cloudflare？我的互联网服务提供商？”更重要的是，我们发现了一个根本的问题：在用户感到极度沮丧时，他们并不想提交报告，而是希望解决问题。我们将“发送反馈”替换为“故障排除”，这个简洁的词语承诺采取行动，而不是启动繁琐的流程。
有问题的“发送反馈”提示词：用户不知道向谁发送反馈
提醒注意，而不是发送警报。我们使用了大量红色背景，用于提示错误。测试中“不假思索”的反应：参与者认为自己操作失败，感到有心无力。即使是可以通过重试解决的简单问题，用户也会往最坏的方面想，然后放弃。饱和度极高的红色并没有传达“这里有一些问题需要解决”的信息。它传达的信息是：“你操作失败，且无能为力。”解决方案：仅图标使用红色，文本或背景切勿使用红色。
演变过程：从使用红色显示不清晰的错误状态描述，到使用中性色文本进行更清晰、简洁的错误信息沟通。
简洁易读，而不是冗长难懂。我们尝试保持透彻周全，从技术细节详细解释错误。结果却适得其反。非技术用户觉得难以理解。技术用户根本不需要这些解释。每个人都试图在小部件的狭小空间内阅读这些内容。我们得到的教训是：少即是多，尤其是在空间有限、压力大的情况下。
人人可用。我们通过审核发现，某些页面使用了 10px 字体。灰色文本虽然在技术方面符合 AA 级标准（普通文本至少 4.5:1，大文本至少 3:1），但实际阅读起来却比较困难。如果服务对象是整个互联网用户，“技术上符合标准”是远远不够的。
我们制定了明确的目标：满足 WCAG 2.2 AAA 级标准，这是最高且最严苛的 Web 无障碍访问合规要求，旨在让包括重度残障人士在内的最广泛的用户群体均可访问网站内容。在整个重新设计过程中，当视觉一致性与可读性发生冲突时，我们始终优先考虑可读性。每一次都是如此。
这不仅仅局限于视觉功能方面。我们的设计面向屏幕阅读器用户、仅使用键盘导航的用户，以及色觉障碍人士，这超越了自动化合规工具的检测范围。
无障碍访问设计不仅要考虑各种障碍人士的需求，而且还涉及到语言。简洁的英语内容，翻译成德语后可能显得冗长。言简意赅的西班牙语内容，翻译成日语后可能模糊不清。支持 40 多种语言迫使我们进行彻底的简化。现在，相同的“无法连接到网站/故障排除”模型消息，适用于英语、保加利亚语、丹麦语、德语、希腊语、日语、印尼语、俄语、斯洛伐克语、斯洛文尼亚语、塞尔维亚语、菲律宾语等多种语言。
重新设计的错误状态，支持 12 种语言；即使文本长度不同，布局也保持一致
所以，我们最终发布的成品是什么？
首先，我们介绍一下哪些部分没有改动。合适的路径（“验证您是真人”→“正在验证...”→“成功！”）测试结果非常好。用户了解每个阶段发生的情况。我们之前担心每种状态的不同内容可能会使消息过于复杂，但实际上，这反而成为了我们的竞争优势。
合适的路径：验证您是真人→正在验证→成功！这些状态测试良好，基本保持不变
但对于需要改进的状态，我们根据所有反馈进行了重大修改。
我们大幅减少了处于错误状态的文本数量。现在，我们不再提供冗长的解释说明，例如“您的设备时钟设置错误”或“此质询页面被中间服务器意外缓存且不再可用”，而是显示：
清晰、简单的状态名称（例如：“设备时间不正确”）
醒目的“故障排除”链接
仅此而已。详细的指南现在位于一个专门的模态框屏幕，该屏幕支持用户根据需要打开，让其拥有足够的空间来真正阅读并按照故障排除步骤进行操作。
故障排除模态框：在用户需要时提供详细的指南，且不会使小部件显得杂乱无章
故障排除模态框会提供上下文信息（“当您的设备时钟或日历设置不准确时，会发生此错误。若要完成网站的安全验证流程，您的设备必须设置为您所在时区的正确日期和时间。”）、编号列举的尝试步骤、文档链接，以及（仅在用户尝试解决问题后）向 Cloudflare 提交反馈的选项。首先获取帮助，然后提交反馈。
现在，每种状态的对比度和可读性均符合 WCAG 2.2 AAA 级标准。字体大小已设定最小值。交互元素清晰可聚焦，并且可供屏幕阅读器正确朗读。
无论用户遇到的是紧凑的 Turnstile 小部件，还是完整的质询页面，信息架构现在都保持一致。相同的层次结构。相同的布局。相同的心理模型。
如今，质询页面采用简洁的设计结构：顶部是网站名称和收藏夹图标，下方是清晰的状态信息（例如“验证成功”或“您的浏览器版本过旧”），以及可操作的指导说明。不再有密密麻麻的橙色或红色文字。不再有晦涩难懂、缺乏上下文的技术术语。
重新设计的质询页面提供清晰的故障排除说明。
每一则消息均已在 40 多种支持的语言中进行了测试。我们的流程包含三层验证：
设计团队进行初步的设计审核
由合格供应商提供的专业翻译
由 Cloudflare 母语员工进行最终检查
这不仅关乎翻译的准确性，也是为了确保视觉设计在不同语言的内容长度存在显著差异的情况下依然有效。
最终成果是安全验证体验更清晰、更易用、更流畅，而且至关重要的是，同样安全。我们没有为改善体验而牺牲安全保护。我们证明了良好的设计与高安全性并不冲突。
左侧是重新设计的 Turnstile 小部件，右侧是重新设计的质询页面
但是，设计体验只是成功的一半。将其分发给数十亿用户？这正是 Ana 的用武之地。
有人可能会说，作为前端工程师最困难的部分是将 div 元素居中。实际上，真正的挑战往往隐藏在更深层次，尤其是在深入接触平台原语的情况下。使用原生 API 构建互联网基础设施的关键部分，会迫使人以不同的视角思考 UI 开发、权衡取舍以及长期可维护性。
在我们的案例中，我们使用 Rust 处理 Turnstile 小部件和质询页面的 UI。这项决策带来了跨平台的安全性和一致性方面的显著优势，但也增加了前端的复杂性。许多前端工程师已经习惯了采用符合人体工程学的 React 等现代框架，在这些框架中，常见的 UI 交互几乎都是免费。使用 Rust 意味着即使是简单的交互，也需要使用更低级别的构建（例如 document.getElementById、createElement 和 appendChild。
此外，与基于 JavaScript 的框架相比，编译时间和严格的检查自然会减缓 UI 的快速迭代。由于工具生态系统仍在不断演变，调试也变得更加复杂。这些限制促使我们在 UI 开发过程中更加慎重、深思熟虑，最终也更加严谨。
那些最初看似微小的视觉调整，例如内边距调整或对齐方式更改，很快就暴露了一个更大的难题：如何进行内容国际化。
翻译完成后，我们必须确保内容在 38 种语言和 16 种不同的 UI 状态下仍然可读且可用。仅文本长度的变化就需要做出谨慎的设计决策。有些译文的长度可能比英文长 30% 到 300%。像“Stuck?”这样的简短英文字符串，它的印尼语版本会变成“Tidak bisa melanjutkan?”，德语版本会变成“Es geht nicht weiter?”，这会极大地改变布局要求。
支持从右到左显示的语言，这又增添了一层技术复杂性。支持阿拉伯语、波斯语或法尔西语，以及希伯来语，不仅仅只是翻转文本方向那么简单。整个布局必须镜像显示，包括对齐方式、导航模式、方向图标和动画流程。许多元素的设计理念隐含从左到右显示的假设，因此，我们必须重新审视这些元素，使其真正实现双向显示。
有序列表也需要特别注意。并非所有文化都使用西方的 1、2、3 编号系统，硬编码数字序列会让界面显得格格不入或不正确。我们采用了符合本地规范的编号系统和完全可翻译的列表格式，确保每种语言中的排序都自然流畅且符合文化习惯。
随着我们开始在反馈报告中列出行动要点，正确性变得愈发重要。需要正确渲染所需的每个操作，触发正确的流程，以及在各种状态、语言和极端情况下表现一致。
为了实现这一目标，我们投入了大量资源进行测试。单元测试帮助我们独立验证逻辑，而端到端测试则确保新的状态和语言在实际场景中能够按预期正常运行。这种测试基础让我们有信心安全地进行迭代，防止回归，并确保反馈报告对用户来说始终可靠且实用。
最初的一系列技术限制，最终转化为构建更强大、更具包容性且经过充分测试的 UI 系统的契机。处理减少抽象层级和更深入了解浏览器底层原语的过程，迫使我们重新思考了设计元素假设，改进了内容国际化策略，以及提高了整体质量标准。
最终成果不仅是一个有效的解决方案，更是一个值得信赖的解决方案。正是这种信任让我们能够不断改进，即使是在将 div 元素居中显示是最简单的设计优化的情况下。
我们认真对待为数十亿用户进行设计的艰巨责任。在如此庞大的规模下，利用可衡量的数据来了解设计方案的实际影响至关重要。在准备推出这些变更的过程中，我们重点关注五个关键指标，以判断我们是否真正成功地让互联网上最常见的用户界面更加人性化。
我们的主要目标是质询完成率：它是指已发出的质询成功完成的百分比。通过弃用“中间缓存”之类的技术术语，转而使用“设备时间不正确”等简单易懂、可操作的标签，我们预计质询完成率将显著提升。更高的质询完成率并不意味着我们对机器人的验证更宽松；而是意味着我们将消除那些无意中导致合法真人用户出错的障碍。
用户在质询页面上花费的每一秒，都让他们无法获得真正所需的信息。我们的研究表明，用户看到一大堆红色文字时，往往会因为选择太多而不知所措。凭借全新的简洁易读、中性色设计，我们将跟踪完成时间，以确保用户能够在几秒钟内识别并解决问题，而不是花费几分钟。
过去，我们使用大量“饱和红色”引起了用户的强烈抵触情绪：他们认为自己操作失败，于是直接放弃。如今，我们仅保留图标使用红色并采用统一的信息架构，旨在降低放弃率。我们希望用户能够主动单击“故障排除”，而不是感到无能为力而放弃。
从产品角度来看，一项重大改进是我们推出了新的故障排除模态框。通过直接在小部件内提供清晰、编号的步骤，我们将自助服务支持功能集成到用户界面中。我们预计，这将显著降低客户和内部团队的支持工单数量。
我们知道，极少人喜欢接受安全质询，但不应因质询内容令人困惑而遭致厌恶。我们将监测社区论坛、反馈报告和社交频道的社交情绪，以了解用户对话是否会从“这个小部件坏了”转变为“我遇到了问题，但我已经解决了”。
作为产品经理，我的目标通常是实现无形的安全，最好的质询是用户看不见的质询。但如果必须显示质询，它应该是助手，而不是保安。重新设计证明了 AAA 级无障碍访问与高安全性标准并不冲突，二者是同一事物的两面。通过统一 Turnstile 与质询页面的架构，我们建立了一个基础，使我们能够以前所未有的速度迭代，并以更人性化的方式保护互联网。
此次重新设计是一个基础，而非终点。
我们将继续监测用户如何与新体验进行交互，并致力于根据了解到的情况进行迭代。我们在新设计中内置的反馈机制旨在真正帮助用户进行故障排除，而不仅仅是让他们报告问题，这将为我们提供前所未有的、更丰富的见解。
我们也会密切关注安全态势的演变。随着机器人攻击变得越来越复杂、AI 不断模糊真人行为与自动化行为之间的界限，验证的难度只会越来越大。我们的任务是始终提前防范，在不影响用户体验的前提下，不断提高安全性。
如果您在使用新版 Turnstile 或质询页面时有任何反馈，请随时告知我们。您可以通过 Cloudflare 社区论坛或使用产品内置的反馈机制联系我们。