Проектирование UX-прототипов интерфейсов игр

Проектирование UX-прототипов интерфейсов игр

Игровой UI — это не мобильное приложение и не сайт. Пользователь держит геймпад или видит интерфейс краем глаза, пока следит за геймплеем. Потому правила проектирования другие: приоритет у читаемости в движении, быстрого сканирования и минимального когнитивного барьера при открытии любого экрана.

Большинство проблем с UX в играх приходят не от плохого визуала, а от непроработанной архитектуры экранов ещё до отрисовки первого пикселя.

Что идёт не так без прототипирования

Самый болезненный сценарий: дизайнер отрисовал инвентарь, программист сверстал в uGUI, художник добавил анимации — и только в плейтесте выяснилось, что при открытии инвентаря игрок теряет контекст местоположения персонажа, потому что инвентарь занимает весь экран и нет minimap overlay. Переделка на этом этапе стоит в 5–10 раз дороже, чем правка на уровне wireframe.

Или другой случай: система диалогов с ветвлением, которую на прототипе никто не проходил до конца. В реализации оказалось, что при глубине ветвления больше 3 уровней игрок физически не умещает все варианты ответа на экране мобильного устройства — текст обрезается, кнопки налезают друг на друга.

Как строится UX-прототипирование для игр

Стартовая точка — пользовательские сценарии (user flows), а не экраны. Типичный набор для RPG: первый запуск → обучение → основной геймплей → пауза → инвентарь → магазин → настройки. Для каждого сценария прорисовываем переходы между состояниями: что происходит при нажатии Escape, что при потере соединения, что при недостатке ресурсов для покупки.

Затем — информационная архитектура HUD. Какие данные нужны всегда (health, ammo, minimap), какие — по требованию (инвентарь, карта), какие — контекстуально (диалог, квест-трекер при приближении к цели). Это разбивка по слоям видимости, и она должна быть зафиксирована до начала работы художника.

Прототип в 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 — передача в дизайн или параллельная разработка визуального стиля на основе прототипа.

Стоимость определяется после обсуждения объёма экранов и сложности механик.