[Перевод] Никто не любит капчу. Редизайн турникета Cloudflare, который бесит всех

Вы это видели. Миллиарды раз. Но вряд ли запомнили. Небольшое окно с галочкой. Полноэкранная проверка перед входом на сайт. Что‑то, что встаёт между вами и нужной страницей и вежливо (или не очень) просит: “Докажите, что вы человек”.

Для всех это рутина. Лёгкое раздражение, которое мы научились не замечать. Но задумайтесь: какой интерфейс встречается в интернете чаще всего? “Гугл”? “Ютуб”? Нет.

Самый частый интерфейс в мире – это маленький турникет от Cloudflare. 7,67 миллиарда показов в день. Это больше, чем население Земли. И всё это время мы смотрели на него, но не видели. А если и видели, то, скорее всего, с мыслью: “Опять эта дурацкая капча”.

В Cloudflare решили, что с этим пора что‑то делать. Потому что даже у турникета есть право быть человечным.

Рассказываем, как компания перепридумала интерфейс, который видят все.

Вы это видели. Может быть, не обратили внимания, не зафиксировали в памяти – но видели точно. Небольшое окошко с просьбой подтвердить, что вы человек. Полноэкранная проверка безопасности перед входом на сайт. Стоит провести в интернете хоть немного времени – и вы обязательно столкнётесь с виджетом-турникетом или страницами проверки от Cloudflare. И скорее всего, не раз и не два, а столько, что и не сосчитать.

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

А это – огромная ответственность.

Создавать продукт, на который ежедневно смотрят миллиарды глаз, – задача особая. Здесь нужен совсем иной подход. Каждый пиксель, каждое слово, каждое нажатие должно быть понятно бабушке в японской глубинке, подростку из Сан-Паулу, незрячему разработчику в Берлине и занятому топ-менеджеру в Лагосе. И всё это – одновременно. И чаще всего – в момент раздражения.

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

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

Делегируйте часть рутинных задач вместе с BotHub! Для доступа к сервису не требуется VPN и можно использовать российскую карту. По ссылке вы можете получить 300 000 бесплатных токенов для первых задач и приступить к работе с нейросетями прямо сейчас!

Часть 1: Процесс дизайна

Проблема

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

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

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

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

• 2024 год: 3 млрд в день

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

Это в среднем на 58,1% больше проверок безопасности за год. А чем больше проверок, тем больше поводов для раздражения. Чем активнее компании внедряют такие механизмы защиты – ради себя и своих клиентов, – тем выше вероятность, что где-то кто-то столкнётся с неприятным опытом.

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

Честный ответ оказался прост: нам есть что улучшить.

Аудит дизайна

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

Картина открылась не самая радужная.

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

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

Возьмём, к примеру, механизм отправки отзывов. Пользователю предлагалось выбрать между вариантами “Виджет иногда не работает” и “Виджет не работает постоянно”. Но в чём, по сути, разница? И как человеку в момент раздражения определить, “иногда” это или “постоянно”? Мы требовали от пользователей интерпретировать расплывчатые формулировки именно тогда, когда у них и без того накипело. Чем больше мы оставляли на их усмотрение, тем менее полезной становилась обратная связь – и тем больше негатива появлялось в соцсетях.

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

Этот аудит оказался отрезвляющим. Зато он ясно показал, куда нам нужно направить усилия.

Картирование пользовательского пути

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

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

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

И здесь важно вот что: сообщения должны быть понятны каждому. Человеку любого возраста. С любыми ментальными или физическими особенностями. С любым культурным бэкграундом. С любым уровнем технической подготовки. Вот что значит проектировать в масштабе. Когда аудитория исчисляется миллиардами, “пограничные случаи” перестают быть пограничными – они становятся нормой.

Единая информационная архитектура

Одна из самых влиятельных книг по UX-дизайну – “Не заставляйте меня думать” Стива Круга. Её главный принцип предельно прост: каждая секунда, которую пользователь тратит на то, чтобы понять, расшифровать или интерпретировать интерфейс, – это трение. А трение, особенно в момент раздражения, ведёт к отказу.

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

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

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

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

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

Чему нас научили пользовательские исследования

Как оставаться честными перед собой, когда меняешь интерфейс, который видят миллиарды? Проверять. И проверять много.

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

Методика была строгой: участники видели и текущую версию, и обновлённую – не зная, где “старое”, а где “новое”. Порядок показа мы варьировали, чтобы исключить эффект предпочтения первого варианта. И мы тестировали не только новые идеи – мы ставили под сомнение сами предпосылки: а нужно ли, вообще, что-то менять?

Не всё требовало исправлений

Один из наших вопросов звучал так: стоит ли нам ориентироваться на конкурентов? Большинство провайдеров капчи используют универсальную формулировку “Я человек” на всех этапах. У нас же разные тексты для разных состояний: “Подтвердите, что вы человек”, затем “Проверяем…”, затем “Готово!”.

Не усложняем ли мы? Мы решили сравнить напрямую.

