你一定見過它。或許當下沒有意識到，但你一定見過。那個請你驗證身分的小工具，或是造訪網站前會出現的整頁安全檢查。只要在網際網路上待過一段時間，肯定遇到過 Cloudflare 的 Turnstile 小工具或驗證頁面——次數多到數不清。
Turnstile 小工具——數百萬網站上熟悉的身影
當我們說網際網路的很大一部分都在 Cloudflare 背後運作，這可不是誇大其詞。我們的 Turnstile 小工具和驗證頁面，每天被載入的次數高達 76.7 億次。你沒看錯，真的是「億」這個單位。這可能是網際網路上最常被看見的使用者介面。
而這樣的規模，也代表著巨大的責任。
設計一個每天有數十億人次使用的產品，挑戰不僅僅在於技術——更需要一套截然不同的思考方式。每一個像素、每一句文案、每一次互動，都必須能讓日本鄉下的老奶奶、聖保羅的青少年、柏林一名有視覺障礙的工程師，以及拉哥斯一位分秒必爭的主管，都能順利使用。這一切必須同時成立，而且是在使用者可能感到煩躁的時刻。
今天，我們想分享 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 版本
其中一個假設是：我們是否應該跟競爭對手保持一致？大多數 CAPTCHA 廠商在所有狀態下都使用「I am human（我是人類）」這類文字。而我們則使用不同的內容——先是「Verify you are human（請驗證您是人類）」，接著是「Verifying...（驗證中…）」，最後是「Success!（成功！）」。
我們是否把事情複雜化了？我們進行了直接的對比測試。
結果，我們的做法明顯勝出。在互動狀態下，「Verify you are human」得到了 8 分中的 5 分，而「I am human」只得到 3 分。在驗證中的狀態下，差距更為懸殊——7.5 分對上 0.5 分。使用者想要知道正在發生什麼事，而不只是被告知他們是什麼。
使用者測試結果：用者明顯偏好我們的做法，而不是競爭對手風格的設計
這個實驗最終沒有作為一項功能上線，但它帶來的收穫是無價的。它讓我們有信心，我們不是為了不同而不同。有些東西，原本就是對的。
研究揭露了我們在四個方面讓使用者失望了：
提供協助，而非官僚程序。當使用者遇到錯誤時，我們提供的是「Send Feedback（傳送回饋）」。在測試中，他們感到困惑。「我要把這個發送給誰？這個網站？Cloudflare？我的網際網路服務提供者？」更重要的是，我們發現了一個根本問題：在挫折感達到頂點的時刻，人們並不想提交報告——他們想解決問題。因此，我們用「Troubleshoot（疑難排解）」取代了「Send Feedback（傳送回饋）」——這個詞承諾的是採取行動，而不是繁瑣程序。
有問題的「Send Feedback」提示：使用者不清楚自己是在向誰提供回饋
引起注意，而非驚慌。我們過去在顯示錯誤時大量使用紅色背景。測試中的反應非常直接——參與者感覺自己失敗了，感到無能為力。即使是那些重試就能解決的簡單問題，使用者也會做出最壞的假設並放棄。高飽和度的紅色傳達的不是「這裡有些問題需要處理」，而是在說「你已經失敗了，而且無能為力」。改進方式：紅色僅用於圖示，絕不用於文字或背景。
演進過程：從使用紅色、錯誤狀態描述不清的畫面，轉變為使用中性色文字、傳達更清晰簡潔的錯誤訊息。
易於掃讀，而非冗長。我們曾試圖做到詳盡，用技術細節解釋錯誤。結果適得其反。非技術背景的使用者感到被排擠。技術背景的使用者則不需要這些。每個人都試圖在小工具的狹小空間內閱讀這些文字。學到的教訓是：在壓力情境與有限空間中，「少即是多」。
讓所有人都能存取。我們的稽核發現，某些狀態下使用了 10px 的字體。有些灰色文字雖然技術上符合 AA 標準（一般文字至少 4.5:1，大型文字至少 3:1），但在實際使用中卻難以閱讀。當你的服務對象是整個網際網路世界時，「技術上符合標準」並不夠好。
我們設定了一個明確的目標：達到 WCAG 2.2 AAA 標準——這是網頁無障礙規範中最高、最嚴格的等級，旨在讓最廣泛的使用者（包括重度身心障礙者）都能存取內容。在整個重新設計過程中，每當視覺一致性與可讀性發生衝突，可讀性永遠優先。
這不僅限於視覺方面。我們也為使用螢幕閱讀器的使用者、純鍵盤操作者，以及有色覺差異的人進行設計——超越了自動化無障礙檢測工具所能捕捉的範圍。
而且，無障礙不僅關乎身體機能——也關乎語言。適合英文的長度，在德文中會溢出；在西班牙文中簡潔的表達，在日文中可能顯得模糊。支援超過 40 種語言，迫使我們必須大幅簡化。同樣的「Unable to connect to website / Troubleshoot（無法連線到網站/疑難排解）」模式，現在能夠適用於英文、保加利亞文、丹麥文、德文、希臘文、日文、印尼文、俄文、斯洛伐克文、斯洛維尼亞文、塞爾維亞文、菲律賓文以及其他更多語言。
重新設計後的錯誤狀態，以 12 種語言呈現——儘管文字長度不同，但版面配置保持一致
那麼，我們最終實際推出的成果是什麼呢？
首先，來談談我們沒有改變的部分。順利路徑——「請驗證您是人類」→「驗證中...」→「成功！」——在測試中表現得極其出色。使用者能清楚理解每個階段的狀況。我們曾擔心每個狀態使用不同內容可能過於複雜，但這實際上成為了我們的競爭優勢。
順利路徑：「請驗證您是人類」→「驗證中...」→「成功！」這些狀態測試結果良好，因此大致保持不變
但對於那些需要改進的狀態，我們根據學到的一切，做出了重大的改變。
我們大幅減少了錯誤狀態中的文字量。不再顯示像「您的裝置時間設定不正確，或者此驗證頁面意外地被中間層快取，目前已無法使用」這類冗長的解釋，現在我們只顯示：
一個清晰簡單的狀態名稱（例如：「裝置時間不正確）」）
一個顯眼的「Troubleshoot」（疑難排解）連結
就這樣。詳細的指引現在放在使用者需要時才開啟的專用彈出視窗中，讓他們有空間真正閱讀並照著步驟操作。
疑難排解彈出視窗：在需要時提供詳細指引，不佔用小工具空間
這個疑難排解視窗提供了問題背景說明（例如：「此錯誤發生在您裝置的時鐘或日曆不準確時。若要完成此網站的安全驗證程序，您的裝置必須設定為您所在時區的正確日期和時間。」）、可供嘗試的逐步操作建議、說明文件的連結，以及（僅在使用者嘗試解決問題之後）一個向 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 系統。使用較少的抽象層、更貼近瀏覽器底層 API 進行開發，迫使我們重新審視既有假設、改善國際化策略，並全面提升品質標準。
最終的成果不僅僅是一個能運作的解決方案，更是一個我們信賴的方案。而這份信任，讓我們能夠持續精進，甚至置中一個 div 到頭來反而是最簡單的部分。
為數十億人進行設計，是我們認真看待的責任。在這種規模下，必須利用可衡量的數據來告訴我們，設計選擇所帶來的真實影響。當我們準備推出這些改變時，我們聚焦於五個關鍵指標，這些指標將告訴我們，是否真正成功地讓這個網際網路上最常見的 UI 變得對人類更友善。
我們的首要指標是「驗證解決率」：成功完成的驗證所佔的百分比。透過摒棄像「中介快取」這類技術術語，轉而採用簡單、可操作的標籤，例如「裝置時間不正確」，我們預期驗證解決率將顯著提升。更高的驗證解決率並不代表我們對機器人放寬標準；而是意味著我們移除了那些意外阻礙到合法人類使用者的障礙。
使用者在驗證頁面上花的每一秒，都是他們未能取得所需資訊的一秒。我們的研究顯示，使用者看到滿版的紅色文字時，常常因為不知所措而無法行動。藉由我們新的、易於掃讀的中性色設計，我們將追蹤「完成時間」，以確保使用者能在幾秒鐘（而非幾分鐘）內識別並解決問題。
過去，我們大量使用「高飽和度紅色」，引發了使用者的本能反應：他們覺得自己失敗了，然後就直接放棄。透過將紅色僅保留給圖示使用，並採用統一的架構，我們的目標是降低「放棄率」。我們希望讓使用者感到有能力去點擊「疑難排解」，而不是感到無能為力而直接離開。
從產品角度來看，其中一個較大的轉變是我們新增的「疑難排解對話視窗」。透過在小工具中直接提供清晰、逐步的操作指引，我們正在將自助式支援融入 UI 之中。我們預期這將使我們客戶以及我們內部團隊的「技術支援單數量」出現可衡量的下降。
我們知道安全驗證很少受到喜愛，但它們不應該因為令人困惑而招致反感。我們正在監測各大社群論壇、回饋報告以及社群媒體上的社群輿情，觀察討論方向是否能從「這個小工具壞了」轉變為「我遇到一個問題，但我解決了」。
作為一名產品經理，我的目標往往是讓安全機制隱形——最好的驗證挑戰，是使用者未見到的那一個。但當驗證挑戰必須出現時，它應該扮演協助者的角色，而不是守門的打手。這次的重新設計證明了，AAA 無障礙標準與高安全性標準並非相互競爭；它們是一體兩面。透過統一 Turnstile 和驗證頁面的架構，我們建立了一個能夠讓我們更快速迭代，並以更人性化的方式保護網際網路的基礎。
這次的重新設計是一個基礎，而非終點線。
我們將持續監測使用者如何與新體驗互動，並承諾根據我們所學到的一切進行迭代。我們在新設計中內建的回饋機制——那些真正能協助使用者進行疑難排解，而不只是要求他們回報問題的機制——將為我們提供比以往更豐富的見解。
我們也在密切關注安全領域的演變。隨著機器人攻擊變得更加精密，以及 AI 持續模糊人類行為與自動化行為之間的界線，驗證的挑戰只會日益艱鉅。我們的工作是保持領先——持續提升安全性，同時不讓人類的使用體驗變得更糟。
如果你遇到新的 Turnstile 或驗證頁面並有任何回饋，我們都樂於傾聽。歡迎透過我們的社群論壇聯繫我們，或使用體驗本身內建的回饋機制。