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

«Как у всех»
Каждый квартал мы проводим в Альфа-банке много разных исследований. Довольно часто мы прибегаем к необходимости проанализировать, как тот или иной функционал реализован на других цифровых сервисах. Для чего? Например, чтобы использовать паттерн/сценарий, знакомый пользователям, а не придумывать «велосипед».
Мы анализируем то, с чем чаще всего могут взаимодействовать наши пользователи: банки-конкуренты, популярные платформы, маркетплейсы, мобильные приложения и так далее. И, допустим, после анализа мы видим, что в приложениях конкурентов чаще всего используется некий паттерн. Стоит ли его внедрять к себе без колебаний, потому что «у них же есть»?
Отнюдь. Давайте убедимся в этом на примерах.
Пример №1: развёрнутый список
Для начала рассмотрим иконку стрелки вниз (он же «шеврон») — очень распространенный и, казалось бы, очень понятный по своему действию, элемент, функция которой — развернуть/свернуть. Так думали и мы….Но решили проверить, как он воспринимается пользователями.
На качественном исследовании мы дали пользователям задание: найти счёт с номером «***7856» компании «Изюм+», чтобы посмотреть, как они взаимодействуют с «шевроном».

Как писала выше, мы считали, что элемент интуитивно понятен по своему действию, но пользователи просто не замечали, что компанию можно развернуть и увидеть входящие в неё счета. Они думали, что смогут увидеть только конкретный счёт — через поиск. Это вызывало непонимание и негатив.
Так как на качественном исследовании мы были ограничены в количестве респондентов, то решили удостовериться в критичности проблемы и проверить данный паттерн на количественном исследовании (first click test, проводился для раздела «Выписка» на платформе Альфа-Бизнес). И, внеся небольшую доработку, сделали список второй компании раскрытым по умолчанию. Мы предполагали, что это даст больше понимания пользователю, что внутри компании — счета, а список можно развернуть/свернуть.
Однако, раскрытие «шеврона» второй компании не помогло пользователям понять механизм работы вложенности счетов в компанию внутри фильтра. 109 человек сделали клик на чекбокс возле компании и 40 человек на ООО «Город Ногатино», и всего 9 на целевую область «Шеврон».
Резюмируя: мы решили оставить по умолчанию раскрытыми все списки внутри фильтра, а также провести А/Б тест с шевронами и без уже на платформе нашего банка (так сказать «на бою»), но это уже совсем другая история.
Пример №2: очистка поиска
Ещё один распространённый элемент, применяемый для очистки поля от введённых данных, — крестик в поиске.
На качественном исследовании пользователям давали задание: после найденного счёта с номером «***7856» компании «Изюм+», необходимо выбрать все счета компании «Город Ногатино». Соответственно, функциональность крестика была в том, чтобы удалить данные из поля поиска.

Но...пользователи не стирали поиск, чтобы вернуться к списку компаний в фильтре «Счёт компании». А некоторые и вовсе не замечали крестик.
Подумав над результатами эксперимента взаимодействия с поиском, мы пришли к выводу, что у пользователей нет сложившегося паттерна использования поиска повторно, чтобы стереть и вбить другой запрос в рамках фильтра. Хотя, такой паттерн встречается не так уж и редко, и не проведя исследование мы могли бы прийти к выводу, что такая функциональность привычна пользователям и её стоит внедрить. Но этот вывод был бы ошибочным.
Пример №3: действия в таблице
Данный пример отличается от выше приведенных. Речь пойдёт об одном паттерне, который может работать в одном продукте, а в другом — нет.
Опуская часть с заданием, перейдём сразу к выводам. На качественном исследовании пользователи одного продукта отметили, что им удобнее, если иконки действий будут располагаться в «трёх точках». При этом на таком же исследовании в другом продукте итог был... обратным.

