Пользователь приходит в новый интерфейс не с пустой головой: прошлый опыт уже подсказывает ему, где искать, чего ждать после действия и что означает знакомая форма. Разберём, как из повторяющегося опыта возникают конвенции и паттерны, почему хороший паттерн нельзя копировать без контекста и где неудачное решение превращается в манипуляцию.
В прошлом уроке мы разобрали ментальную модель как прогноз: человек видит интерфейс, предполагает, что произойдёт после действия, действует и сверяет ожидание с ответом системы. Но откуда берётся само ожидание? Частично — из опыта с этим продуктом, а частично — из десятков других продуктов, которыми человек пользовался раньше. Nielsen Norman Group — организация, которая занимается исследованиями и практикой пользовательского опыта, — отмечает, что ментальные модели веб-интерфейсов формируются в том числе из повторяющихся паттернов, которые люди встречают в разных системах.[1]
Если во многих сервисах строка поиска принимает текст, список под ней предлагает продолжения запроса, а выбор подсказки запускает или уточняет поиск, человек начинает переносить это ожидание в следующий продукт. Он не обязан знать слова «autocomplete» или «паттерн». Он просто пробует уже знакомое действие. Поэтому предсказуемость интерфейса — не признак отсутствия творчества, а способ использовать уже накопленное пользователем знание.
В профессиональной работе это связывают с внешней последовательностью интерфейса: продукт учитывает веб-, платформенные и отраслевые соглашения, которые пользователь уже мог выучить в других системах. NN/g называет это external consistency и противопоставляет ей внутреннюю последовательность внутри одного продукта; внутреннюю consistency мы подробнее разберём в следующем уроке.[2]
Здесь нужны два близких слова, которые в командах иногда смешивают. Для курса будем разводить их по рабочей функции. Конвенция — привычное для аудитории соглашение о том, где находится элемент, как он выглядит или как ведёт себя. Паттерн — повторяемый способ решить повторяющуюся пользовательскую проблему в определённом контексте. Конвенция описывает ожидание, с которым человек приходит; паттерн помогает дизайнеру построить решение.
Многие паттерны со временем становятся настолько распространёнными, что поддерживают конвенцию, но эти слова не являются полными синонимами. Например, ожидание, что подчёркнутый текст в вебе является ссылкой, — конвенция. А «поиск с подсказками» — более содержательный шаблон взаимодействия: он решает повторяющуюся проблему формулирования и ускорения запроса.
Сам подход к паттернам появился не в цифровых интерфейсах. В 1977 году архитектор Кристофер Александер с соавторами опубликовал книгу A Pattern Language, где повторяющиеся проектные проблемы и решения описывались как адаптируемые схемы для конкретного места и условий.[3] Нам важна не история термина сама по себе, а исходная мысль: паттерн существует вместе с проблемой и контекстом, а не отдельно от них.
GOV.UK Design System — открытая дизайн-система британских государственных сервисов — формулирует ту же практическую идею: их patterns — это проверенные решения для конкретных пользовательских задач и типов страниц, которые часто состоят из нескольких элементов и требуют адаптации к контексту.[4] Поэтому профессиональный вопрос звучит не «какой паттерн сейчас модный?», а «какая повторяющаяся проблема у нас есть и подходит ли сюда известное решение?»
Рассмотрим паттерн, который можно потрогать прямо сейчас. Когда человек ещё не закончил вводить поисковый запрос, сервис может предложить варианты продолжения. Google описывает Autocomplete как функцию, которая помогает быстрее завершить начатый запрос; среди факторов для подсказок называются язык, местоположение, текущий интерес к теме и прошлые запросы.[5] Яндекс тоже использует поисковые подсказки и отдельно позволяет управлять подсказками, основанными на истории поиска.[6]
Перед нами один и тот же класс решения, но не одна и та же реализация. Состав подсказок, персонализация, порядок вариантов и дополнительные действия могут различаться. Именно поэтому паттерн нельзя описать как «нарисовать выпадающий список под полем». Смысл глубже: человек начал формулировать запрос, а система помогает быстрее превратить намерение в подходящую формулировку.
Есть и обратная сторона. Подсказки, полезные в поиске, не становятся хорошим решением для любого текстового поля. Если человек вводит секрет, уникальный номер документа или свободный комментарий, механизм «угадывать продолжение» решает уже другую или вообще несуществующую проблему. В таком месте копируется внешняя форма, но теряется основание паттерна.
Теперь проверим паттерн на границе применимости. Знакомое решение иногда выглядит настолько «правильным», что его хочется использовать по привычке. Но паттерн перестаёт помогать, если исходная проблема изменилась.
В дизайн-системе GOV.UK, официальной системе компонентов и паттернов британских государственных цифровых сервисов, breadcrumbs — «хлебные крошки» — помогают понять положение страницы в иерархии сайта и перейти на более высокий уровень.[7] Там же отдельно существует back link — ссылка возврата на предыдущий шаг многостраничного процесса. Руководство прямо предупреждает: эти два решения не следует ставить вместе, потому что они обслуживают разные модели движения.[8]
Представьте оформление заявки из четырёх последовательных шагов. Если над формой поставить хлебные крошки «Главная → Заявки → Шаг 3», они могут выглядеть знакомо, но не отвечают на главный вопрос человека: что произойдёт при возврате и сохранятся ли введённые данные. Компонент знакомый, а проблема выбрана неверно.
Сначала сформулируйте повторяющуюся пользовательскую проблему без названия компонента. Затем назовите контекст, в котором она возникает. Только после этого сравнивайте известные решения.
Ошибка не всегда начинается с плохих намерений. Иногда команда выбирает решение, которое кажется рациональным, повторяет его из проекта в проект и получает предсказуемо плохой результат. В этом уроке будем называть антипаттерном повторяющееся проектное решение, которое выглядит правдоподобно, но систематически мешает решать исходную задачу или создаёт избыточную стоимость для пользователя.
Например, команда может использовать один и тот же многоуровневый навигационный компонент в каталоге, анкете и пошаговой настройке только потому, что элемент уже есть в наборе готовых решений. Проблема не в том, что «хлебные крошки плохие»: в иерархическом каталоге они уместны. Антипаттерном становится механическое применение знакомого решения вне его контекста.
«У нас есть готовые вкладки, поэтому любое переключение между состояниями сделаем вкладками».
«Пользователь должен быстро переключаться между равноправными представлениями. Проверим, подходит ли сюда паттерн вкладок и какие у него ограничения».
Это различие пригодится на ревью. Фраза «так нельзя делать» почти ничего не даёт. Сильнее звучит диагноз: какую проблему решали, почему выбранный паттерн не соответствует контексту и что именно ломается для человека.
Следующая граница важнее, чем просто «хороший или плохой UX». В 2010 году дизайнер Гарри Бриннелл запустил сайт darkpatterns.org, посвящённый интерфейсным приёмам, которые манипулируют выбором пользователя. Проект позже сменил название на Deceptive Patterns, подчёркивая сам механизм обмана или манипулирования выбором.[9]
Здесь нужна аккуратность с намерением. В профессиональных и исследовательских определениях нет единственного теста, который позволял бы по экрану достоверно установить, что именно думал дизайнер. Исследователи прямо отмечают, что у понятия нет одной универсальной нормативной границы.[10] Поэтому на ревью безопаснее сначала описывать наблюдаемую механику и её эффект: что скрыто, что затруднено, к какому выбору подталкивает интерфейс и что теряет пользователь.
Масштаб явления тоже изучался эмпирически. В исследовании 2019 года команда Принстонского университета автоматически и вручную проанализировала примерно 11 тысяч интернет-магазинов и нашла 1 818 экземпляров dark patterns, относящихся к 15 типам, на 1 254 сайтах. Авторы отдельно подчёркивали, что методика обнаруживала не все возможные механики, поэтому результат следует читать как нижнюю оценку для изученной выборки.[11]
Яркая кнопка согласия и менее заметная кнопка отказа могут быть проблемой, но одного визуального различия недостаточно, чтобы автоматически назвать интерфейс deceptive pattern. Смотрите на информацию, последствия, свободу отказа и фактическую механику выбора.
Названия deceptive patterns удобны как профессиональный словарь, но заучивать каталог ради каталога бессмысленно. Полезнее понять, каким способом меняется решение человека. Ниже — шесть распространённых механизмов из современной классификации Deceptive Patterns.[12]
Вместо нейтрального «Не сейчас» человек видит вариант вроде «Нет, я предпочитаю переплачивать». Отказ технически доступен, но формулировка пытается вызвать вину или стыд. Deceptive Patterns определяет confirmshaming именно через эмоциональное давление и унизительную или вызывающую вину формулировку варианта отказа.[13]
Человек сравнивает варианты по одной цене, проходит несколько шагов, а перед оплатой обнаруживает обязательный сбор, который нельзя было разумно учесть раньше. Проблема не в том, что цена изменилась сама по себе, а в том, что важная для решения информация была раскрыта после того, как пользователь уже вложил время и сформировал ожидание.[12]
Чтобы получить желаемый результат, человека заставляют выполнить дополнительное действие, которое не является необходимым для самой задачи: например, передать несвязанные с ней данные или согласиться на дополнительное условие. Ключевой вопрос здесь — действительно ли действие необходимо для результата или используется как цена доступа к нему.[12]
Подписка оформляется за несколько понятных действий, а отмена требует искать скрытый путь, звонить, проходить дополнительные экраны или снова убеждать сервис, что решение окончательное. Исторически для похожей асимметрии использовали термин roach motel: легко войти, трудно выйти. Современная классификация Deceptive Patterns использует более прямое название hard to cancel.[14]
Таймер или сообщение о скором окончании предложения выглядит как реальное ограничение, хотя заявленная срочность ложна или не связана с фактическими условиями. Сам таймер не является deceptive pattern: если бронь действительно удерживается ограниченное время и срок честно отражает состояние системы, это обычная информация о контексте. Проблема начинается с ложной срочности.[12]
Опция заранее выбрана, и человек получит дополнительную услугу или согласие, если специально не заметит и не изменит состояние. Но и здесь одной предустановки недостаточно для автоматического обвинения: некоторые значения по умолчанию могут быть полезны. Для deceptive pattern критичны контекст, прозрачность, последствия и то, насколько интерфейс рассчитывает на невнимательность.[12]
Некоторые deceptive patterns видны в одном экране, но hard to cancel раскрывается только во времени. Пользователь уже решил уйти, а продукт получает последний шанс объяснить последствия этого решения. Один спокойный экран с важной информацией или предложением остаться сам по себе ещё не делает отмену манипулятивной. Вопрос начинается там, где человеку приходится снова и снова доказывать уже выраженное намерение, а новые шаги почти не добавляют информации, необходимой для осознанного решения.
На знакомом российском примере это различие видно особенно хорошо. В опубликованном UX-разборе подписки Яндекс Плюс продуктовая студия StandApp зафиксировала конкретный поток отмены: после первого запроса пользовательнице показывали предупреждение о бесплатном периоде, предложение заморозить подписку, напоминания о преимуществах и предложение сохранить подписку за бонус; до окончательной отмены действие пришлось подтверждать несколько раз.[15] Этот материал полезен как зафиксированный интерфейсный случай, но не как описание нынешнего Плюса: продукт мог измениться.
Текущая официальная справка Яндекс Плюса описывает отмену иначе и значительно короче: открыть личный кабинет, пролистать страницу до конца, нажать «Отменить мультиподписку» и подтверждать действие, пока не появится экран успешной отмены. Для замороженной подписки сначала требуется возобновление, после чего кнопка отмены снова становится доступной.[16] Но справка описывает маршрут, а не обязательно каждый промежуточный экран и его визуальную иерархию.
Старый или отдельно зафиксированный поток может хорошо объяснять механизм hard to cancel, но не доказывает, что тот же интерфейс существует сегодня. А короткая официальная инструкция подтверждает наличие пути отмены, но сама по себе не доказывает, что этот путь свободен от лишнего трения. Для оценки текущего продукта нужен текущий наблюдаемый сценарий.
Поэтому профессиональный диагноз строится не из фразы «там много экранов». Спросите, зачем нужен каждый дополнительный шаг после ясного намерения уйти. Если он сообщает существенное последствие — например дату прекращения доступа, — это может помогать выбору. Если новые экраны лишь повторяют предложение остаться и заставляют снова подтверждать то же решение, аргумент в пользу hard to cancel становится сильнее.
Манипуляция не всегда требует длинного сценария. Иногда достаточно двух кнопок, если их подписи заставляют человека неверно понимать, от чего именно он отказывается. Банк России — российский регулятор финансового рынка — публикует реальные случаи поведенческого надзора. В одном из них при оформлении онлайн-займа решение о дополнительной платной услуге предлагалось выразить кнопками «Подписать договор» и «Отказаться от заявки». Регулятор отмечал, что такая формулировка может создать ложное впечатление: будто человек решает судьбу самого займа, а не отдельной услуги.[17]
Обратите внимание: проблема находится не в цвете кнопок и не в том, что продукт вообще предлагает дополнительную услугу. Интерфейс связывает отказ от второстепенного предложения с гораздо более серьёзным последствием — отказом от основной заявки. Ниже справа показана учебная прозрачная альтернатива; это не формулировка Банка России, а способ увидеть, что именно нужно исправить.
Для решения о дополнительной услуге: «Подписать договор» / «Отказаться от заявки». Человеку трудно понять реальное последствие отказа.
Учебная альтернатива: «Подключить дополнительную услугу» / «Продолжить без услуги». Обе подписи говорят о том решении, которое принимается на этом шаге.
Банк России рекомендует исключать неоднозначные формулировки и давать человеку доступный выбор согласиться или отказаться именно от дополнительной услуги.[17] Этот кейс полезен ещё и потому, что не требует угадывать «злой умысел» команды: достаточно показать, как устройство выбора способно исказить понимание последствий.
Тема остаётся актуальной и для современных банковских интерфейсов. В июле 2026 года Банк России отдельно писал, что по жалобам пользователей банки нередко подчёркивают привлекательные характеристики продуктов, а риски и специальные условия раскрывают неполно; регулятор связывает будущие требования к информированию в том числе с устранением «тёмных паттернов», манипулирующих поведением клиентов.[18] Для дизайнера отсюда следует практический вывод: значимая информация должна быть понятна в момент решения, а не обнаруживаться после него.
Продукту нужны продажи, регистрации, подписки и повторные визиты. Само по себе это не делает интерфейс неэтичным. Проблема начинается, когда нужный бизнесу результат достигается за счёт того, что человек не замечает условие, не понимает последствия или сталкивается с искусственным препятствием при отказе.
Удобный способ думать об этом — разделять убеждение и подрыв информированного выбора. Можно показать преимущества тарифа, сравнить варианты, напомнить о сроке реального предложения. Но если результат зависит от скрытой комиссии, ложного таймера, унизительного текста отказа или намеренно сложного выхода, интерфейс уже использует слабость принятия решения как рычаг.
Для учебного ревью используйте пять вопросов. Это не отраслевой стандарт и не юридический тест, а рабочая рамка курса:
Последний вопрос особенно полезен. Если бизнес-результат держится только потому, что часть людей не заметила включённую услугу, не поняла стоимость или не нашла отказ, проблема находится не в «слабом тексте кнопки», а в самой модели взаимодействия.
После этого урока название компонента должно быть последним, а не первым шагом рассуждения. Начните с того же способа мышления, который уже использовали в предыдущем уроке: задача, контекст, ожидание и последствия действия.
Следующий урок будет уже не про происхождение ожиданий и не про каталог паттернов. Там мы соберём базовую систему самопроверки интерфейса: последовательность решений внутри продукта, обратную связь, предотвращение ошибок и другие базовые практики. Здесь достаточно уметь ответить на более ранний вопрос: почему это решение вообще здесь появилось и соответствует ли оно проблеме и интересам пользователя?
В этом задании не нужно искать «кто сделал лучше». Ваша цель — отделить устойчивые свойства паттерна от деталей конкретной реализации и увидеть, где знакомый механизм перестаёт соответствовать задаче.
Мысленно замените цвета, радиусы, шрифт и расположение списка. Если принцип взаимодействия всё ещё узнаётся и решает ту же проблему, вы, скорее всего, смотрите на паттерн, а не на визуальный стиль.
C. Паттерн связывает повторяющуюся проблему, контекст и принцип решения. Цвет, геометрия и конкретное расположение списка могут меняться, не разрушая сам принцип.
A. Хлебные крошки полезны для иерархии. Ошибка — не в компоненте как таковом, а в механическом переносе решения на другую задачу.
B. Повторяемость сама по себе не делает решение хорошим. Если механизм стабильно вредит задаче, его можно диагностировать как антипаттерн, не приписывая команде непроверенное намерение.
C. Отказ доступен, но его формулировка пытается вызвать вину или стыд. Это и есть механизм confirmshaming.
B. Существенная стоимость раскрывается только поздно, после того как человек уже сравнивал варианты и вкладывал время, исходя из другой цены.
C. Fake urgency основана на ложной или вводящей в заблуждение срочности. Честное отображение реально действующего срока само по себе не является этим механизмом.
C. Историческое или отдельно зафиксированное наблюдение годится для разбора механики, но не заменяет проверку текущего продукта. Официальная инструкция подтверждает путь отмены, а не полную структуру каждого промежуточного экрана.
B. Сама предустановка ещё не объясняет эффект. Нужны контекст, последствия и понимание того, получает ли человек прозрачный выбор или сервис рассчитывает на то, что опцию не заметят.
B. Подписи говорят не о том решении, которое человек принимает на этом шаге. Из-за этого отказ от второстепенной услуги может восприниматься как отказ от самого займа — именно эту проблему отмечал Банк России.
C. Ключевой красный флаг — зависимость результата от непонимания, невнимательности или искусственно затруднённого отказа.