Окт. 10

UX Guide: как избежать юзабилити-ошибок в продукте

На последнем проекте у меня как UX-дизайнера возникла необходимость поделиться базовыми знаниями UX с командой разработки. В будущем это должно помочь им избежать наиболее грубых юзабилити-ошибок в продукте. Также я подумала, что эти базовые гайды могут быть полезны и другим. Например, начинающим специалистам и мидлам в Front-end, QA, Product management, а также всем, кто занимается разработкой своих pet projects. Дизайнерам многие вещи, описанные ниже, скорее всего, известны. Все юзабилити-гайды не поместились бы в формат статьи, поэтому здесь наиболее критичные и частые ошибки, с которыми мне приходилось встречаться на разных проектах при оценке и редизайне существующих интерфейсов.

Я буду упоминать юзабилити-паттерны и антипаттерны, то есть эффективные и сбивающие с толку дизайн-решения, а также слабые паттерны, которые в принципе выполняют свою функцию в интерфейсе, но являются либо «костылем», либо результатом неправильного подбора нужного паттерна.

Controls

Контролы — элементы интерфейса, с помощью которых пользователь взаимодействует с системой. У пользователей есть устоявшиеся представления о том, как работает тот или иной контрол. Уход от закрепившегося паттерна, например другое интерактивное поведение или необычная визуальная часть контрола, могут вызывать замешательство, снижать доверие к системе и увеличивать порог входа. Даже смена на кнопке текста «Сохранить» на «Запомнить» заставит пользователя лишний раз задуматься перед нажатием. И запомнить этот случай :)

Я хочу акцентировать внимание на основном контроле — кнопках.

Buttons

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

По визуальным стилям различают следующие виды кнопок: сплошные (solid), контурные (outlined/ghost), в виде ссылки, с иконкой, только иконка без заголовка, комбо-кнопки, toggle-кнопки (встречаются реже).

Не забывайте о состояниях кнопок, особенно состояния disabled. Пользователь должен четко понимать две вещи.

Первое. Кнопка находится в состоянии disabled, то есть это визуально считывается: увеличивается прозрачность фона кнопки и текста, при этом текст должен оставаться читаемым; меняется цвет кнопки на оттенки серого. Если стайл-гайд фреймворка диктует использования кнопки с серым фоном для дефолтного состояния, не следует для него делать надписи на кнопке белого и серого цвета. Серый фон + серый/белый текст = disabled.

Второе. Какие условия пользователю нужно выполнить, чтобы вернуть кнопку к состоянию default (например, обозначение обязательных инпут-полей звездочкой *). Нельзя оставлять пользователя без объяснения, почему любой элемент системы задизейблен.

Тайтлы / названия кнопок, если речь идет не о лендинг-страничке или имейл-рассылке, должны быть максимально лаконичными и глагольными по конструкции.

Возможные варианты на английском:

verb (Create, Save, Delete, Copy, etc);
verb + noun (Create Copy, Save Draft, etc.);
редко noun, особенно для Action buttons, и чаще используется для ссылок (Details, Settings, Profile, etc).

Написание тайтлов. В одну строку. Всегда. Возможные варианты:

все ЗАГЛАВНЫЕ буквы. Чаще для названия из одного слова, реже из двух, никогда для предложений (SIGN UP AND GET OUR SPECIAL OFFER);
только первая буква заглавная, например Create, Save Draft.

Padding — расстояния от тайтла до границ кнопки. Бывают горизонтальными (по бокам от надписи) и вертикальными (сверху и снизу от надписи):

для горизонтальных можно пользоваться правилом: минимальный отступ равен ширине заглавной буквы шрифта надписи на кнопке, умноженной на 1,5;
для вертикальных бывают разные варианты (например, компактные кнопки или с большим паддингом). Но и здесь можно пользоваться правилом: вертикальный паддинг не должен превышать горизонтального.

В самих кнопках обычно нет недочетов, разве что нет консистентности в стилях. Например, в интерфейсе встречаются кнопки с надписями, когда все буквы заглавные и когда заглавная только первая буква. Часто кнопки ошибочно замещают другие паттерны. И это требует системной переработки дизайн-решения. Из последнего, например, когда в диалоговом окне вместо списка опций (чекбоксы или радиокнопки) и группы кнопок Cancel/Apply использовалось текстовое объяснение опций и три отдельные кнопки под каждую опцию плюс кнопка Cancel.

