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

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

Они не выглядят багами. Они выглядят «как обычно». И именно это делает их опасными. Пользователь даже не возмущается — он молча спотыкается, перестраивается и уходит с ощущением, что опять что-то сделал не так.

В этой статье — четыре рудимента, которые всё ещё встроены в корпоративные продукты, B2B-сервисы, государственные интерфейсы и даже массовые платформы. У каждого из них:

  • была причина появиться,

  • есть причина до сих пор не умереть,

  • и есть точка, где UX просто перестаёт быть UX, превращаясь в саботаж взаимодействия.

1. CAPTCHA — защита, которая наказывает

Форма почти заполнена. Остался один шаг.
И тут система просит доказать, что ты не робот.
Найди все автобусы. Все светофоры. Все лодки, если останешься в живых.

На фоне 2025 года это выглядит особенно иронично. Особенно когда ты — платящий клиент.

Откуда это взялось

Классическая CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) появилась в 2000-х. Изначально — как способ фильтровать ботов на форумах, логинах и формах.

Было простое правило: робот не распознает и не решит, человек справится.

Почему это устарело

Современные боты решают капчи лучше людей.
Существуют сервисы, где реальные люди за 0.001$ проходят их за скрипт.
Google давно перешёл на невидимую CAPTCHA v3, где пользователя даже не беспокоят — поведение анализируется по IP, движению мыши, скорости взаимодействия.

Решение — не "ввести текст", а просто двигаться естественно.

Почему это до сих пор используется

Потому — что бесплатно, включается по умолчанию.

В B2B-продуктах и государственных сервисах безопасность трактуется буквально: “если защита работает хотя бы у кого-то — ставим”.

Плюс: никто не считает потери.

Почему это ломает взаимодействие

  • Среднее время прохождения капчи — 6–8 секунд.

  • Частота ошибок на мобильных — до 30%.

  • Часто человек не понимает, что именно не так: он выбрал автобусы, но не все. Он промахнулся, но это не сказано.

Это торможение не из страха, а из унижения: ты чувствуешь, что тебя проверяют не на человечность, а на терпение.

Где это до сих пор встречается

  • Регистрации на государственных порталах.

  • Вход в админки B2B-платформ.

  • Legacy-продукты, которые не перешли на invisible или soft validation.

Что об этом говорят

  • Google: пользователи потратили ~819 млн часов на прохождение капч.

  • Baymard Institute: до 30% пользователей не проходят форму, если капча стоит в конце.

  • NNGroup: “капча увеличивает показатель отказов в 2–3 раза в зависимости от типа формы”.

2. Модалка “ОК / Отмена” — вы всё ещё уверены?

Один из самых живучих UX-рудиментов — модальное окно с кнопками «ОК» и «Отмена». Казалось бы, нейтральный паттерн. Пока не начинаешь читать текст над кнопками.

“Удаление текущей сессии приведёт к потере несохранённых данных. Продолжить?”

И под ним —
[ОК] [Отмена]

Что именно делает «ОК»?
Что конкретно отменяется «Отменой»?
Ты знаешь, что хочешь нажать — но не знаешь, какая из кнопок это сделает.

Как это вообще появилось

Стандартная пара из эпохи десктопных систем.
UI-библиотеки Windows и раннего MacOS строились по шаблону: сообщение + [ОК]/[Cancel]. Это была не дизайнерская идея — это было решение для разработчиков. Работает, значит нормально.

Почему это устарело

Современные модалки не служат подтверждением действия по умолчанию. Они контекстны:
— “Удалить файл?” → [Удалить] / [Отменить]
— “Выйти без сохранения?” → [Выйти] / [Остаться]
Пользователь должен видеть конкретное действие. ОК/Cancel — это не действие, это комментарий к действию, причём внутренний.

Почему это живёт

  • В большинстве UI-китов это дефолтный шаблон.

  • Дизайнеры и разработчики используют модалку как быструю заглушку.

  • Команды не валидируют тексты кнопок. Формулировки проверяются разве что на грамматику — не на смысл.

Почему это ломает взаимодействие

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

Где это до сих пор встречается

  • Bitrix24, SAP, Zoom

  • Часто используется в no-code конструкторах и внутренних админках.

  • В браузерных плагинах и установщиках ПО.

Что об этом говорят

Baymard Institute: «неконкретные подписи кнопок в диалогах — одна из ключевых причин ошибочного поведения». В их исследовании 2023 года это вошло в топ-3 источников фрустрации при подтверждении действия.

3. Повторный вход — когда интерфейс не доверяет даже сам себе

Ты в системе. Всё запомнено, ты авторизован, ты действуешь.
Но на попытке настроек, удаления или скачивания —
“Пожалуйста, введите пароль ещё раз”

