Некоторые интерфейсные решения не устарели — они просто не были пересмотрены. Они живут по инерции: из-за юридических формальностей, технических ограничений или просто потому, что «так уже есть». Часто — это не чья-то ошибка, а результат слишком длинной цепочки допущений.
Во второй части (первая тут) продолжу разбирать рудименты — те фрагменты UX, которые когда-то имели смысл, но больше не работают. Мы посмотрим на них не с точки зрения «плохо», а с точки зрения: почему так получилось, почему до сих пор так, и как это решают сейчас.
Фокус на российском рынке.
Переводы по старым банковским формам: БИК, корр. счёт, ИНН
— У нас тут не просто UX, а межбанковская инфраструктура.
Большинство российских банков до сих пор предлагают форму для перевода, в которой пользователь должен вручную указать БИК, корреспондентский счёт, ИНН и КПП. Казалось бы, в 2025 году это должно быть автоматизировано. Но такие формы живут и в крупных банках (Сбер, ВТБ, Альфа при переводе юрлицам), и в B2B-финтехах, и даже в госуслугах.
Историческая подоплёка
Система межбанковских расчётов устроена так, что БИК и корр. счёт действительно участвуют в маршрутизации денег через ЦБ. Эти поля — не для человека. Это язык бухгалтерии и межбанковских шлюзов. В прошлом — нормальный UX: бухгалтер знал, что и куда вбить.
Почему до сих пор так
Банки не хотят брать на себя ответственность за автоматическое подставление реквизитов. Добавим юридическую неуверенность, неполные справочники организаций и неравномерную интеграцию с ФНС/API — и получим форму, которую проще оставить ручной. Особенно для юрлиц.
Почему потеряло смысл
Сегодня большая часть этих данных может подтягиваться автоматически. Достаточно ИНН или расчётного счёта — и можно собрать всё остальное. Более того, пользователю это просто не нужно. Ему нужен уверенный результат, а не список полей, за каждое из которых он боится.
Почему ломает UX
Пользователь не понимает, за что отвечает каждое поле. Это вызывает тревогу, откладывание действия или обращение в поддержку. UX превращается в стрессовый квест с бухгалтерской терминологией. И да, даже хинты (?) не помогают.
Согласно данным usability-тестов Точки и исследования ProductLab (2022), упрощённый флоу перевода с автоподстановкой по ИНН увеличил завершение переводов на 34%, а количество обращений в поддержку по теме реквизитов снизилось почти вдвое.
Как решают
Точка и Модульбанк сделали флоу, в котором ИНН — это всё. Система сама проверяет валидность, подставляет нужные поля и показывает превью компании. Бухгалтеры счастливы, фрилансеры — ещё больше.
Оплата без прозрачного breakdown: сумма есть, контекст — нет
— Деньги списали, а что именно я оплатил — остаётся тайной.
В интерфейсах оплаты часто можно увидеть только финальную сумму. Всё. Ни разбивки по комиссиям, ни уточнений по курсу, ни структуры скидки или налога. Особенно актуально для агрегаторов (например, доставки или страховые платформы), где много посредников.
Историческая подоплёка
Это наследие старых систем эквайринга и классической «кассовой логики»: пользователь — плательщик, детали для бухгалтера. Отображение подробностей считалось избыточным.
Почему до сих пор так
У продукта нет доступа к точным данным до финального расчёта (например, комиссия определяется банком или агрегатором динамически). А конверсия считается важнее прозрачности. А значит — меньше деталей, быстрее путь к кнопке.
Почему потеряло смысл
Пользователь стал внимательнее. Он ожидает детализации, особенно в финансовых продуктах. Прозрачность = доверие. В противном случае — это повод для чарджбека, жалобы или отказа от следующей транзакции. (Не люблю за это сервисы оплаты чаевых)
Почему ломает UX
В финтехе это разрушает ощущение контроля. Особенно в подписках, страховании, трансграничных платежах. "Вроде согласился, но что именно я оплатил — уже не вспомнить."
По данным исследования Deloitte Digital (2021), 48% пользователей считают непрозрачную оплату главным фактором потери доверия в финтех-приложениях. А 3 из 10 отказов от повторной транзакции связаны с неожиданными комиссиями.
Как решают
Wise (ex-TransferWise) показывает в реальном времени: курс, комиссии, итог к зачислению. В России Сбер и Альфа в некоторых сценариях стали отображать комиссию постфактум, но до прозрачного breakdown пока далеко. В агрегаторах (например, Тинькофф Страхование) некоторые продукты уже показывают развёрнутую структуру цены до оплаты.
Секретные вопросы при восстановлении доступа
— Как звали моего четвертого хомяка?
Google в исследовании 2019 года показал, что около 40% пользователей не могут восстановить доступ через секретные вопросы. Точность угадывания злоумышленниками достигала 19,7% — выше, чем при брутфорсе слабого пароля. Этот метод давно признан уязвимым, но по инерции продолжает использоваться.
Историческая подоплёка
Системы построены на устаревших стандартах безопасности. А сменить флоу сложно из-за зависимости от внутренней архитектуры, требований ИБ или формальных аудитов.
Почему потеряло смысл
Пользователи не помнят ответы. Ответы можно легко найти в соцсетях или угадать. Это компромисс между кажущейся безопасностью и реальной уязвимостью.
Почему ломает UX
Ты не можешь восстановить доступ. И злишься не на себя, а на продукт. Потому что тебя поставили в тупик вместо того, чтобы помочь.
Как решают
Современные финтех-продукты (Тинькофф, Сфера, ЮKassa) переходят на комбинацию одноразовых кодов, биометрии, авторизации по сессии. Госуслуги, к слову, уже используют подтверждение через ЕСИА и пуш-подтверждение через мобильное приложение.
Повторный ввод пароля при регистрации
— Если я ошибся, скажи сразу. А не заставляй делать всё заново.
Согласно исследованию Baymard Institute (2023), 12–18% пользователей не завершают регистрацию, если в форме есть обязательный повторный ввод пароля. Особенно это критично на мобильных устройствах, где вероятность ошибки выше, а возврат к редактированию сложнее.
Историческая подоплёка
Паттерн живёт в CMS, шаблонах, внутренних UI-kit'ах. Его внедряют по умолчанию. А риск опечатки — всё ещё фобия для безопасников.
Почему потеряло смысл
Мы можем показывать пароль (?), валидировать его в реальном времени и сразу сообщать об ошибке. Второе поле превращается в бессмысленную фрикцию.
Почему ломает UX
Особенно на мобильных. Люди чаще бросают регистрацию, чем исправляют поле. И чем сложнее требования к паролю, тем выше риск ошибиться.
Как решают
Большинство крупных продуктов (VK, Яндекс ID, Озон) уже отказались от повторного поля. Вместо него — ?, индикатор надёжности и моментальная проверка. А если опечатался — просто замени. Без танцев с двумя полями и бубнами у пепелища.
Финалочка
Эти UX-рудименты — не баги дизайна. Это следы старых инфраструктур, юридических фобий и фрагментарных решений. Но пора признавать: пользователь больше не живёт в 2012-м. Он ждёт ясности, предсказуемости и уважения к своему времени. А мы — те, кто может это ему дать.
Комментарии (36)
Licemery
21.07.2025 06:21Все решения с ориентацией на мобилы вместо нормальных платформ хуже любого из "устаревших". Ненавижу телефонистов.
Black_Spirit
21.07.2025 06:21Да уж. Приучили их тыкать сосисками. Так они и по нужде когда ходят, тыкать не перестают. Какой уж тут UI..
anastasyakosh
21.07.2025 06:21Что именно ты имеешь ввиду под "нормальной платформой"?
AndrewBond
21.07.2025 06:21PC разумеется.
Подразумевается не то, что мобильные платформы неполноценные (речь не об этом сейчас), а то, что если PC UX на мобилках плох (правда), то почему считается нормальным обратный путь - UX мобилок тащить на PC. Вот это необъяснимо.
anastasyakosh
21.07.2025 06:21Очень даже объяснимо: есть практика Mobile First. Она оптимизирует скорость и проста в масштабировании на десктопы.
Исторически сайты делали сначала для десктопа, а потом пытались адаптировать под мобильные. Это часто приводило к перегруженным интерфейсам на маленьких экранах.
Mobile First меняет приоритет: сначала создается версия для мобильного устройства (минимум контента и элементов), а затем интерфейс расширяется для больших экранов
AndrewBond
21.07.2025 06:21Очень хорошо обосновано, почему перенос десктопных практик на мобилы плох. Но, ничего не сказано о том, что мобильный интерфейс на десктопе не менее убог, и о том, почему вдруг решили, что так делать можно. Судя по всему, никакого "а затем" после "сначала" в большинстве случаев не бывает.
anastasyakosh
21.07.2025 06:21Хочется пруфов. Хотябы два примера, где мобилку плохо перенесли на десктоп
AndrewBond
21.07.2025 06:21Навскидку, например, сайт baucenter. Теперь на странице помещается где-то на 50% меньше информации. Шрифты, отступы и тд сделаны "по-мобильному", что на десктопе выглядит как полный хаос. Там еще креативные дизайнеры поработали. Возможно, часть хаоса не из-за мобиле-ферст, а из-за них. Не самый красноречивый пример, но первый вспомнившийся.
SteveVess
21.07.2025 06:21У получателя 10 счетов в разных филиалах или в одном. Как по инн получить нужный?
AndrewBond
21.07.2025 06:21получатель указывает ИНН нужного банка, вместо названия банка, ИНН, БИК, корсчета и что там еще.
inkelyad
21.07.2025 06:21получатель указывает ИНН нужного банка
Что есть глупо. Если все равно какой-то набор цифр вводить - то надо вводить сразу все нужные в одном поле, а не размазывать по нескольким Смотри мое сообщение ниже про IBAN. Но банки почему-то его использование для внутренних платежей не внедряют.
AndrewBond
21.07.2025 06:21Зачем вводить все нужные? Зачем их вообще знать?
inkelyad
21.07.2025 06:21Зачем вводить все нужные? Зачем их вообще знать?
У меня, скорее, вопрос, зачем знать какие-то ИНН что банка, что получателя?
На но платежке (любого вида) должен же быть условный адрес назначения, куда деньги должны попасть? Ну вот и копипастим этот IBAN, не разбираясь с его структурой.
Одна непрерывная строка тут удобна тем, что ее можно в баркод закодировать и быстро прочитать в форму почти чем угодно.
С другой стороны, есть еще ГОСТ Р 56042-2014 который про тот QR, что обычно на платежках ЖКХ стоит, но никто не запрещает использовать его еще много где -- это, по сути, данные для той стандартной формы банковского перевода. И приложения банков его могут более-менее читать. А вот предоставлять все реквизиты в таком виде мало кто догадывается.А руками вводить неудобно что так что так.
AndrewBond
21.07.2025 06:21> зачем знать какие-то ИНН что банка, что получателя?
Мне всё равно, как называется эта строка. Главное, чтобы она была одна. Сейчас при вводе ИНН (относительно короткой строки) все остальные поля заполняются автоматом, что для меня сущее облегчение.
AndrewBond
21.07.2025 06:21PS: могли бы уточнить, что IBAN включает все банковские реквизиты, включая сам счет. Было бы понятнее. Я говорил только о реквизитах банка.
Так-то да. Одна строка для полного описания назначенияinkelyad
21.07.2025 06:21могли бы уточнить, что IBAN включает все банковские реквизиты, включая сам счет.
Смысл в том, что это несущественно - знать, что там у него внутри. Существенно, что достаточно одной этой строки, без дополнительного ввода. чтобы деньги попали туда, куда надо.
Правда, часто надо еще разные номер лицевого счета указывать, что там не предусмотрено, и их нужно отдельно вводить. Тут совсем одной строки не предусмотрено и QR по ГОСТ Р 56042-2014 будет удобней, хоть он и здоровый.AndrewBond
21.07.2025 06:21Смысл в том, что это несущественно - знать, что там у него внутри.
Ну вот вы второй фразой себя же опровергаете
Правда, часто надо еще разные номер лицевого счета указывать
Мне реально неважно, что означает тот номер, который я ввожу. Мне должно его хватать для всего. И я не должен думать, нужно ли в данном случае еще что-то довводить, или нет.
PS: я понятия не имею, что такое "лицевой счет" и чем он от других счетов, которыми меня пытают банки в своих платежках, отличается. Оплата по платежкам - боль.
Те, кто предлагает "оплату по QR" такие же недалёкие создания, как и те, кто требует все двадцать реквизитов банка -
Каким образом мне оплатить по QR с квитанции, прошедшей через средний офисный ксерокс или сделать то же самое с десктопа, они не думают.
inkelyad
21.07.2025 06:21: я понятия не имею, что такое "лицевой счет" и чем он от других счетов, которыми меня пытают банки в своих платежках, отличается.
А это проблема уже не столько UI-я, сколько всей системы оплат, увы.
Потому что банк не может за организацию учитывать, за что там ей деньги пришли.Те, кто предлагает "оплату по QR"
Больше никуда нужные данные просто физически не влазят. Даже если изобрести индивидуальный идентификатор на прлатежку, который включает все-все-все - это будет слишком длинная последовательность цифр.
Каким образом мне оплатить по QR с квитанции
Печать QR покрупнее, чтобы выживал при копировании. Починить ксерокс. Если он не выполняет свою функцию - сохранять содержание документа, то он явно не пригоден к эксплуатации.
сделать то же самое с десктопа, они не думают.
Если набирать руками - удобно не будет никак. Ни на десктопе, ни на телефоне. А у большинства людей есть таки сенсоры (в телефонах, да), чтобы руками не набирать. И, увы, сейчас "без смартфона жизни нет". Тот, кто сейчас настаивает, что смартфоном пользоваться не намерен - это уже сознательный выбор неудобного способа.
Но есть альтернативы, да.
(1) когда плательщик сообщает, откуда брать деньги (например, вбив номер банковской карты). И набирать надо мало. Но там свои проблемы, как мы знаем.
(2) получатель платежа посылает куда-то платежку, чтобы банк ее увидел и предложил оплатить. Вопрос, только, куда и как.
inkelyad
21.07.2025 06:21Большинство российских банков до сих пор предлагают форму для перевода, в которой пользователь должен вручную указать БИК, корреспондентский счёт, ИНН и КПП
И поэтому ЦБ уже давно (хотя нужно было сильно раньше) одобрил использование IBAN.
Ну да, длинный, но поле ввода одно, не надо задумываться что есть что.
ArtyomOchkin
21.07.2025 06:21Да уж, одна из самых неудобных вещей - типичные phpшные формы регистрации на всяческих сайтах/форумах. Мало того, что скопипастить пароль во второе поле ввода часто не предоставляется возможным (мешает отсутствие значка показать пароль, при
<input type="password">).А при неверном вводе сбрасываются ВСЕ поля формы, что сильно раздражает. Особенно при наличии дополнительной капчи или наличия большого количества полей. Хотя вполне можно было реализовать автосохранение введённых данных на время регистрации через LocalStorage.
Kerman
И как я скажу, что пользователь ошибся? Как я пойму?
Так может не так уж и бессмысленно? Пользователь дважды вводит пароль и вероятность, что он ошибся дважды на несколько порядков ниже, чем вероятность ошибиться один раз.
loralu Автор
Мне кажется, важна причина в целом - использования пароля, как входа.
Это либо авторизация по почте, либо по нику. Что делает аккаунт менее "безопасным".
Если говорим про безопасность, по исследованиям - 2 из 3 человеков выбирают биометрию, как способ авторизации. Проще и воспринимается безопаснее.
Отсюда, танцы с бубнами при создания пароля будто немного изживают себя. Но все же, если он требуется - используют живой валидатор, который сразу сообщает в моменте требования пароля. Увидела недавно, что условия начали упрощать для этого способа (не знаки+символы+латиница+цифры+названия заграничной страны, а связка символов+цифр).
johnfound
Я бы тоже спросил, как система может сказать что пользователь ошибся, когда он вводит новую пароль, которую только что придумал?
obabichev
del
anastasyakosh
Вот так, бро
johnfound
Ну, я считаю что сама практика показывать пароли явным текстом, очень плохая по определению. Сколько из пользователей проверяют свои пароли после первого введения? Да и оно может быть полезно когда вводим пароль для входа в систему, а не при выборе нового пароля.
Кроме того, введение требований к пароли, вне зависимости от того какие они, на самом деле абсолютно бесполезно и только уменьшает пространство паролей никак не повышая их силу. «Password!1» – это словарный пароль, несмотря что полностью соответствует требованиям.
anastasyakosh
Это лишь твои домыслы и гипотезы, которые ничем не подтверждены. А пример выше - это база, которую должен знать любой Джун.
Дам тебе непрошеный совет: проверяй информацию прежде, чем утверждать что-то
loralu Автор
Учитывая ваш второй абзац, вы сами говорите, что паролю - доверия нет. И проблема не в подсказках к полю/удобства ввода проверочного пароля. А в самой логике его использования, как основного способа последущего входа при регистрации.
Смысл тогда разбирать подфоу/кейс?
В формате хороших практик, отметила, где есть хорошие примеры решения этого флоу. Но опять же, крупные продукты, которые владеют огромной базой данных о пользователях, делают упор на другие способы авторизации.
johnfound
Ну, почему? Надо просто не ограничивать пользователя в выборе пароля. И метод с повторным вводом на самом деле вполне надежный и проверенный временем – не надо придумывать варианты, просто чтобы что-то обновить. Точно так же как и не надо принуждать пользователя к безопасности – он все эти требования обойдет легко и с удовольствием. Надо сделать так, чтобы выбирая слабый пароль и если что случится, страдал только этот пользователь и не страдали остальные пользователи.
anastasyakosh
Расскажи эту теорию безопасникам)
johnfound
Ну, безопасники – они разные. Корпоративные очень любят чтобы выглядело безопасно и официальные политики соблюдались. Является ли система безопасной на самом деле им совершенно безразлично.
loralu Автор
Логичный филовсовский вопрос, а кому по вашему мнению тогда не безразлична безопасность пользователей? Стартапам?
Но, я понимаю, что мнение сформировано (скорее всего) из-за огромного количества слитых данных пользователей крупных сервисов.
И опять же это не повод - не стараться делать безопасные интерфейсы и придумывать новые механики тем же корпорациям.
johnfound
Ну, например мне не безразлична безопасность моих же ресурсов в сети. А кстати, хорошая притча:
Можно сделать систему полностью опасной. Полностью безопасной ее сделать в принципе нельзя. К тому же, надо внимательно анализировать какие меры увеличивают безопасность и какие просто создают «видимость безопасности». Такая видимость намного, намного опаснее, чем не делать ничего. Вот я продемонстрировал, что требования к содержанию пароли никак не уменьшает возможность для пользователя придумать словарные пароли. И он наоборот – начнет их придумывать намного чаще, просто потому что запоминать реально сложного пароля очень трудно. Тем более, если эти пароли его вынуждают менять каждые 2..3 месяца. Наоборот – если настаивать чтобы пользователи использовали рандомные пароли + менеджер паролей, это запросто увеличит безопасность. Даже если советовать пользователей записывать пароли на листке, но чтобы хранили эту бумажку в бумажник , это тоже увеличит безопасность системы. Но оно выглядит «опасным» и поэтому такое никогда не примут.
loralu Автор
Вы изначально говорили про безопасников корпораций) потому мой вопрос в полном виде звучал бы - каким конкретно безопасникам тогда не все равно на данные пользователей? Или таких безопасников нет?
Демонстрация притчи - это базовые байки по поводу безопасности данных защищенных паролем, которые имеют место быть. Но пароли - это не единственный способ авторизации на момент 2025 года. Их основных только 14 (а так их более 30), и их используют в разных комбинациях, чтобы защитить данные пользователя. И/или делать вход в сервисы комфортным.
anastasyakosh
Откуда теория про безразличие? Это ваш личный опыт?