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