Результат оказался однозначным. На этапе интерактивного действия “Подтвердите, что вы человек” набрало 5 голосов из 8 против 3 у варианта “Я человек”. На этапе проверки разрыв был ещё заметнее – 7,5 против 0,5. Пользователям важно понимать, что происходит, а не просто констатировать факт.

Этот эксперимент не стал отдельной “функцией”, но дал нам нечто более ценное – уверенность. Мы убедились, что отличаемся не ради отличия. В некоторых вещах мы изначально были правы.

Но вот это нужно было менять

Исследование выявило четыре зоны, в которых мы подводили пользователей.

1) Помощь, а не бюрократия. Когда возникала ошибка, мы предлагали кнопку “Отправить отзыв”. В тестировании люди терялись: “Кому я это отправляю? Сайту? Cloudflare? Провайдеру?” Но главное открытие было глубже: в момент наивысшего раздражения человек не хочет составлять отчёт – он хочет решить проблему. Мы заменили “Отправить отзыв” (“Send feedback”) на “Устранить неполадку” (“Troubleshoot”). Одно слово, и совсем другое ощущение: не бумажная волокита, а конкретное действие.

2) Внимание, а не тревога. Мы щедро заливали ошибки красным фоном. Реакция в тестах была почти телесной: участники чувствовали, что “провалились”, что ситуация безвыходная. Даже в случаях, когда достаточно было просто повторить попытку, люди предполагали худшее и уходили. Ярко-красный цвет не говорил “Обратите внимание” – он говорил: “Вы проиграли, и ничего уже не исправить”. Мы пересмотрели подход: красный – только для иконок, но не для текста и не для фона.

3) Сканируемость, а не многословие. Мы старались быть обстоятельными и объясняли ошибки техническим языком. Это сыграло против нас. Нетехническим пользователям такие тексты казались чуждыми и пугающими. Техническим – избыточными. И всем приходилось вчитываться в мелкий текст внутри крошечного виджета. Вывод оказался прост: чем меньше – тем лучше, особенно в ограниченном пространстве и состоянии стресса.

4) Доступность для всех. Аудит показал, что в некоторых состояниях использовался шрифт размером 10 пикселей. Серый текст формально соответствовал уровню AA (контраст не менее 4,5:1 для обычного текста и 3:1 для крупного), но на практике читался с трудом. “Формально соответствует” – недостаточно, когда твою систему видит весь интернет.

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

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

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

Финальный редизайн

Итак, что же в итоге мы выпустили?

Сначала – о том, чего мы не стали менять. Счастливый путь – “Подтвердите, что вы человек” → “Идёт проверка…” → “Готово!” – показал себя на тестах безупречно. Пользователи ясно понимали, что происходит на каждом этапе. То, что для каждого состояния используется свой, отдельный текст (хотя мы и опасались, что это может усложнять восприятие), на деле оказалось нашим конкурентным преимуществом.

А вот для тех состояний, где действительно были проблемы, мы внесли серьёзные изменения – опираясь на всё, что узнали в процессе.

Упрощённый, легко сканируемый текст

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

• Чёткое и простое название состояния (например, “Неверное время на устройстве”);

• Заметная ссылка “Устранить проблему”.

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

Это модальное окно даёт контекст (“Эта ошибка возникает, когда часы или календарь на вашем устройстве установлены неверно. Для прохождения проверки безопасности время и дата должны соответствовать вашему часовому поясу”), предлагает пронумерованные шаги, ссылки на документацию и – только после того, как пользователь попытался решить проблему самостоятельно, – возможность отправить отзыв в Cloudflare. Сначала помощь, потом обратная связь.

Соответствие стандарту доступности AAA

Все состояния теперь соответствуют требованиям WCAG 2.2 AAA по контрастности и читабельности. Для шрифтов заданы минимальные размеры. Интерактивные элементы легко получают фокус и корректно озвучиваются скринридерами.

Единое взаимодействие для турникета и страниц проверки

Неважно, сталкивается ли пользователь с компактным виджетом-турникетом или полноэкранной страницей проверки, – информационная архитектура теперь едина. Та же иерархия. Те же места для элементов. Та же ментальная модель.

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

Проверено на всех языках

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

• Первичный дизайн-ревью внутри команды дизайнеров;

• Профессиональный перевод от квалифицированного подрядчика;

• Финальную вычитку носителями языка – сотрудниками Cloudflare.

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

Полная картина

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

Но спроектировать новый опыт – это была лишь половина задачи. Доставить его миллиардам пользователей? Вот тут в дело вступает Ана.

Часть 2: Доставка на миллиарды устройств

Не только про центрирование

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

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

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

Маленькие визуальные правки – огромный глобальный эффект

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

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

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

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

Уверенность через тестирование

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

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

Взгляд вперёд

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

В результате мы получили не просто решение, которое работает, а решение, которому мы доверяем. А именно это доверие и позволяет нам продолжать улучшения – даже если в какой-то момент выясняется, что центрирование <div> было самой простой частью задачи.

Этот редизайн – не финишная прямая, а прочная отправная точка.

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

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