UI/UX-дизайн

Дизайн інтерфейсу сайту, додатку або панелі: спочатку сценарії та клікабельний прототип, і лише потім графіка.

• індивідуальноОбсяг
• Сайти та брендингОбласть
• 6 годин – 2 дніЗапуск

Кому це потрібно

Цифрові продукти, SaaS та внутрішні бізнес-системи.

Проблема

Користувачі губляться і не доводять дії до кінця. У цифрових продуктах, системах SaaS та внутрішніх панелях рідко справа в некрасивому вигляді — справа в тому, що екран зробили як список полів для запису в базу, а не як шлях, який хтось має пройти. Команда знає обхідні шляхи і проблеми не бачить; новій людині потрібне навчання, щоб зробити те, що повторюється десять разів на день. Порожні стани, помилки та екрани "тут поки нічого немає" зазвичай взагалі ніхто не проектує, і вони з'являються в коді, нашвидку.

Що робимо

Проектуємо інтерфейс від сценаріїв, а не від екранів: спочатку вирішуємо, хто чого має досягти і за скільки кроків, і лише потім малюємо.

• Сценарії завдань: мета користувача, кроки та місця, де їх можна скоротити
• Wireframe до графіки, щоб суперечка про структуру не стала суперечкою про колір
• Клікабельний прототип, щоб пройти сценарії до того, як щось потрапить у код

Що входить

П'ять етапів у постійному порядку; кожен наступний закриває рішення попереднього, тому нічого не повертається на дошку двічі.

• Flow: шляхи користувача і всі стани, включаючи порожній та помилковий
• Wireframe: компоновка екранів та ієрархія контенту без графіки
• UI: сітка, типографіка, кольори, компоненти та єдині стани елементів
• Прототип: клікабельна версія, на якій можна пройти реальний сценарій
• Тести: проходження сценаріїв з людьми поза командою та правки за результатами

Терміни

Реалізація займає 6 годин – 2 дні. Вузьке місце не малювання, а рішення на вашій стороні: скільки ролей у системі, що бачить кожна з них і які функції входять у першу версію. Тому з цих питань і починаємо. Тести прототипу плануємо заздалегідь: зібрати кілька людей поза командою буває довше, ніж сам дизайн — а без них залишиться думка, а не результат.

Вартість

Вирішують число екранів, обсяг досліджень і те, чи потрібен клікабельний прототип, чи достатньо статичного макета. Перепроєктування наявної панелі ми оцінюємо після того, як подивимося на те, що вже працює — часто достатньо виправити кілька екранів замість того, щоб малювати всі наново, і ми говоримо про це до старту.

Що ви отримуєте

Простіше користуватися і вища конверсія: менше покинутих форм і менше питань у підтримку про те, що має бути видно на екрані. Розробник отримує набір екранів зі всіма станами замість опису в листі і не домальовує відсутні рішення — а це найдешевший момент, щоб їх прийняти. Введення нової людини більше не вимагає поруч того, хто знає обхідні шляхи.

Коли редизайн UX не окупається

Чотири ситуації, в яких ми радимо почекати:

• На сайт заходить дуже мало людей, і зміни все одно неможливо осмислено протестувати — спочатку потрібен трафік.
• Продукт очікує на повну зміну бізнес-моделі — проєктувати потоки під функції, які ось-ось зникнуть, означає викинути роботу даремно.
• З вашого боку немає нікого, хто впровадить готовий проєкт у код — прототип без впровадження залишається файлом.
• Команда не готова прийняти, що частина попередніх рішень виявиться помилковою — без цього тести з користувачами б'ють у порожнечу.

Жодна з цих ситуацій не є вироком назавжди — іноді достатньо почекати на слушний момент, а не відмовлятися від проєкту зовсім.

Формула: у скільки обходиться складна форма

Формула: Втрачені заявки = Кількість входів на форму × Відсоток відмов × Середня цінність заявки. Кількість входів і відсоток відмов видно в Google Analytics (події початку й відправлення форми); середня цінність заявки — це ваша власна цифра з CRM або відділу продажів, не наша.

Та сама формула працює в зворотний бік: якщо знизити відсоток відмов хоча б на кілька відсоткових пунктів, результат одразу показує, скільки заявок це дає на місяць — без жодних припущень про якість дизайну.

Що нам потрібно з вашого боку

Чотири речі, без яких робота не почнеться або застрягне на етапі узгодження:

