Самый узнаваемый интерфейс в сети: как мы переделали страницы проверок Cloudflare

Вы это видели. Возможно, не осознавали, но видели. Этот маленький виджет, просящий подтвердить, что вы человек. Эта полноэкранная проверка безопасности перед доступом к сайту. Если вы хоть сколько-то времени провели в интернете, вы сталкивались с виджетом Turnstile или страницами проверки от Cloudflare — скорее всего, больше раз, чем можете сосчитать.

^{Виджет Turnstile – знакомое зрелище на миллионах сайтов}

Когда мы говорим, что значительная часть интернета находится за Cloudflare, мы не шутим. Наш виджет Turnstile и страницы проверки отображаются 7,67 миллиарда раз каждый день. Это не опечатка. Миллиарды. Возможно, это самый часто видимый пользовательский интерфейс в интернете.

А это налагает огромную ответственность.

Дизайн продукта, на который смотрят миллиарды глаз, — это не просто сложно. Это требует принципиально иного подхода. Каждый пиксель, каждое слово, каждое взаимодействие должно работать для чьей-то бабушки в сельской Японии, подростка в Сан-Паулу, слабовидящего разработчика в Берлине и занятого топ-менеджера в Лагосе. Всех одновременно. В моменты раздражения.

Сегодня мы расскажем историю о том, как переделали дизайн Turnstile и страниц проверки. Это история из трёх частей, рассказанная тремя из нас: о процессе дизайна и исследованиях, сформировавших наши решения (Лео), об инженерной задаче внедрения изменений в беспрецедентном масштабе (Ана), и об измеримом воздействии на миллиарды пользователей (Марина).

Давайте начнём с того, как мы подошли к проблеме с точки зрения дизайна.

Давайте будем честными: никто не любит, когда у него просят доказать, что он человек. Вы знаете, что вы человек. Я знаю, что я человек. Единственный, кто, кажется, не уверен, — это тот маленький виджет, который стоит между вами и сайтом, к которому вы пытаетесь получить доступ. В лучшем случае это небольшая помеха. В худшем? Вы, наверное, хотели в приступе ярости вышвырнуть компьютер в окно. Все мы через это проходили. И никто бы вас не осудил.

^{Turnstile, интегрированный в процесс входа в систему}

По мере того как мир привыкает к, судя по всему, неизбежной революции ИИ, потребность в проверках безопасности только растёт. В Cloudflare мы наблюдаем значительный рост атак ботов — и в ответ организации всё больше инвестируют в меры безопасности. Это значит, что проверки будут предлагаться всё большему числу конечных пользователей и всё чаще.

Цифры говорят сами за себя:

2023: 2,14 млрд в день

2024: 3 млрд в день

2025: 5,35 млрд в день

Это в среднем 58,1% роста проверок безопасности в год. Больше проверок — больше возможностей для разочарования пользователя. Чем больше компаний интегрируют такие системы верификации для защиты себя и своих клиентов, тем выше вероятность, что у кого-то, где-то, будет плохой опыт.

Мы поняли, что пора критически взглянуть на наши флагманские продукты и спросить себя: правильно ли мы поступаем по отношению к миллиардам людей, сталкивающихся с этим? Выполняем ли мы свою миссию — построить лучший интернет, не только более безопасный, но и более человечный?

Ответ, как мы выяснили, был таким: мы можем лучше.

Прежде чем что-то переделывать, нужно было понять, с чем мы работаем. Мы начали с проведения комплексного аудита каждого состояния, каждого сообщения об ошибке и каждого взаимодействия как в Turnstile, так и на страницах проверки.

То, что мы обнаружили, было не лучшим.

^{Состояние несогласованности в виджете Turnstile. Множество состояний без единого подхода}

Несоответствия были вопиющими. У нас не было единого подхода ко множеству различных сценариев ошибок. Некоторые сообщения были излишне многословными и техническими («Часы вашего устройства показывают неверное время, или эта страница проверки была случайно закэширована посредником и больше недоступна»). Другие были слишком расплывчатыми, чтобы быть полезными («Время истекло»). Визуальный язык сильно различался — разные макеты, разные иерархии, разные тональности.