Система внезапно теряет память.

Откуда это

Повторный вход — это след старой модели безопасности, где:

  • сессии были короткими,

  • токены хранились в cookies,

  • и не было ни 2FA, ни OAuth, ни биометрии.

Чтобы подтвердить важное действие — требовался ручной пароль. Всегда. Даже если ты только что авторизовался.

Почему это больше не актуально

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

  • Есть модели “Just-In-Time” верификации без разрушения контекста.

  • Повторный ввод стал не гарантией безопасности, а ритуалом недоверия.

Почему это до сих пор используется

  • Так проще — не надо думать, как разграничивать “опасные” действия.

  • Архитектура систем часто не поддерживает гибкую повторную верификацию.

  • Это выглядит безопасно.

На деле — просто дешёвый костыль.

Почему это ломает взаимодействие

  • Потеря фокуса. Ты в потоке, и вдруг — пауза.

  • Восстановление пароля, которого не помнишь, в середине действия.

  • Нарушение доверия: система будто намекает, что ты — не ты.

Это не безопасность. Это насильственный рераутинг действия, без смысла и без пользы.

Где это часто встречается

  • Госуслуги, банки, SAP, Salesforce.

  • Старые CRM и HRM, где любой экспорт или удаление требует re-login.

  • Даже в крупных e-commerce — при добавлении платёжных данных.

Что об этом говорят

  • Google UX research: повторный вход вызывает раздражение у 45% пользователей.

  • В сложных B2B-интерфейсах это увеличивает риск отказа от действия до 30%.

  • NNGroup: “повторное подтверждение паролем — одна из самых ненадёжных и UX-неграмотных форм безопасности”.

4. Выбор страны: когда UI решает, кто ты

Форма регистрации. Поле “Страна”. Выпадающий список.
Ты листаешь. Казахстан, Кения, Кипр, Киргизия…

Где Республика Корея?
А Республика Конго? А Республика Беларусь?

Ты ищешь по букве — но не находишь. Потому что в одном случае страна называется “Республика Армения”, в другом — просто “Армения”. Потому что UX списков — это не отражение мира, а отражение того, кто как в базе записал.

Историческая подоплёка

Списки стран — наследие стандартов ISO-3166.
Но дальше начинаются детали:

  • что брать за название — короткое или официальное?

  • что отображать первым — "Корея, Республика" или "Южная Корея"?

  • где искать Южный Судан — под Ю, С или СС?

UX-компоненты часто не думают о семантике — они берут то, что заведено.
А значит, флаг — это картинка.
Название — это строка.
А человек — должен сам догадаться, как его страна тут называется.

Почему это рудимент

В современном UX можно:

  • использовать адаптивный поиск (не по началу, а по вхождению);

  • дать автоопределение страны с возможностью ручного редактирования;

  • вынести регионы, политические зоны и спорные территории в нейтральные UI-группы.

Но чаще всего используется выпадающий список на 200+ позиций, отсортированный по алфавиту, без нормализации и без логики.

Почему это ломает взаимодействие

  • Пользователь не может найти свою страну привычным способом.

  • Он не знает, как она здесь называется.

  • Иногда он вообще не уверен, включена ли она в список (особенно если речь о непризнанных, спорных или оккупированных территориях).

Где это живёт

  • Международные SaaS-продукты и банки;

  • Формы в визовых и миграционных системах;

  • Все интерфейсы с ISO-стандартами “из коробки”.

Что об этом говорят

  • UX Planet: “Country pickers are where design meets diplomacy. And often loses.”

  • NNGroup: “If a user can’t find their country, they will assume your product is not for them.”

  • Исследование WebAIM: пользователи с непризнанных территорий на 68% чаще покидают форму до завершения регистрации.

UX как инерция власти

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

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

Устаревшие модалки, PDF вместо интерфейса, капчи, сломанные списки стран — это не "небрежность", а отказ пересматривать старую модель взаимодействия.
А значит — не UX, а власть привычки над точностью, логикой и уважением к человеку.

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

Комментарии (2)


  1. rPman
    30.06.2025 07:41

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

    “повторное подтверждение паролем — одна из самых ненадёжных и UX-неграмотных форм безопасности”.

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


    1. loralu Автор
      30.06.2025 07:41

      Да, повторный ввод может быть оправдан — если понятно зачем.

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

      Например, в старых CRM запрашивают пароль повторно, чтобы просто скачать отчёт в PDF — без данных, без доступа к транзакциям. Для системы это «безопасность», а для человека — нелепость.

      Проблема не в требовании, а в том, что оно не обосновано на уровне интерфейса. Это выглядит не как защита, а как баг.