UX Guide: як уникнути юзабіліті-помилок в продукті

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

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

Controls

Контроли — елементи інтерфейсу, за допомогою яких користувач взаємодіє з системою. У користувачів є усталені уявлення про те, як працює той чи інший контрол. Відхід від закріпився патерну, наприклад інше інтерактивне поведінку або незвичайна візуальна частина контрола, можуть викликати замішання, знижувати довіру до системи і збільшувати поріг входу. Навіть зміна тексту на кнопці «Зберегти» на «Запам'ятати» змусить користувача зайвий раз замислитися перед натисненням. І запам'ятати цей випадок :)

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

Buttons

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

За візуальним стилем розрізняють наступні види кнопок: суцільні (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 або спливаючі повідомлення, які не вимагають обов'язкового дії від користувача);
з однієї 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). Це вторинні дії з об'єктами в робочій області. Наприклад, вибір декількох повідомлень в месенджері або декількох колонок/рядків у таблиці може викликати додаткові 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) , які не переривають, а доповнюють або ініціюють виконання користувацького сценарію.

Наприклад:

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

Or Fixed 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. Це перший користувач системи і, на мою думку, перший борець за якість, доцільність та логічність тих чи інших рішень під час розробки продукту.

Здавалося б, нічого особливо поганого в таких інтерфейсних недоліках немає, якщо розглядати окремі випадки окремо. Однак якщо подібні помилки є, зазвичай їх багато. Більше того, коли користувач мотивований і немає альтернативного (конкурентного вашому) рішення, він все одно пройде цей шлях, навчиться, придумає свої «милиці» та буде використовувати продукт. Якщо захоче. Але на це все піде набагато більше когнітивних ресурсів і часу. В тому числі вашого часу і часу команди, відведеного на саппорт користувачів.

Опубліковано: 09/10/19 @ 10:00
Розділ Різне

SEO Блог