Мы также изучили полученные онлайн-отзывы. Соцсети, обращения в поддержку, форумы сообщества — мы всё прочитали. Раздражение было ощутимым, и во многом его можно было избежать.

Возьмём, к примеру, наш механизм обратной связи. Мы предлагали пользователям варианты вроде «Виджет иногда не работает» и «Виджет не работает никогда». Но какая, собственно, разница? И откуда им было знать, как часто он не работает? Мы просили пользователей интерпретировать неоднозначные варианты в момент их наибольшего раздражения. Чем больше мы оставляли на их усмотрение, тем менее полезной становилась обратная связь — и тем больше раздражения мы видели в соцсетях.

^{Предыдущий экран обратной связи: «Виджет иногда не работает» vs «Виджет не работает никогда» — какая разница?}

Наши страницы проверки — полноэкранные блоки безопасности, которые появляются при обнаружении подозрительной активности или когда у владельцев сайта усилены настройки безопасности — имели схожие проблемы. Некоторые состояния были запутанными. Другие использовали слишком много технического жаргона. Многие не давали практических рекомендаций, когда пользователи больше всего в них нуждались.

^{Состояние несогласованности на страницах проверки. Множество состояний без единого подхода}

Аудит был отрезвляющим. Но он дал чёткую картину того, на чём нужно сосредоточиться.

Чтобы спроектировать лучший опыт, сначала нужно было понять каждый возможный путь пользователя. Каким был счастливый путь? Был ли он вообще? И каковы были негативные пути, ведущие к нарастающему раздражению?

^{Картирование полного пользовательского пути — от первого появления до сценариев ошибок, с отслеживанием настроения}

Это была по-настоящему кросс-функциональная работа. Мы тесно сотрудничали с инженерами вроде Аны, которые знали технические тонкости каждого краевого случая, и с Мариной со стороны продукта, которая понимала не только как продукт работает, но и что пользователи о нём думают — и любовь, и ненависть, которые мы видели онлайн.

В Cloudflare работают одни из самых умных людей в области защиты от ботов. Но ум и ясность — не одно и то же. Существует тонкий баланс между технической сложностью и простотой для пользователя. Только когда эти двое успешно танцуют вместе, мы можем донести информацию так, чтобы она действительно имела смысл для людей.

И вот в чём дело: тексты должны работать для всех. Для человека любого возраста. С любыми умственными или физическими возможностями. С любым культурным бэкграундом. С любым уровнем технической подкованности. Вот что на самом деле значит дизайн в таком масштабе — вы не можете игнорировать краевые случаи, потому что при таком масштабе они перестают быть краевыми.

