Під час нещодавньої зустрічі з клієнтом по WebEx я запанікувала, подумавши, що не можу увімкнути мікрофон. Я мала провести 6-годинну презентацію — як я могла це зробити, якщо навіть не можу вимкнути звук? Я продовжувала натискати на іконку з перекресленим мікрофоном, але мікрофон залишався перекресленим, що б я не робила.
У паніці я зовсім не звернула уваги на зміну кольору іконки! Зрештою, я виявила, що, хоча мікрофон був перекреслений в обох станах, червоний колір іконки мав сигналізувати про те, що кнопка активна, а я в режимі «без звуку».
Я багато разів бачила, як користувачі ставали жертвами цієї проблеми. Кнопка вимкнення звуку використовується для перемикання між двома станами системи (вимкнений та увімкнений), але проблема полягає в тому, що користувачі не можуть легко визначити, який стан є поточним, а який буде після натискання. (Крім того, всупереч найкращим практикам дизайну піктограм, у реалізації WebEx кнопка «Вимкнути звук» не має текстового підпису).
Дві частини інформації, Два елементи управління
У ситуації, коли користувачі можуть переходити між двома можливими станами (для простоти назвемо їх увімкненим і вимкненим), є два біти інформації, які мають відношення до користувача і, хоча пов’язані між собою, не є ідентичними:
- Поточний стан системи (увімкнено або вимкнено).
- Що станеться, якщо користувач натисне кнопку — це наступний стан, який може бути вимкненим або увімкненим, залежно від поточного стану.
Очевидним способом їх реалізації є використання двох різних елементів інтерфейсу: індикатора стану та кнопки зміни стану. Наприклад, у застосунку Tesla на екрані «Керування» застосовано такий підхід: у вас є індикатор стану, який показує, що автомобіль заблоковано, і кнопка «Розблокувати». Натискання на індикатор стану нічого не робить, але натискання на кнопку розблоковує автомобіль.
Дві частини інформації, Один елемент управління
Однак, буває таке, що ми маємо систему з двома станами, поточний стан і те, що станеться далі, є взаємодоповнюючими. Іншими словами, можна припустити, що ці дві частини інформації (стан і те, що станеться далі) можна передати за допомогою одного елемента управління — кнопки перемикання станів. Це тому, що якщо користувачі знають одне, то (принаймні теоретично) вони можуть зробити висновок про інше (якщо ви знаєте, що ваш наступний стан буде вимкнений, то ви можете зробити висновок, що поточний стан увімкнений; або, якщо ви знаєте, що ваш поточний стан увімкнений, ви можете зробити висновок, що ваш наступний стан вимкнений).
Однак пам’ятайте, що будь-який тип висновків вимагає часу і когнітивних зусиль, і часто люди перебувають під тиском часу, щоб швидко відповісти. Якщо я намагаюся вимкнути звук, всі або чекають на мене, або ігнорують і продовжують розмову, тож у мене немає часу на паузу, щоб подумати про інтерфейс або зробити висновки.
Іноді, однак, стан можна легко визначити на основі інших сигналів. Наприклад, у відеоплеєрі є лише один елемент керування (кнопка «Play»), і він вказує на майбутній стан. Проте є достатньо сигналів, щоб зрозуміти, що відео відтворюється — користувач може почути звук або побачити зміни в зображенні на екрані.
Якщо ви вирішили використати один елемент керування для позначення як стану, так і того, що станеться далі, як слід його позначити?
Є дві альтернативи, які можна розглянути в цій ситуації:
1. Кнопка повідомляє про стан, в який перейде система
Тобто, він повідомляє користувачеві, що станеться далі після кліку на кнопку.
Це стандартна рекомендація щодо дизайну кнопок. Зокрема, кнопка реєстрації на сайті буде називатися «Зареєструватися», а кнопка відправки замовлення в магазині — «Купити» або »Оформити замовлення».
Якщо кнопка використовується для перемикання між двома станами, щоб відповідати цій рекомендації, вона також повинна змінити мітку, як у прикладі Tesla вище або у прикладі OBS нижче.
Якщо немає текстового підпису (ймовірно, тому що іконка достатньо зрозуміла), то іконка повинна змінюватися залежно від того, до якого стану вона переводить систему. Класичним прикладом є взаємодія між іконками «Відтворення» і «Пауза», яку ми бачимо на прикладі YouTube вище і яка присутня у більшості відеоплеєрів.
2. Кнопка повідомляє про активний стан за допомогою «тіні»
Це те, що раніше відбувалося в реальному житті з кнопками типу «увімкнути/вимкнути»: коли ви натискали на них, вони не змінювали позначення, а «опускалася вниз». В UI-дизайні, щоб передати цю метафору, дизайнери зазвичай додають тінь, яка вказує на те, що кнопка була натиснута і тепер вона активна.
У Word піктограма «B» для напівжирного шрифту (ліворуч) набуває тіні, коли її вибрано (праворуч), щоб вказати, що ви перебуваєте в режимі напівжирного шрифту (не звичайного). У цій реалізації кнопка не змінює підпис, коли користувач натискає її.
Розуміння цього дизайну залежить від того, щоб тінь була впізнаваною як ознака активного стану. Цей дизайн НЕ повинен покладатися на те, що користувач запам’ятає колір кнопки у двох станах і знатиме, який колір означає активний — для того, щоб він працював, має бути абсолютно очевидно, що активний стан — це натиснута кнопка, а цього іноді важко досягти у світі плаского дизайну.
* * *
Повернімося до прикладу WebEx. Озираючись назад, ми бачимо, що WebEx використав один елемент управління для позначення поточного стану і того, що буде далі, і реалізував друге дизайнерське рішення — сигналізацію активного стану. На жаль, червоний колір для позначення активного стану був невдалим рішенням з кількох причин:
- Червоний колір використовується в інтерфейсі довільно — наприклад, кнопка X (Залишити) також червона, і це не може означати, що вона активна. (Якби червоний колір означав активний стан, що б означав червоний Х? Що я вже покинула зустріч?)
- Інший колір (синій) використовується для позначення активного стану інших кнопок, таких як «Відео» і «Чат» (наприклад, синя іконка відео означає, що відео ввімкнено).
За відсутності чіткого індикатора активного стану користувачеві доводиться покладатися на підпис кнопки, щоб зрозуміти, що відбувається, а якщо підпис піктограми залишиться незмінним, це просто призведе до плутанини.
До речі, застосунок «Phone» на iPhone використовує таку саму реалізацію — з тією лише різницею, що він більш послідовний, ніж WebEx, і використовує білу заливку для позначення активного стану. Навіть з цими налаштуваннями важко визначити активний стан кнопки.
Рекомендації
Отже, які загальні рекомендації щодо кнопок перемикання станів, які є подвійними індикаторами станів? Найбезпечніше рішення — використовувати 2 елементи інтерфейсу, один для поточного стану, а інший для перемикання стану, як у прикладі з Tesla.
Якщо хочете, ви можете об’єднати ці два елементи в один, як це зроблено в Zoom. Елемент керування вимкненням звуку має два окремі компоненти:
- Текстовий напис, який вказує, що станеться, якщо користувач натисне на цей елемент керування
- Іконка, що вказує на поточний стан системи
Натискання на будь-який з них змінить стан.
Нова версія WebEx використала на той самий принцип.
Пам’ятайте, що ваша мета з елементом керування ввімкненням/вимкненням — переконатися, що користувачі швидко зрозуміють обидва варіанти:
- Поточний стан, і
- Що станеться, якщо натиснути на цю кнопку
Оцініть два стани, через які пройде система.
- Чи очевидно, що це за два протилежні стани?
- Якщо ні, то це говорить на користь дизайну з 2 елементами керування: один для поточного стану, а інший для дії, щоб перейти в інший стан.
- Якщо так, ви можете розглянути єдиний елемент дизайну, який просто говорить, що кнопка буде робити.
- Чи є зовнішні підказки (наприклад, шуми, візуальні зміни в середовищі), які можуть допомогти користувачам визначити поточний стан?
- Якщо ні, то використовуйте дизайн з 2 елементами керування, з індикатором стану (щоб чітко показати поточний стан) і кнопкою для перемикання стану.
- Якщо так, то можна розглянути один елемент дизайну — кнопку перемикання станів.
- Чи потрібно користувачам швидко визначати стан і змінювати його (як у випадку з кнопкою “Вимкнути звук”)?
- Якщо так, то достатньо мати іконку для позначення стану і кнопку для його зміни.
- Якщо ні, то можна подумати про кнопку-перемикач станів.
Першоджерело — State-Switch Controls: The Infamous Case of the “Mute” Button