Почему так получилось? Потребности и частота взаимодействия с действиями в таблицах у пользователей в данных продуктах разная. И если в первом случае действия были крайне нечастыми, то во втором — регулярными.
«Мораль сей басни такова»
Подытожив всё вышесказанное, выделю несколько мыслей.
Вывод №1. Не стоит слепо доверять паттернам, которые используются конкурентами, не удостоверившись, что вашим пользователям в продукте это подойдёт.
Добавляя новый элемент/сценарий «как у всех», можем ли мы быть абсолютно уверенными, что пользователь будет работать с функциональностью так, как задумано? А если пользователи привыкли к одному и тому же поведению того или иного элемента, будет ли правильно их «переучивать»? Ведь у нас нет данных о том, проводят ли конкуренты исследования, опрашивают ли пользователей о том, удобны ли им нововведения, анализируются ли инсайты и вносятся ли, соответственно, изменения.
Вывод №2. Если вы идёте в исследование — используйте возможность по максимуму, насколько это возможно, не выкидывая из сценария элементарные и понятные, на ваш взгляд, вещи.
Как часто мы изучаем привычную функциональность, привычные, казалось бы, сценарии взаимодействия пользователя с продуктом? Уверены ли мы на 100%, что пользователи работают с продуктом так, как мы задумали? Да, исследовать всё и вся не получится, конечно же. Но если есть возможность включить несколько вопросов о паттерне в рамках функциональной части, которую несете на исследования — используйте её.
Вывод №3. Даже в рамках одного ресурса паттерны могут отличаться в продуктах.
Если одному продукту подходит та или иная реализация, нет гарантии, что она подойдет для другого — копипаст и единообразие может сыграть плохую шутку, если не проверить, для начала, на исследовании.
Спасибо вам за внимание, надеюсь данная статья была для вас полезной и вы не зря потратили своё время. Делитесь в комментариях своим опытом, сталкивались ли вы с подобными случаями.
Подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.
Комментарии (9)
BykolajOptoed
22.01.2025 10:44Графические элементы выглядят так, что не понятно, что там что-то можно раскрыть. На экране маркированный список, шевроны воспринимаются, как украшательства.
Крестик выглядит как кнопка закрытия окна.
Т.е. в обоих случаях проблема в графическом дизайне компонентов. А ещё на этих примерах видно главную беду современного дезигна - безумные пустые пространства между элементами. Так бывает, когда дизайн для телефонов тащат в десктопный веб.
webhamster
22.01.2025 10:44пользователи просто не замечали, что компанию можно развернуть и увидеть входящие в неё счета
Конечно не замечали. Мы то ждем, что выпадающий список будет как отдельный элемент в виде кнопки с уголком или в виде поля ввода с уголком. У вас же элементы не имеют границ, поэтому не ясно что на них вообще можно нажимать. Догадаться что их к тому же можно развертывать - это с точки зрения пользователя надо предпринимать целое расследование, чтобы понять что имел в виду автор.
Да, еще нам нужно чтобы уголок был справа, как в привычных всем интерфейсах. Уголок слева может находиться в единственном случае - если это элемент дерева. Но вы пользователю никак не показали, что он работает с деревом: у вас пользователь видит список.
Зато места для галочек (правильно говорить - флажок) - видны замечательно. Тут то сразу понятно, что в них можно тыкать. Вот только к чему они там? Ведь пользователю надо найти счет, а не отмечать галочками юрлиц!
Я не дизайнер, но почему-то я вижу явные проблемы, которые есть в интерфейсе автора. Автор вроде и нащупал проблему (причем только одну - с непониманием развертывания списков), но как он это сделал? Запустив качественное исследование на пользователях, видимо, организовав фокус-группу со всеми сопутствующими делами. Это сколько ресурсов надо было потратить, чтобы понять базовые вещи? Мне становится страшно за современную айтишечку.
Я вижу, что дизайнеры UI постоянно делают одну и ту же ошибку: они заставляют пользователя исследовать интерфейс и его элементы. Когда пошла мода на кнопки без отрисовки их границ, сразу было ясно что ни к чему хорошему это не приведет. И пользователю сразу стало непонятно: вот эта надпись - это кнопка? А вот эта картинка - это кнопка, вызывающая действие или просто иконка оформления? А если я нажимаю на картинку и ничего не происходит, значит ли это что картинка - не кнопка? Может быть это все-таки кнопка, которая срабатывает при определенных условиях? Но дизайнеры были упорными: кнопки устарели! Границы кнопок зашумляют чистый дизайн! Хотите понять, что это кнопка - просто наведите на нее мышкой (зашибись, теперь в угоду дизайну пользователь должен возякать мышкой, чтоб понять с чем имеет дело). И внезапно та же проблема появилась в мобильных интерфейсах, но еще ужаснее: курсора мышки то в них нет. Хочешь понять, что это за элемент - ты должен на него нажать. Шикарно! Особенно рады пользователи, которые работают с финансовой информацией, где ошибочное или пробное действие может привести к сложно устраняемым последствиям.
Ну а о том, что в интерфейсах исчезли кнопки подтверждения и отмены, я вообще молчу, по-моему о них уже никто и не помнит.
Все, не буду больше писать, я только расстраиваюсь.
Norim_Nord
22.01.2025 10:44Соглашусь и дополню критику мнением по сценарию поиска.
У компании есть программисты, дизайнеры, менеджеры проектов, но... Нет бизнес-аналитиков? Никто не составляет BPMN-диаграммы?
На диаграмме обязательно был бы цикл <ввод-поиск-выбор-ввод-поиск-..>, если бы он требовался пользователю в 99% случаев.
Это в поисковой системе пользователю с высокой долей вероятности потребуется несколько запросов, чтобы найти необходимое.
Из личного опыта: на ПК мне проще и быстрее нажать Ctrl+A и в это время поднести правую руку к Backspace, заодно сразу перенося её дальше, чтобы набрать новый поисковый запрос. На телефоне не стандартная клавиатура - SwiftKey. Стираю отдельные слова и предложения свайпом по клавиатуре. Резюме: крестик в поле поиска может пригодится только в сценарии длительного поиска на мобильном устройстве (и то сомнительно. Обычно при нажатии на поле поиска автоматически выделяется весь текст, что позволяет просто начать вводить новый запрос!)
Пожалуйста, подписывайте в каких форматах интерфейса используется элемент (ПК / телефон).
uiuxaudit
22.01.2025 10:44По “Пример 1”
Только по скрину сложно судить, не хватает вводных: в каком сценарии это используется? что вокруг? и т.п.
Может шеврон не нужен и/или “галка” не нужна.
Если шеврон и галка нужны, то тут можно попробовать перенести шеврон вправо и может сделать “треугольником”.
По клику на родительский пункт (и/или его галку) автоматом разворачивать его дочерние пункты, тогда юзеру и стрелка не понадобится.
Вместо стрелок, справа сделать маленькую кнопку с текстом “счета”, не чёрным цветом, тогда будет гораздо понятнее.
Я бы предложил поправить текст placeholder поля поиска, написать: «Начните вводить счёт или компанию» (по длине столько же). Кажется, юзерам так будет понятнее.
Предложил бы сортировать номера счетов по возрастанию (или убыванию). Или сортировать чуть сложнее: по первым пяти цифрам, а внутри по последним 4-6. Так удобнее искать визуально, тем более что юзеры ищут счёт тоже по последним цифрам.
Ещё на скрине непонятно зачем красная кнопка Применить, если ничего не чекнуто, но наверно не весь сценарий вошёл в скрин.
uiuxaudit
22.01.2025 10:44По “Пример 2”
Кнопку очистки на полях поиска убирать не надо. Может её мало кто видит и мало кто пользуется (из вашей ЦА), но дико бесит, когда её нет, а она нужна ))
Кнопка бледно-серая, кажется, что disabled (у вас стиль такой), и её плохо видно (серое на сером).
Фон непустого поля ввода совпадает с фоном пустого поля. Кажется, чтобы для непустых полей правильнее менять фон на более светлый (или белый). Тогда вашу кнопку Х виднее, юзер лучше бы понимал разницу и активнее пользовался поиском и очисткой поля.
CptAFK
22.01.2025 10:44Это вообще бичь современных интерфейсов.
Кнопка лайк в Яндекс.Музыке стала светлой в нажатом состоянии, вместо привычной "красной". Постаянно ставлю лайк, понимаю что наоборот его снял, плююсь и снова его ставлю. Очень удобно Яндекс
Кнопка лайк в youtube shorts вообще скачает в цветах, видимо в зависимости от фона видео под ней или типа того, вообще мозг ломает.
uiuxaudit
22.01.2025 10:44По “Пример 3”
Горизонтальные точки в таблице ощущаются как продолжение таблицы, а не как кнопка с действиями. Т.е. Юзер привык, если что-то, куда-то не помещается, то обрезается и ставится «…». Такое же отношение к этим горизонтальным точкам.
Вертикальные же точки не воспринимаются как продолжение чего-то там, а как конец строки, как вызов списка или меню.
Не понял из вашего описания, в каком случае юзеры точнее понимали назначение кнопок с точками. Судя по скринам в первом случае у вас горизонтальные точки всегда видны в таблице (не по ховеру), но их плохо видно, т.к. они не выглядят кнопками (просто точки). А во втором случае, у вас вертикальные точки появляются только по ховеру на строку таблицы.
Вот так вот “в лоб” заводить тест на эти сценарии не рекомендуется, т.к. у вас не только стиль (горизонтальные / вертикальные), но и функциональность отличается (видны по ховеру / без ховера). Ну и таблицы про разное, сценарий использования значительно отличаются.
yppro
22.01.2025 10:44Они думали, что смогут увидеть только конкретный счёт — через поиск.
А что, поиск не работает(ал)? Тогда вам «двойка» вне зависимости от направления стрелок.
мы решили оставить по умолчанию раскрытыми все списки внутри фильтра
Это худшее решение, какое только можно придумать, потому что чем сложнее элемент, тем хуже пользовательский опыт.
пользователи не стирали поиск, чтобы вернуться к списку компаний
Подсветите нестёртое поле поиска красным. В ошибку нужно ткнуть носом.
evgen_ru
интересное исследование, спасибо.
1 и 2 паттерны не очень логичные, так как шеврон вроде бы по гайдам должен располагаться с правой стороны и тогда чекбокс не будет отвлекать от него внимание. имхо.