Коли UX-проєктування справді потрібне
UX-дослідження і прототипи не завжди потрібні. Для невеликого сайту з кількома сторінками логіка зазвичай очевидна, і на дослідження піде більше ресурсу, ніж воно дасть.
Проєктування виправдане, коли:
- продуктом користуються щодня, і кожна незручність множиться на сотні повторень;
- у системі кілька ролей з різними задачами — клієнти, менеджери, адміністратори;
- людина має пройти багатокроковий процес: реєстрацію, оформлення заявки, налаштування;
- продукт уже працює, але аналітика показує, що люди масово зупиняються на певному кроці;
- помилка користувача дорого коштує: неправильне замовлення, втрачені дані, звернення в підтримку.
Дослідження: що ми з’ясовуємо
Мета дослідження — замінити здогадки фактами. Залежно від продукту ми:
- розмовляємо з кількома реальними користувачами про їхні задачі та роздратування;
- опитуємо співробітників підтримки та продажів — вони знають, на що клієнти скаржаться найчастіше;
- вивчаємо дані аналітики та записи сесій у Hotjar чи Clarity, щоб побачити, де люди зупиняються;
- розбираємо, як схожі задачі вирішують інші продукти, які вже знайомі вашим користувачам.
Якщо даних про поведінку на сайті поки немає, спершу варто налаштувати аналітику. Про те, як читати ці дані, — на сторінці веб-аналітики та аудиту.
Сценарії, структура і каркаси
Після дослідження ми описуємо головні сценарії: що людина хоче зробити, з чого починає, які кроки проходить і чим закінчує. Для кожного сценарію рахуємо кроки і питаємо себе, чи можна обійтися без кожного з них.
Далі будуємо каркаси екранів — прості чорно-білі схеми без кольорів і фото. На цьому етапі зміни коштують дешево: перемістити блок чи прибрати крок можна за кілька хвилин, а не після довгої роботи над детальним дизайном.
Прототип і тестування на людях
Клікабельний прототип у Figma виглядає майже як справжній продукт, але за ним немає коду. Ми даємо його кільком людям з цільової аудиторії і просимо виконати конкретні задачі: знайти товар, подати заявку, змінити налаштування.
Навіть кілька таких сесій виявляють більшість грубих проблем: незрозумілі назви кнопок, сховані функції, поля, які незрозуміло як заповнювати. Виправити їх у прототипі набагато дешевше, ніж після розробки.
Важливо, що на тестуванні ми не питаємо «чи вам подобається». Ми спостерігаємо, що людина робить, де вагається і що каже вголос. Поведінка говорить про зручність інтерфейсу більше, ніж будь-які оцінки.
Формати роботи: плюси й мінуси
Повний цикл для нового продукту. Від дослідження до готових екранів і дизайн-системи. Плюс — продукт від початку будується навколо реальних задач. Мінус — найбільший обсяг роботи перед стартом розробки.
UX-аудит наявного продукту. Аналізуємо, де користувачі втрачаються, і даємо перелік проблем з пріоритетами та рішеннями. Плюс — швидкий результат і зрозумілий план покращень. Мінус — без подальшого проєктування частину рішень доведеться доробляти власними силами. Якщо ж змін настільки багато, що простіше оновити все, мова вже про редизайн.
Проєктування окремого сценарію. Наприклад, лише оформлення замовлення чи перші кроки нового користувача в продукті. Плюс — фокус на найболючішому місці. Мінус — треба стежити, щоб нове рішення не вибивалося з решти продукту.
Дизайн-система для великих продуктів
Коли в продукті десятки екранів і кілька дизайнерів або розробників, без спільних правил інтерфейс швидко розповзається: однакові дії виглядають по-різному, з’являються п’ять відтінків однієї кнопки.
Дизайн-система — це бібліотека компонентів у Figma плюс правила, коли і як кожен з них використовувати. Вона прискорює появу нових функцій і робить продукт передбачуваним для користувача. Для невеликого сайту вистачить простого набору елементів інтерфейсу (UI-кіта), а повноцінна система окупається лише на великих продуктах.
Сайт, кабінет чи мобільний додаток
Підхід до проєктування однаковий, але деталі різні. Для сайту важливі навігація і пошук, для кабінету — таблиці, фільтри та робота з великими обсягами даних, для мобільного додатка — жести, правила платформ iOS та Android і робота однією рукою. Проєктування застосунків ми описуємо окремо, на сторінці дизайну мобільних додатків.
Що підготувати з вашого боку
- Доступ до аналітики та, якщо є, до звернень у підтримку.
- Контакти кількох користувачів, готових поговорити або пройти тест.
- Опис бізнес-цілей: що має покращитися після редизайну інтерфейсу.
- Технічні обмеження, про які варто знати: що неможливо змінити в наявній системі.
- Людину з вашого боку, яка знає продукт і може швидко відповідати на питання про бізнес-правила.
Типові помилки
- Проєктувати для себе. Власник продукту знає його надто добре і не помічає, що новачкові незрозуміло.
- Пропускати порожні й помилкові стани. Продукт виглядає добре з ідеальними даними, але розвалюється, коли список порожній чи сервер відповів помилкою.
- Тестувати на колегах. Співробітники вже знають продукт і термінологію компанії, тому не помітять того, що збиває з пантелику нового клієнта.
- Вважати UX разовою роботою. Продукт змінюється, з’являються нові функції та нові користувачі. Сценарії варто переглядати після кожного великого оновлення.
- Копіювати рішення великих продуктів. Те, що зручно в інструменті з мільйоном користувачів, може бути надмірно складним для вашої аудиторії.
Що впливає на вартість UI/UX-дизайну
- Кількість ролей і сценаріїв, які треба спроєктувати.
- Глибина дослідження: аналіз даних і кілька інтерв’ю чи повноцінне тестування з користувачами.
- Кількість екранів і станів, зокрема складних таблиць і форм.
- Потреба в дизайн-системі чи достатньо набору компонентів.
- Платформи: лише веб чи ще планшети й мобільні версії.
Часті запитання
Чи можна пропустити дослідження і одразу малювати? Можна, якщо продукт простий або ви добре знаєте користувачів. Але для складного продукту економія на дослідженні часто обертається переробками після запуску.
Скільки людей потрібно для тестування? Для пошуку основних проблем зазвичай вистачає кількох учасників з кожної ключової ролі. Важливіше, щоб це були реальні представники аудиторії.
Як зрозуміти, що новий інтерфейс кращий за старий? Перед змінами фіксуємо показники: скільки людей завершують ключовий сценарій, скільки часу це займає, скільки звернень у підтримку. Після запуску порівнюємо їх з новими.
Чи працюєте ви з продуктом, який розробляє інша команда? Так. Ми передаємо макети й компоненти у Figma і консультуємо розробників під час реалізації.
Чому Promodex
Promodex працює з 2015 року, у портфоліо агентства 750+ проєктів. Серед продуктів, над якими ми працювали, — IKURA, Crypto Monitoring, Unibox Warehouse та Pro ERP. Наші дизайнери працюють в одній команді з розробниками, тому прототипи від початку враховують реальні технічні можливості. Ми пояснюємо кожне рішення і після запуску допомагаємо покращувати продукт за даними.