• Доступ до аналітики (Google Analytics чи інший інструмент) з історією щонайменше за кілька тижнів.
• Доступ до панелі, CMS чи репозиторію, якщо ми проєктуємо наявний продукт, а не сайт з нуля.
• Одна людина з вашого боку, яка приймає рішення щодо потоків, — розмита відповідальність розтягує кожен етап.
• Список технічних обмежень (фреймворк, бібліотека компонентів, якщо вже є) — проєкт має реалізовуватися в тому, що у вас є.

Чим раніше готові ці чотири пункти, тим менше часу йде на з'ясування рішень уже під час проєкту замість того, щоб зробити це до його старту.

Як перевірити ефект через місяць без нас

Формула: Коефіцієнт завершення завдання = Кількість користувачів, які досягли мети / Кількість користувачів, які почали сценарій × 100%. Мету і початок сценарію ви визначаєте самі (наприклад, додавання товару в кошик і оплата замовлення) і відстежуєте в аналітичному інструменті, який у вас уже є, — без додаткового софту.

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

Чого UX/UI не робить

Межі, про які ми говоримо прямо:

• Не пише тексти чи продавальні офери — ми проєктуємо структуру, в яку вставляється готовий текст.
• Не гарантує конкретне зростання конверсії чи термін, у який воно стане помітним.
• Не замінює впровадження — клікабельний прототип ще потрібно закодувати.
• Не включає тестування після кожної наступної зміни продукту вже після завершення проєкту — це окреме замовлення.

Ці межі ми визначаємо до старту, щоб жодна зі сторін не припускала того, чого інша не обіцяла.

Типова помилка при замовленні редизайну

Найпоширеніша помилка — замовити оновлення графічного шару замість виправлення потоків. Екран виглядає сучасніше, змінюються кольори й типографіка, а шлях користувача і місця відмов залишаються точно тими самими — проблема просто отримує гарніше пакування. Наслідок коштує дорого: компанія платить один раз за оновлення вигляду, а потім другий раз за проєктування потоків, яке треба було зробити спочатку.

Ціна цієї помилки зростає разом з розміром продукту — чим більше екранів охопив рескін, тим більше з них доведеться перепроєктувати вдруге.

Повний редизайн проти точкових правок — порівняння

Чотири шляхи, у кожного свій обсяг і свій результат:

• Повний редизайн від потоків — усуває причину проблеми, але вимагає найбільше часу і рішень з вашого боку.
• Евристичний аудит і точкові правки — швидше і дешевше, але не зачіпає помилки, вбудовані в структуру продукту.
• Тести з користувачами без змін у проєкті — дешеве джерело знань про проблему, але сам по собі нічого не виправляє.
• Зміна лише графічного шару (рескін) — покращує вигляд, залишає ті самі шляхи і ті самі відмови.

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

Доступність і крайні стани: чого зазвичай бракує

Формула контрасту з WCAG 2.1 (критерій 1.4.3): Контраст = (L1 + 0,05) / (L2 + 0,05), де L1 і L2 — відносна яскравість світлішого і темнішого кольору; для звичайного тексту результат має бути не менше ніж 4,5:1. Це рахується безкоштовними інструментами, вбудованими в будь-який браузер, а не питання смаку.

• Порожній стан — що бачить користувач, перш ніж щось додасть.
• Стан помилки — що відбувається, коли збереження не вдається.
• Стан завантаження — що видно, перш ніж з'являться дані.
• Стан без прав доступу — що бачить людина, яка не має доступу до певної функції.

Що ви отримуєте

• Карта flow та wireframes ключових екранів
• UI-дизайн та система багаторазових компонентів
• Клікабельний прототип і матеріали для передачі розробникам

Коли завдання лежить в іншому місці

Якщо завдання звучить інакше, поруч стоять сусідні області тієї самої системи — AURA пов’язує їх між собою, а не продає окремо:

• 3D-анімації — 3D-об'єкти, анімації при скролі та інтерактивні сцени на сайті — для брендів, які не хочуть виглядати як усі.
• UX і конверсія — Шукаємо причини, через які відвідувачі не залишають заявку, і усуваємо їх по черзі — замість того, щоб переробляти весь сайт навмання.
• Сайти та магазини — Від лендінгу під одну пропозицію до магазину з каталогом та оплатою. Сайт будується навколо одного рішення, а не навколо фотогалереї.
• Лендінг — Одна сторінка під одну кампанію: та сама обіцянка, що в рекламі, одна ціль і нічого, що від неї відволікає.