Проектування UX-прототипів інтерфейсів ігор
Ігровий UI—це не мобільне застосування та не вебсайт. Користувач тримає геймпад або бачить інтерфейс краєм ока, доки стежить за геймплеєм. Тому правила проектування інші: пріоритет у читаємості в русі, швидкого сканування та мінімального когнітивного бар'єру при відкритті будь-якого екрана.
Більшість проблем з UX у іграх приходять не від поганої графіки, а від непрацьованої архітектури екранів ще до малювання першого пікселя.
Що йде не так без прототипування
Найболісніший сценарій: дизайнер намалював інвентар, програміст верстав у uGUI, художник додав анімації—і тільки в плейтесті виявилось, що при відкритті інвентаря гравець втрачає контекст розташування персонажа, тому що інвентар займає весь екран і немає minimap overlay. Переробка на цьому етапі коштує в 5–10 разів дорожче, ніж правка на рівні wireframe.
Або інший випадок: система діалогів з гілкуванням, яку на прототипі ніхто не проходив до кінця. При реалізації виявилось, що при глибині гілкування більше 3 рівнів гравець фізично не умістить всі варіанти відповіді на екран мобільного пристрою—текст обрізується, кнопки налізають одна на одну.
Як будується UX-прототипування для ігор
Стартова точка—користувацькі сценарії (user flows), а не екрани. Типовий набір для RPG: перший запуск → навчання → основний геймплей → пауза → інвентар → магазин → налаштування. Для кожного сценарію прорисовуємо переходи між станами: що відбувається при нажатті Escape, що при втраті з'єднання, що при недостатку ресурсів для покупки.
Потім—інформаційна архітектура HUD. Які дані потрібні завжди (health, ammo, minimap), які—за запитом (інвентар, карта), які—контекстуально (діалог, quest-tracker при наближенні до цілі). Це розбивка за шарами видимості, і вона повинна бути зафіксована до початку роботи художника.
Прототип у Figma—не фінальний дизайн. Wireframe у grayscale з реальними текстами та реальними розмірами даних. Якщо в інвентарі може бути 500 предметів—у прототипі повинна бути сітка на 500 предметів, а не 6 іконок-заглушок. Саме на цьому етапі з'ясовується, потрібна пагінація, фільтри, пошук.
Інтерактивний прототип vs статичні макети
Статичний Figma-файл не показує проблем з навігацією. Для ігрового UI критично важливі інтерактивні переходи: як відкривається меню (slide/fade/instant), що відбувається з фоновим геймплеєм (pause/blur/nothing), як працює навігація клавіатурою/геймпадом.
Figma Prototyping з умовними переходами (Variants + Interactive Components) дозволяє сымітувати більшість цієї логіки. Для складніших випадків—Unity UIToolkit з UXML-прототипом без фінального дизайну: працює прямо в рушієві, можна тестувати з геймпадом одразу.
Фокус-тестування на прототипі—не розкіш. Навіть 5 людей, які вперше бачать інтерфейс, знаходять проблеми, які команда перестала помічати за місяць роботи. На цьому етапі це безплатно. Після реалізації—дорого.
Специфіка платформ у прототипуванні
Мобільний інтерфейс та PC-інтерфейс—різні речі навіть для одного геймплею. Touch targets на мобільному: мінімум 44×44 dp, рекомендовано 56×56 для активних елементів. Це означає, що на смартфоні в портретній орієнтації сітка предметів інвентаря буде максимум 4 колонки з іконками 64×64 при розумних відступах. Якщо дизайн робився під PC з 8 колонками—переробка неминуча.
Для console UI з геймпадом прототип обов'язково повинен включати схему focus management: який елемент вибраний за замовчуванням при відкритті кожного екрана, куди переходить фокус при нажатті D-pad у кожному напрямку. Це прописується текстом у прототипі—не передбачається, а документується.
Документація прототипу: що передається команді
Прототип без документації—це артефакт, який втрачає цінність одразу після того, як його автор йде у відпустку. Мінімальний пакет документації до UX-прототипу гри включає три речі.
Перше—Interaction Spec: для кожного інтерактивного елемента описані всі стани (default, hover, pressed, disabled, selected для геймпада) та триґери переходу між ними. Не «кнопка активується при нажатті», а «при OnPointerDown → візуальний відклик 80 мс → при OnPointerUp + умова X → перехід на екран Y».
Друге—Edge Cases Map: що відбувається при нульових даних (пустий інвентар), при максимальних даних (99 предметів у слоту), при помилці мережі, при перериванні дії в середині. Це те, що програмісти знаходять самі при реалізації—але краще, якщо відповіді вже є в документації.
Третє—Responsive Behavior Guide: як кожен екран адаптується до різних роздільностей та орієнтацій. Скриншоти з Figma на 375px, 768px та 1920px по ширині з описом правил—не просто «адаптивний», а «при ширині менш за 480px список переходить з двох колонок в одну».
Ця документація скорочує час верстки та знижує кількість правок на етапі реалізації приблизно вдвічі.
Етапи роботи
Розпочинаємо зі збору вимог: ігрові механіки, платформи, цільова аудиторія, технічні обмеження рушія. Потім—документування user flows та інформаційної архітектури. Wireframe-прототипування з ітераціями та внутрішніми плейтестами. Після узгодження wireframes—передача в дизайн або паралельна розробка візуального стилю на основі прототипу.
| Масштаб проекту | Строки прототипування |
|---|---|
| Один екран (інвентар, карта, магазин) | 2–5 днів |
| Повний UI-комплект для інді-проекту (10–15 екранів) | 1–3 тижні |
| Складна система з гілкуванням (діалоги, квести, прокачка) | 2–5 тижнів |
| Мультиплатформенний UI з адаптацією під PC/mobile/console | 4–8 тижнів |
Вартість визначається після обговорення обсягу екранів та складності механік.