Action buttons and action button groups

Call to action (CTA) button — это кнопки, которые по своему функциональному назначению требуют от пользователя определенных действий или подталкивают его к таким действиям для завершения пользовательского сценария. Часто используются для подтверждения действия в диалоговых окнах, при сабмите данных. Являются обязательным шагом при манипуляции с контентом если его нельзя вернуть к предыдущему состоянию (undo, revert).

По смысловой нагрузке action buttons могут быть:

primary — по смыслу желательные для системы/бизнеса;
secondary — по смыслу «опциональные» для системы, именно наличие secondary buttons дает пользователю чувство контроля при взаимодействии с системой;
tertiary (реже).

Action buttons могут состоять:

только из primary (иногда выносят в диалоговые окна, оповещения от системы, лучше использовать toasts или всплывающие notification, которые не требуют обязательного действия от пользователя);
из одной primary и одной secondary;
реже из одной primary и двух secondary.

Визуальная иерархия выстраивается по логике:

primary — сплошные кнопки;
secondary — контурные или ссылки;
tertiary — кнопки-ссылки или кнопки-иконки;
иногда tertiary или одна из secondary визуально стоят обособленно от связки primary + secondary.

NB! Есть два главных паттерна расположения кнопок primary и secondary относительно друг друга:

primary — слева для пользователей Windows OS;
primary — справа для пользователей Mac OS, иногда mobile.

И тот и другой считается верным и зависит от профиля аудитории.

Антипаттерны:

использование двух и более кнопок primary и/или трех и более secondary;
без визуального различия между primary/secondary/tertiary;
заменять primary Call to action buttons кнопкой-иконкой.

Бывает, группы кнопок объединяют и выносят на Action Panel — панель над рабочей областью для манипуляции контентом этой области. Здесь чаще всего используют кнопки:

только с иконками;
комбо;
сплошные и контурные.

Некоторые из кнопок, чаще всего сплошные или контурные, могут появляться и прятаться на Action Panel как отклик системы на действие пользователя, в зависимости от контекста выполняемой им задачи (user task). Это вторичные действия с контентом в рабочей области. Например, выбор нескольких сообщений в меcсенджере или нескольких колонок/строк в таблице может вызывать дополнительные Action Buttons.

Icon button

Отдельно хочу обратить внимание на упущения при подборе кнопок-иконок, замечания применимы также к иконкам-ярлыкам, которые сопровождают надписи.

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

Максимально избегать использования визуально уникальных иконок без сопровождающих надписей.

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

Чем меньше размер иконки, тем менее детализированной она должна быть.

Много ошибок вытекает из некорректного использование существующих символов иконок, например когда для выбора скорости воспроизведения видео используют символ бегущего человечка вместо уместного «x1» при дефолтной скорости видео. Другой пример, когда используется иконка выбора шрифта «ТТ» для вызова окна ввода текстовой заметки.

Selection controls

Toggle/switch(er)

По сути, это переключатель между состояниями ON/OFF или Enabled/Disabled, появился относительно недавно и перешел из мобильных в веб- и десктоп-интерфейсы.

toggle, или switcher, имеет два состояния, on/off, для одного и того же атрибута сущности / для одной и той же функции этой сущности;
всегда располагается справа от тайтла;
включение и выключение toggle дает пользователю мгновенный фидбек, изменение в лейауте / в поведении системы и т. д.;
всегда доступен для переключения между двумя состояниями: on/off;
не требует дополнительного подтверждения через Call to action buttons (CTA), а значит, не привносит в систему необратимых изменений при переключении on/off;
антипаттерном считается переключение между двумя противоположными по смыслу сущностями через toggle (например, Save vs. Delete, Sound on vs. Mute, All vs. Custom).

при активации (положение on) может раскрывать группу с дополнительными контролами: радиокнопками и чекбоксами.

toggle при активации (положение on) не должен раскрывать дополнительную опцию с одним toggle;
при активации (положение on) слабым паттерном считается раскрытие вложенной группы опций с множеством toggle.

