Рано чи пізно кожна продуктова команда опиняється в тій самій точці. Звернення в підтримку накопичуються довкола тих самих трьох екранів. Показники активації просідають. Хтось на зустрічі каже: «Продукт просто якийсь незграбний», і всі кивають, бо всі це теж відчувають. Але ніхто не може вказати на конкретну проблему.
Саме тоді вам потрібен UX-аудит. Йдеться про структурований огляд того, що насправді зламано, наскільки серйозно і в якому порядку це виправляти.
Ось чекліст, яким користуємося ми, у послідовності, яка має сенс.
Перш ніж почати: визначте ключову дію
Аудит без фокуса перетворюється на список із двохсот дрібних зауважень, за які ніхто не береться. Почніть із того, щоб назвати одну дію, заради якої існує ваш продукт. Створити проєкт. Надіслати рахунок. Завершити переказ. Усе в аудиті зважується через одне питання: це допомагає ключовій дії чи блокує її?
Також вирішіть, для кого ви проводите аудит. Досвідчений користувач і людина, що зайшла вперше, натрапляють на зовсім різні проблеми. Якщо треба обрати когось одного, обирайте нового користувача. Він бачить усе, що ваша команда давно перестала помічати.
Кожна пауза означає питання, на яке інтерфейс не зміг відповісти.
1. Перша сесія
Пройдіть продуктом як людина, що ніколи його не бачила. А ще краще: поспостерігайте за реальною людиною, яка ніколи його не бачила. Дайте їй ключову дію і мовчіть.
Перевірте:
- Чи розуміє людина, що робить продукт, за кілька секунд після того, як потрапила на нього?
- Чи очевидний шлях до ключової дії, чи вона блукає?
- Скільки рішень їй треба ухвалити, перш ніж вона отримає хоч якусь цінність?
- Де вона вагається? Кожна пауза означає питання, на яке інтерфейс не зміг відповісти.
- Чи підказують порожні стани, що робити, чи зустрічають порожнім екраном?
Саме на першій сесії більшість продуктів втрачає більшість користувачів. Онбординг, що розраховує на знання, яких немає, форми, що просять забагато й зарано, екрани, що показують усе замість одного наступного кроку. Ми розібрали саме ці провали в криптопродуктах у статті UX-патерни, які вбивають масове поширення крипти, і ті самі патерни постійно трапляються у звичайних SaaS.
2. Навігація та інформаційна архітектура
Перевірте:
- Чи можуть користувачі передбачити, що ховається за кожним пунктом навігації, ще до кліку?
- Чи є один очевидний шлях кудись дістатися, чи три непослідовні?
- Чи більше семи пунктів верхнього рівня в бічній панелі або меню? Якщо так, групування давно назріло.
- Чи завжди користувачі розуміють, де вони і як повернутися назад?
- Чи говорять підписи мовою користувача, чи вашим внутрішнім жаргоном?
Швидкий тест на чесність: прочитайте підписи навігації вголос комусь не з компанії. Якщо хоч один підпис потребує пояснення, він не пройшов тест.
3. Ієрархія на кожному ключовому екрані
Відкрийте п'ять найвідвідуваніших екранів і примружтеся. Що вирізняється? Саме це дизайн називає важливим. Чи збігається це з тим, що важливо насправді?
Перевірте:
- Одна чітка основна дія на екран, а не чотири кнопки однакової ваги
- Дані впорядковані за тим, що потрібно користувачам, а не за тим, що повертає база даних
- Розміри шрифту, що створюють справжні рівні, а не п'ятнадцять трохи відмінних
- Вільний простір, що групує пов'язані речі, а не розмазаний рівномірно, як маргарин
Дашборди провалюють цю перевірку частіше, ніж будь-який інший тип екранів. Якщо ваш показує двадцять метрик з однаковою візуальною вагою, користувачі не знайдуть ту одну цифру, заради якої прийшли. Ми написали детальний розбір у статті Дизайн дашборду SaaS: принципи, які справді масштабуються.
4. Форми та поля введення
Саме у формах помирають наміри. Кожна форма в продукті заслуговує на ретельну перевірку.
Перевірте:
- Чи кожне поле заслуговує на своє місце? Кожне з них коштує вам частини завершених заповнень.
- Чи видно підписи під час введення, чи плейсхолдери зникають і лишають користувачів здогадуватися?
- Чи кажуть повідомлення про помилки, що не так і як це виправити, чи просто стають червоними?
- Чи відбувається валідація одразу в полі, чи лише після надсилання всієї форми?
- Чи підписана основна кнопка дією («Створити рахунок»), чи нічим («Надіслати»)?
5. Зворотний зв'язок і стан системи
Користувачам треба знати, що система їх почула. Тиша сприймається як збій.
Перевірте:
- Чи кожна дія дає видиму реакцію протягом секунди?
- Чи продумані стани завантаження, чи екран просто зависає?
- Чи просять деструктивні дії підтвердження, і чи лише деструктивні?
- Коли щось ламається, чи дізнається користувач, що сталося і що робити далі?
- Чи можуть користувачі скасувати дію, чи кожна помилка означає почати все спочатку?
Тут варто подивитися й на надмірні попередження. Коли кожен третій клік викликає діалог підтвердження, користувачі перестають читати їх усі, зокрема той, що справді важливий.
6. Послідовність
Непослідовність непомітна на будь-якому окремому екрані, але роз'їдає продукт загалом. А ще це найчастіша знахідка в продуктах, які команди будували кілька років.
Перевірте:
- Чи кнопки, що роблять однакові речі, всюди мають однаковий стиль?
- Чи одне поняття має одну назву в усьому інтерфейсі, чи три?
- Чи схожі екрани мають спільний макет, чи кожен проєктували з нуля?
- Чи мають іконки послідовне значення?
- Чи підпорядковуються формати дат, чисел і великі літери одному правилу?
Кожна непослідовність змушує користувачів заново вчити те, що вони вже вивчили. Когнітивна ціна реальна, і вона накопичується. Ментальні моделі, що за цим стоять, ми розібрали у статті Психологія UX.
7. Основи доступності
Мінімальна планка, яку має взяти кожен продукт, ще без повної перевірки за WCAG:
- Контраст тексту відповідає рівню AA (4.5:1 для основного тексту)
- Інтерактивні елементи доступні з клавіатури
- Стани фокуса видимі
- Колір ніколи не є єдиним носієм значення
- Зони натискання достатньо великі для справжніх пальців
Проблеми з доступністю зазвичай корелюють із загальною неохайністю. Виправивши їх, ви зазвичай покращуєте досвід для всіх.
8. Швидкодія як частина UX
Швидкість є властивістю дизайну. Гарний екран, що вантажиться чотири секунди, є зламаним екраном.
Перевірте:
- Час до інтерактивності на найуживаніших екранах
- Чи важкі екрани завантажуються поступово, чи все разом
- Що відбувається на повільному з'єднанні, а не лише на офісному wifi
- Чи мобільна версія справді зручна, чи лише формально адаптивна
Як перетворити знахідки на план
Аудит дає довгий список. Не виправляйте його згори донизу. Оцініть кожну знахідку за двома осями: наскільки вона шкодить (блокує ключову дію чи косметична) і наскільки складно її виправити.
Так ви отримаєте чотири кошики. Першими йдуть болючі проблеми, які легко виправити: зазвичай це зміни в текстах, ієрархії кнопок, повідомленнях про помилки. Болючі проблеми, що потребують багато зусиль, треба належно запланувати. Неболючі пункти йдуть у беклог, і чесно буде визнати, що більшість із них ніколи не варті того, щоб ними займатися.
І ще одне варто назвати прямо: якщо аудит знаходить переважно проблеми з ієрархією та послідовністю, це сигнал, що продукту бракує дизайн-системи. Виправлення екранів по одному без неї означає, що проблеми виростуть знову. Це окрема розмова, і ми описали її у статті Дизайн-система для стартапів.
Часті запитання
Скільки триває UX-аудит?
Для типового SaaS-продукту від одного до двох тижнів: кілька днів структурованого огляду і кілька днів на опис знахідок із рівнем критичності та рекомендаціями. Коротший аудит буде поверховим переглядом, а значно довший зазвичай означає воду.
Проводити аудит своїми силами чи залучати когось ззовні?
Працюють обидва варіанти, але вони знаходять різне. Внутрішня команда знає контекст; зовнішні експерти бачать те, до чого команда вже звикла й перестала помічати. Найсильніший варіант: зовнішній погляд плюс внутрішня пріоритизація.
Як часто його проводити?
Після кожного великого релізу, перед кожним запланованим редизайном або щоразу, коли метрики та звернення в підтримку вказують на ті самі екрани. Для планової перевірки більшості продуктів достатньо раз на рік.
Чим UX-аудит відрізняється від користувацького тестування?
Аудит є експертним оглядом за відомими принципами: швидкий, широкий, без учасників. Під час користувацького тестування спостерігають за реальними людьми: повільніше, глибше і краще виявляє проблеми, яких не передбачить жоден чекліст. Вони доповнюють одне одного; аудит зазвичай іде першим і підказує, що тестувати.
Висновок
UX-аудит є структурованим проходом через першу сесію, навігацію, ієрархію, форми, зворотний зв'язок, послідовність, доступність і швидкість, де все зважується відносно однієї дії, заради якої існує ваш продукт. Результат: короткий список виправлень, ранжованих за болем, а не список побажань на двісті пунктів.
Ми проводимо UX-аудити в межах роботи над продуктовим дизайном, зазвичай як перший крок перед будь-яким редизайном. Якщо ваш продукт здається зламаним і ви хочете точно знати де, почніть тут.