Одна из самых влиятельных книг в UX-дизайне — «Не заставляйте меня думать» (Don't Make Me Think) Стива Крага. Основной принцип прост: каждый момент, который пользователь тратит на попытку интерпретировать, понять или расшифровать ваш интерфейс, — это момент трения. А трение, особенно в моменты раздражения, ведёт к отказу.

Наш аудит показал, что мы заставляли пользователей думать слишком много. Разная информация занимала одно и то же место в интерфейсе в разных состояниях. Не было последовательной визуальной иерархии. Пользователи, столкнувшиеся с состоянием ошибки в Turnstile, находили информацию в совершенно другом месте, чем на странице проверки.

Мы приняли фундаментальное решение: одна информационная архитектура, чтобы править всеми.

^{Визуальная диаграмма, отображающая единую информационную архитектуру с согласованной структурой для виджета Turnstile и страниц проверки}

И Turnstile, и страницы проверки теперь будут следовать одной структурной схеме. Одинаковой визуальной иерархии. Одинаковому расположению для действий, пояснительного текста, ссылок на документацию.

Ограничивало ли это наши дизайнерские возможности? Безусловно. Нам пришлось отказаться от множества креативных идей, которые не вписывались в эту структуру. Но ограничения — не враг хорошего дизайна, часто они его лучший друг. Ограничив свои варианты, мы смогли углубиться в детали, которые действительно имели значение.

Для пользователей выгода огромна: им не нужно заново учиться, что означает каждый элемент интерфейса. Состояния ошибок выглядят одинаково. Ссылки на справку всегда в одном месте. Поняв одно состояние, вы понимаете их все. Это сведённая к минимуму когнитивная нагрузка — именно то, что нужно во время проверки безопасности.

Как держать себя в тонусе при перепроектировании чего-то, что видят миллиарды людей? Нужно тестировать. Много.

Мы привлекли 8 участников из 8 разных стран, намеренно стремясь к разнообразию по возрасту, цифровой грамотности и культурному происхождению. Мы искали не только технически подкованных новаторов — мы хотели понять, насколько хорошо редизайн будет работать для всех.

Наш подход был тщательным: участники видели как текущий интерфейс, так и предлагаемые изменения, не зная, что «старое», а что «новое». Мы меняли порядок показа, чтобы исключить предвзятость. И мы не просто тестировали наши новые идеи, но и проверяли исходные предположения о том, что вообще нужно менять.

^{Две разные версии Turnstile, тестируемые в A/B-тесте}

Одна из гипотез: стоит ли нам ориентироваться на конкурентов? Большинство поставщиков CAPTCHA используют текст «Я человек» для всех состояний. Мы используем разный контент — «Подтвердите, что вы человек», затем «Проверка...», затем «Успех!».

Не усложняли ли мы всё? Мы протестировали оба подхода напрямую.

Наша версия победила решительно. Для интерактивного состояния фраза «Подтвердите, что вы человек» набрала 5 баллов из 8 против всего 3 у «Я человек». Для состояния проверки разрыв был ещё больше — 7,5 против 0,5. Пользователи хотели понимать, что происходит, а не просто слышать, кем они являются.

^{Результаты тестирования: пользователи решительно предпочли наш подход дизайну в стиле конкурентов}

Этот эксперимент не был внедрён как новая функция, но он был бесценен. Он дал нам уверенность, что мы не просто отличаемся ради отличия. Некоторые вещи уже были правильными.

Исследование выявило четыре области, где мы подводили пользователей:

Помощь, а не бюрократия. Когда пользователи сталкивались с ошибками, мы предлагали кнопку «Отправить отзыв». Во время тестирования они были в замешательстве. «Кому я это отправляю? Веб-сайту? Cloudflare? Моему провайдеру?» Что более важно, мы обнаружили нечто фундаментальное: в момент наибольшего разочарования люди не хотят писать отчёт — они хотят решить проблему. Мы заменили «Отправить отзыв» на «Устранить неполадку» — одно слово, которое обещает действие, а не бюрократию.

^{Проблематичное сообщение «Отправить отзыв»: пользователи не знали, кому отправляют отзыв}

Внимание, а не тревога. Мы активно использовали красный фон для ошибок. Реакция в тестах была очень сильной — участники чувствовали, что они провалились, чувствовали себя беспомощными. Даже при простых проблемах, решаемых повторной попыткой, пользователи предполагали худшее и сдавались. Красный цвет в полной насыщенности передавал не «Вот что нужно исправить», а «Вы потерпели неудачу, и ничего нельзя сделать». Решение: использовать красный только для иконок, никогда для текста или фона.

^{Эволюция: от состояний с неясным описанием ошибки на красном фоне к гораздо более понятному и лаконичному сообщению об ошибке в тексте нейтрального цвета.}

Обозримость, а не многословность. Мы пытались быть дотошными, объясняя ошибки техническими деталями. Это дало обратный эффект. Нетехнические пользователи чувствовали себя отчуждёнными. Техническим пользователям это не было нужно. Все пытались прочитать это в крошечном пространстве виджета. Вывод: меньше — значит больше, особенно в ограниченном пространстве в стрессовые моменты.

Доступность для всех. Наш аудит выявил шрифты размером 10px в некоторых состояниях. Серый текст, который технически соответствовал стандарту AA (минимум 4.5:1 для обычного текста и 3:1 для крупного), но на практике читался с трудом. «Технического соответствия» недостаточно, когда ваша аудитория — весь интернет.

Мы поставили чёткую цель: соответствовать стандарту WCAG 2.2 AAA — высшему и наиболее строгому уровню соответствия веб-доступности, предназначенному для максимального охвата пользователей, включая людей с тяжёлыми формами инвалидности. В ходе редизайна, когда визуальная целостность конфликтовала с читаемостью, побеждала читаемость. Каждый раз.

Это выходило за рамки зрения. Мы проектировали для пользователей скринридеров, навигации только с клавиатуры и людей с различными особенностями цветового зрения — выходя за пределы того, что могут обнаружить автоматизированные инструменты проверки.

И доступность — это не только про ограничения, но и про язык. То, что умещается в английском, не помещается в немецком. То, что лаконично в испанском, двусмысленно в японском. Поддержка более 40 языков вынудила нас радикально упростить. Одна и та же структура «Не удалось подключиться к сайту / Устранить неполадку» теперь работает на английском, болгарском, датском, немецком, греческом, японском, индонезийском, русском, словацком, словенском, сербском, филиппинском и многих других языках.

^{Редизайн состояния ошибки на 12 языках — единая структура, несмотря на разную длину текста}

Так что же мы в итоге внедрили?

Для начала поговорим о том, что мы НЕ меняли. Успешный сценарий — «Подтвердите, что вы человек» → «Проверка...» → «Успех!» — показал себя исключительно хорошо. Пользователи понимали, что происходит на каждом этапе. Разный контент для каждого состояния, в сложности которого мы сомневались, на самом деле оказался нашим конкурентным преимуществом.

^{Успешный сценарий: Подтвердите, что вы человек → Проверка → Успех! Эти состояния хорошо протестированы и в основном остались без изменений}

Но для состояний, которые требовали доработки, мы внесли значительные изменения, руководствуясь всем, что узнали.

Мы радикально сократили количество текста в состояниях ошибки. Вместо многословных объяснений вроде «Часы на вашем устройстве показывают неверное время, или страница с проверкой была случайно сохранена в кеше посредника и больше не доступна», мы теперь показываем:

1. Понятное, простое название состояния (например, «Неверное время на устройстве»)

2. Выделенную ссылку «Устранить неполадку»

И всё. Подробные инструкции теперь находятся на отдельном модальном экране, который открывается, когда пользователям это нужно — давая им пространство для чтения и выполнения шагов по устранению неполадок.

^{Модальное окно устранения неполадок: подробные инструкции, когда они нужны, без загромождения виджета}

Модальное окно устранения неполадок предоставляет контекст («Эта ошибка возникает, когда часы или календарь на вашем устройстве показывают неточные данные. Для завершения процесса проверки безопасности этого веб-сайта на вашем устройстве должна быть установлена правильная дата и время в вашем часовом поясе.»), пронумерованные шаги для решения, ссылки на документацию и — только после того, как пользователь попытался решить проблему — возможность отправить отзыв в Cloudflare. Сначала помощь, потом отзыв.

Теперь каждое состояние соответствует стандартам контрастности и читаемости WCAG 2.2 AAA. Размеры шрифтов имеют установленные минимумы. Интерактивные элементы чётко выделяются фокусом и правильно озвучиваются скринридерами.

Вне зависимости от того, сталкивается ли пользователь с компактным виджетом Turnstile или с полной страницей проверки, архитектура информации теперь последовательна. Такая же иерархия. Такое же расположение. Такая же ментальная модель.

Страницы проверки теперь имеют чёткую структуру: название сайта и фавиконка вверху, понятное сообщение о статусе (например, «Проверка прошла успешно» или «Ваш браузер устарел») и инструкции для действия ниже. Никаких стен из оранжевого или красного текста. Никакого технического жаргона без контекста.

^{Редизайн состояний страницы проверки с понятными инструкциями по устранению неполадок.}

Каждый элемент контента был протестирован на более чем 40 поддерживаемых языках. Наш процесс включал три уровня проверки:

1. Первоначальный обзор дизайна командой дизайнеров

2. Профессиональный перевод нашим квалифицированным поставщиком

3. Финальная проверка сотрудниками Cloudflare — носителями языка

Речь шла не только о точности перевода — важно было убедиться, что визуальный дизайн остаётся целостным, когда длина контента резко меняется от языка к языку.

В результате мы получили процесс проверки безопасности, который стал понятнее, доступнее, менее раздражающим и — что крайне важно — таким же безопасным. Мы не пошли на компромисс в защите ради улучшения пользовательского опыта. Мы доказали, что хороший дизайн и сильная безопасность не конфликтуют друг с другом.

^{Редизайн виджетов Turnstile слева и редизайн страницы проверки справа}

Но разработать интерфейс — это была лишь половина битвы. Внедрить его для миллиардов пользователей? Здесь в игру вступает Ана.

Некоторые могут сказать, что самая сложная часть работы фронтенд-инженера — это центрирование div. В реальности же настоящая проблема часто лежит гораздо глубже, особенно при работе близко к примитивам платформы. Создание критически важного элемента интернет-инфраструктуры с использованием нативных API заставляет вас по-другому думать о разработке пользовательского интерфейса, компромиссах и долгосрочной поддержке.

В нашем случае мы используем Rust для обработки пользовательского интерфейса как виджета Turnstile, так и страницы Challenge. Это решение принесло очевидные преимущества с точки зрения безопасности и согласованности между платформами, но также увеличило сложность фронтенда. Многие из нас привыкли к удобству современных фреймворков, таких как React, где распространенные взаимодействия с интерфейсом практически даром. Работа с Rust означала повторную реализацию даже простых взаимодействий с использованием низкоуровневых конструкций, таких как document.getElementById, createElement и appendChild.

Кроме того, время компиляции и строгие проверки естественным образом замедляли быструю итерацию интерфейса по сравнению с фреймворками на JavaScript. Отладка также была более сложной, поскольку экосистема инструментов все еще развивается. Эти ограничения заставили нас быть более осознанными, вдумчивыми и, в конечном счете, более дисциплинированными в нашем подходе к разработке пользовательского интерфейса.

То, что изначально выглядело как мелкие визуальные правки, такие как корректировка отступов или выравнивания, быстро выявило гораздо более серьезную проблему: интернационализацию.

Как только переводы стали доступны, мы должны были убедиться, что контент остается читаемым и удобным на 38 языках и в 16 различных состояниях интерфейса. Одна только вариативность длины текста потребовала тщательных дизайнерских решений. Некоторые переводы могут быть на 30–300 процентов длиннее английского оригинала. Короткая английская фраза вроде «Stuck?» становится «Tidak bisa melanjutkan?» на индонезийском или «Es geht nicht weiter?» на немецком, кардинально меняя требования к макету.

Поддержка языков с письмом справа налево добавила еще один уровень сложности. Поддержка арабского, персидского (фарси) и иврита означала не просто смену направления текста. Пришлось зеркалировать целые макеты, включая выравнивание, шаблоны навигации, направленные иконки и анимационные потоки. Многие из этих элементов неявно разработаны с учетом письма слева направо, поэтому нам пришлось пересмотреть эти решения и сделать их по-настоящему двунаправленными.

Нумерованным спискам также потребовалось особое внимание. Не каждая культура использует западную систему нумерации 1, 2, 3, а жестко заданные числовые последовательности могут сделать интерфейс чуждым или некорректным. Мы полагались на номерные форматы с учетом локали и полностью переводимые форматы списков, чтобы обеспечить естественный и культурно уместный порядок на каждом языке.

Когда мы начали перечислять пункты действий в отчетах об обратной связи, корректность стала еще более критичной. Каждое действие должно было отображаться правильно, запускать нужный поток и вести себя последовательно во всех состояниях, языках и крайних случаях.

Чтобы достичь этого, мы много инвестировали в тестирование. Модульные тесты помогли нам проверить логику изолированно, а сквозные (end-to-end) тесты гарантировали, что новые состояния и языки работают так, как ожидается, в реальных сценариях. Эта основа тестирования дала нам уверенность для безопасной итерации, предотвратила регрессии и обеспечила надежность и полезность отчетов об обратной связи для пользователей.

То, что начиналось как набор технических ограничений, превратилось в возможность создать более надежную, инклюзивную и хорошо протестированную систему пользовательского интерфейса. Работа с меньшим количеством абстракций и ближе к примитивам браузера заставила нас переосмыслить допущения, улучшить стратегию интернационализации и поднять общую планку качества.

В результате мы получили не просто работающее решение, а то, которому мы доверяем. И это доверие позволяет нам продолжать совершенствоваться, даже когда центрирование div оказывается самой простой частью.

Дизайн для миллиардов людей — это ответственность, которую мы воспринимаем серьезно. В таких масштабах крайне важно использовать измеряемые данные, чтобы понимать реальное влияние наших дизайнерских решений. Готовясь к внедрению этих изменений, мы фокусируемся на пяти ключевых метриках, которые покажут, действительно ли нам удалось сделать самый видимый в Интернете интерфейс более человечным.

Нашей главной путеводной звездой является Уровень решения проверок (Challenge Solve Rate, CSR): процент выданных проверок, которые успешно завершены. Отойдя от технического жаргона вроде «промежуточного кэширования» в сторону простых, понятных обозначений, таких как «Некорректное время устройства», мы ожидаем значительного роста CSR. Более высокий CSR не означает, что мы стали мягче к ботам; это значит, что мы убираем препятствия, которые случайно сбивали с толку законных пользователей-людей.

Каждая секунда, которую пользователь проводит на странице проверки, — это секунда, когда он не получает нужную ему информацию. Наши исследования показали, что пользователи часто терялись, видя стену красного текста. Благодаря новому, легко сканируемому дизайну нейтральных цветов мы отслеживаем Время на выполнение, чтобы гарантировать, что пользователи смогут выявить и решить проблемы за секунды, а не минуты.

Раньше наше активное использование «насыщенного красного цвета» вызывало инстинктивную реакцию: пользователи чувствовали, что потерпели неудачу, и просто сдавались. Резервируя красный цвет только для иконок и используя унифицированную архитектуру, мы стремимся снизить показатели отказов. Мы хотим, чтобы пользователи чувствовали себя способными нажать «Устранение неполадок», а не чувствовали себя беспомощными и уходили.

Одним из более значительных изменений с точки зрения продукта является наш новый модальный режим устранения неполадок. Предоставляя четкие, нумерованные шаги прямо внутри виджета, мы встраиваем самообслуживание в интерфейс. Мы ожидаем, что это приведет к ощутимому снижению объема обращений в поддержку как для наших клиентов, так и для наших внутренних команд.

Мы знаем, что проверки безопасности редко вызывают любовь, но их не должны ненавидеть из-за запутанности. Мы отслеживаем Общественное мнение на форумах, в отчетах об обратной связи и социальных сетях, чтобы увидеть, сместится ли дискуссия от «этот виджет сломан» к «у меня была проблема, но я её исправил».

Как менеджер по продукту, моя цель часто — невидимая безопасность: лучшая проверка — та, которую пользователь никогда не видит. Но когда проверку необходимо увидеть, она должна быть помощником, а не вышибалой. Этот редизайн доказывает, что доступность уровня AAA и высокие стандарты безопасности не конкурируют; они две стороны одной медали. Унифицировав архитектуру Turnstile и Challenge Pages, мы создали основу, которая позволяет нам итерироваться быстрее и защищать Интернет более гуманно, чем когда-либо прежде.

Этот редизайн — основа, а не финишная черта.

Мы продолжаем следить за тем, как пользователи взаимодействуют с новым опытом, и мы стремимся итерироваться на основе того, что узнаем. Механизмы обратной связи, встроенные в новый дизайн — те, которые действительно помогают пользователям решать проблемы, а не просто просят сообщить о них, — дадут нам более глубокое понимание, чем когда-либо.

Мы также следим за эволюцией ландшафта безопасности. По мере того как атаки ботов становятся более изощренными, а искусственный интеллект продолжает стирать грань между человеческим и автоматизированным поведением, задача верификации будет только усложняться. Наша задача — оставаться впереди, продолжая улучшать безопасность, не ухудшая человеческий опыт.