Из достаточно новых ошибок встречается использование toggle для открытия вложенного контента (например, списка фильтров, просмотра медиа во фрейме), что-то вроде раскрывающегося списка ⌵ или аккордеона. Это очень близкие по смыслу интерактивные элементы, но они вызывают замешательство при уходе от привычного использования. Если говорить об аналогиях, представьте, что ваша вкладка в браузере будет закрываться не по нажатию на иконку крестика, а по нажатию на иконку корзины.

Radio Buttons

Кнопки со своей предысторией. В одних источниках упоминаются автомобильные радиоприемники, в других — настольные. Суть остается одной и той же: и у тех и у других были физические кнопки, каждая из которых включала или выключала свою радиоволну. Для удобства переключения между кнопками (и станциями соответственно) нажатие последующей кнопки выключало («отжимало обратно») предыдущую. В современных интерфейсах интерактивный принцип остался тот же: выбираешь одну опцию — снимается выбор с предыдущей.

всегда представляет группу контролов;
всегда располагается слева от тайтлов (названий) опций;
подразумевает выбор single select (одного значения) из многих;
подразумевает один дефолтный выбор еще до взаимодействия пользователя с системой;
нет варианта, чтобы оставить пользователя без выбора. То есть, когда мы хотим, чтобы пользователь обязательно выбрал один из вариантов, то используем группу радиокнопок;
при выборе не может раскрывать, отображать один или группу toggle;
при выборе одного из значений может активировать группу чекбоксов, иногда встречается вариант с активацией одного чекбокса, и чаще всего можно было бы избежать этого, отредактировав текст опции радиокнопки.

более чем 5 опций радиокнопки лучше размещать в дропдауне с сингл-селектом;
подтверждение выбора требует использования CTA;
выбор опции может активировать поля ввода (текстовое поле, селектор, календарь и т. д.).

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

Чекбоксы

Группа селекторов, которая позволяет как единичный, так и множественный выбор опций.

может представлять группу контролов или один чекбокс;
чекбокс имеет два состояния, on/off, для одного и того же атрибута сущности / для одной и той же функции этой сущности;
всегда располагается слева от названий опций.

может быть или не быть дефолтное значение (on/off);
подтверждение выбора требует использования CTA, идут перед CTA в лейауте (на практике не всегда);
выбор опции on может активировать логически «вложенные» инпут-филды (текст-филд, селектор, календарь и т. д). Вложенные сущности должны быть доступны для превью без выбора конкретного чекбокса.

К чекбоксам в интерфейсах обычно нет критических замечаний, из последнего необычного могу назвать: расположение чекбокса справа от названия опции; перечень около 30 чекбокс-опций текстом в строку (а не сгруппированными multiselect-фильтрами); обязательный чекбокс «I have read terms and conditions» под CTA-кнопкой.

Dialogue windows / Modals / System Feedback

Одна из форм обратной связи и диалога с пользователем — это модальные или диалоговые окна. Также для обратной связи могут использоваться notification messages, или toasts. Модальные и диалоговые окна всегда требуют от пользователя подтверждения действий, то есть использования CTA в интерфейсе.

У эффективного диалога, а взаимодействие пользователя и системы по стандарту ISO 9241 рассматривается как диалог, есть свои ключевые параметры (в стандарте ISO дается более расширенно):

контекст (о чем общаемся);
понятность (мы говорим на одном языке с собеседником);
разборчивость речи (все сказанное передается, распознается и интерпретируется с минимальным искажением);
это свободное волеизъявление, то есть у участника есть возможность отказаться от диалога. К счастью, интерактивная система не может себе позволить игнорирование пользователя.

Сравним, как эти принципы переносятся при проектировании диалогового окна.

Контекст. Диалоговые окна не должны прерывать основной сценарий пользователя; зачастую выступают как уточнение/подтверждение последнего/первого шага пользовательского сценария.
Понятность. Текст сообщений придерживается контекста предшествующих действий и оперирует общепринятыми терминами (как в системе, бизнес-домене; другие устоявшиеся паттерны для текста в интерфейсах). Текст остается лаконичным и понятным.
Разборчивость. Форматирование текста диалога удобочитаемо.
Свобода. Диалоговое окно можно закрыть.

Также могут встречаться контекстные окна (Context/In-context windows), которые не прерывают, а дополняют или инициируют выполнение пользовательского сценария.

Например:

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

Fixed or draggable?

Fixed. И диалоговые, и контекстные окна могут блокировать контент на бэкграунде, в таких случаях используется полупрозрачная подложка под таким окном. Такой паттерн следует использовать:

если нужно максимальное внимание от пользователя в работе с контекстным окном или диалогом. Например, для удаления важных данных или ввода sensitive data, открытия доступа;
если контекстное окно требует значительных ресурсов (когнитивных или временных) для работы с ним, тогда полупрозрачная подложка снимает когнитивную нагрузку;
если этот диалог, контекстное окно являются обязательным шагом пользовательского сценария, часто инициирующим или заключительным.

Draggable. Когда пользователю нужно использовать информацию на бэкграунде как референс, лучше сделать окно, которое можно перетаскивать.

Часто понять, что нужно использовать: Fixed или Draggable, — можно изучив пользовательский сценарий или после тестирования, фидбэка от пользователей.

General notes

Flow interruption and Context

Старайтесь не разрывать выполнение пользовательского сценария (user flow / scenario), заставляя его избыточно навигировать или отвлекаться на сопутствующие второстепенные задачи.
Не забывайте о Back-навигации, если возникает необходимость разорвать сценарий.
Старайтесь избегать тупиковых ситуаций в user flow, подсказывая пользователю возможные последующие шаги.
Не забывайте о подсказках для Empty states или во время Onboarding.

Empty States — «заглушка» для функционала в интерфейсе, когда еще не введены релевантные данные. Например, вместо пустой таблицы отображать сообщение для пользователя о том, как сделать так, чтобы наполнить эту таблицу данными. Или в разделе Uploads, когда еще не подгружены файлы, отображать сообщение о том, как добавить контент. Можно обобщить и сказать, что те сущности, которые могут быть созданы и будут отображаться в виде группы в дальнейшем, должны иметь скрин с состоянием Empty state. Подсказки во время Onboarding упрощают вход новичка в систему и ознакомление с базовым функционалом, основным flow. Оставляйте за пользователем возможность пропустить Onboarding, а также информируйте о его прогрессе, например сколько шагов пройдено и сколько осталось до окончания процесса. Слишком детализированный Onboarding, который объясняет, как работать с простыми контролами, скорее служит «костылем» в непродуманном дизайн-решении.

Custom UI elements and custom interactions

Избегайте придумывания уникальных UI-элементов, их новых интерактивных состояний, особенно если существуют устоявшиеся паттерны. Дизайн в игровой индустрии позволяет придумывать уникальные контролы (например, две стороны монеты и ее переворачивание могут работать как toggle on/off). В остальных случаях не надо.

Искажения существующих паттернов зачастую заводятся как UI-баги.

Duplication and Negative space

Где это возможно, избегайте дублирования и избыточности информации и функций.

Не брезгуйте негативным пространством в лейаутах, то есть пустыми местами между блоками UI-элементов, разреженностью текста, которые по практичным соображениям хочется наполнить функционалом (кнопками, формами). Разумное использование негативного пространства улучшает понимание пользователем системы и его впечатление от работы с ней.

Выводы

Если в команде нет UX-дизайнера — валидируйте свои решения со специалистами Quality Assurance. Это первый пользователь системы и, по моему личному мнению, первый борец за качество, целесообразность и логичность тех или иных решений во время разработки продукта.

Казалось бы, ничего особенно критичного в таких интерфейсных недочетах нет, если рассматривать частные случаи по отдельности. Однако если подобные ошибки есть, обычно их много. Более того, когда пользователь мотивирован и нет альтернативного (конкурентного вашему) решения, он/она все равно пройдет этот путь, обучится, придумает свои «костыли» и будет использовать продукт. Если захочет. Но на это все уйдет намного больше когнитивных ресурсов и времени. В том числе вашего времени и времени команды, отведенного на саппорт пользователей.