Всем привет! Данная статья — об игровых интерфейсах и порядку работы с ними. Она предназначена в первую очередь для тех, кто работает в игровой индустрии и в том или ином виде влияет на разработку интерфейса, но при этом сам не является UI/UX специалистом. Проект-менеджеры, продюсеры, геймдизайнеры, программисты, работающие с GUI, художники — я писал этот текст, думая о вас, ребята.
Вступительное слово. В своей практике я не раз сталкивался с тем, что разработкой и проектированием игровых интерфейсов занимаются люди, напрямую к этой области не относящиеся. Скажу больше, часто это люди, для которых обязанности, связанные с интерфейсом, являются дополнительным и нежелательным обременением. Чаще всего это связка геймдизайнер+художник, в которой геймдизайнер продумывает функционал и разметку экранов, а художник добросовестно старается “сделать красиво”. При этом зачастую ни тот, ни другой не имеют опыта работы с интерфейсами, не задумываются о юзабилити, пользовательских сценариях или единообразии элементов и в целом не понимают, как организовать процесс работы с интерфейсом, чтобы получить гарантированно хороший результат. И это происходит не по вине художников или геймдизайнеров, просто сама ниша игровых интерфейсов очень специфическая и узкая, информации по работе с ними очень мало, и людям банально негде набраться опыта, не с чего начать. Я хотел бы поделиться своим опытом и наблюдениями в этой сфере и предложить некую структуру, чек-лист, с которым можно сверяться при разработке игрового интерфейса на (вашем) проекте.
Пара слов о себе: работу в геймдеве я начал в 2011 году как flash- и web дизайнер. C 2013 работаю исключительно как дизайнер интерфейсов на игровых проектах, в основном мобильных. За это время я поработал в офисах как небольших стартапов, так и в крупных, устоявшихся компаниях; попробовал себя в качестве фрилансера-удаленщика и приходящего “эксперта”. Всего я поучаствовал в создании примерно двух десятков игр разного масштаба и качества, из которых около дюжины дожили до релиза и лежат в маркете. Если кому интересны конкретные тайтлы — пишите в личку.
И давайте договоримся сразу: то, что написано ниже — ни в коем случае не истина в последней инстанции. Мой опыт ограничен. Если вы считаете, что где-то я написал ерунду (или знаете, как сделать что-то лучше) — пожалуйста, свяжитесь со мной или опишите свое видение в комментариях.
Окей, теперь к сути. Давайте для начала окинем всю последовательность предлагаемых мною шагов разом, а затем я постараюсь объяснить, зачем нужен каждый из них и какие грабли вы рискуете собрать, пропустив или недооценив каждый из шагов.
1) Определение структуры и главных функциональных частей интерфейса.
2) Прототипирование ключевых экранов в виде схем.
3) Сброка и тестирование прототипа. Поиск стилистики и внешнего вида.
4) Отрисовка экранов, составление UI kit’а. Документация.
5) Внедрение в игровой движок, приемка и контроль качества.
6) Добавление интерфейсных анимаций.
7) Аналитика результатов.
Пойдем по порядку.
Шаг первый. Определение структуры и главных функциональных частей интерфейса.
Разработка интерфейса (в идеале) начинается после того, как сформирован дизайн-документ, описывающий базовый функционал проекта. Исходя из него, игра разбивается на логические части (к примеру, боевая сессия, глобальная карта, клановые интерфейсы и т.д.), которые, в свою очередь, дробятся на конкретные экраны. Затем команда, включающая в себя всех заинтересованных, набивается в переговорку и проходится по каждой части проекта, в дискуссионной форме стараясь ответить на вопрос “что именно там должно быть?”. В результате таких дискуссий формируются ТЗ для первых мокапов, которые затем попадают в руки UX-специалистов.
В процессе накидывания этих первичных мокапов будут материализовываться “правила”, по которым строится интерфейс на данном конкретном проекте. Как осуществляется навигация? Где будут располагаться кнопки? Сколько текста понадобится и какого примерно размера он будет? Нужны ли тултипы и иные всплывающие элементы и если да, то где и в каком формате?
На выходе вы должны получить генеральную схему экранов проекта, по возможности минимизировав при этом количество “белых пятен” на ней. Выглядит это как-то так:
На что тут следует обращать внимание:
Хочу сконцентрировать ваше внимание на одной важной, на мой взгляд, мысли: геймдизайн должен значительно опережать графический дизайн. На этапе, когда детальных описаний экранов либо нет вообще, либо когда они есть, но только для одного-двух экранов, не надо начинать работать с интерфейсом, по крайней мере не на чистовую — используйте заглушки. В противном случае вы потеряете массу времени и денег на переделки. Помните, что перерисовывать макеты в заглушечном формате в разы проще и быстрее, чем переделывать уже «финализированный» интерфейс, не говоря уже о собранном и реализованном. Причем, чем больше базовых игровых фич вы откладываете на “потом”, с тем бОльшим количеством проблем столкнетесь в будущем, пытаясь впихивать новый функционал в уже устаканившуюся систему взаимодействия.
Понятно, что в реальности продумать все заранее невозможно, и вы постоянно будете сталкиваться с ситуацией, когда надо “добавить сюда еще вот это и вон то”. Это абсолютно нормально, будьте готовы к таким ситуациям: заранее закладывайте возможность добавления в экран новых элементов, обговаривайте этот вопрос с гейм-дизайнерами или проект-менеджерами (“как думаешь, что еще может добавиться на этот экран в ближайшей перспективе?”) Надо понимать, что у каждого экрана есть свой предел прочности, по достижении которого понимаешь, что проще все удалить и сделать по-другому, чем продолжать попытки впихнуть невпихуемое.
Это, кстати, классическая и неизбежная проблема проектов-долгожителей, особенно мобильных и браузерных. Чем дольше живет игра, чем шире и разнообразнее становится ее функционал, тем безобразнее, замусореннее выглядит ее интерфейс.
Шаг второй. Сборка прототипа, поиск стилистики.
Итак, у нас на руках есть дизайн-документ, общая, более-менее цельная заглушечная схема экранов и связей между ними. Теперь мы уже более-менее понимаем, какой объем работы по части интерфейса предстоит сделать, понимаем количество экранов и примерный набор элементов на каждом из них. Это прекрасный момент для того, чтобы начать собирать на коленке уродливый прототип интерфейса из квадратиков и кружочков. Да, вы никогда не покажете его своим друзьям и маме, но он ответит на множество вопросов, в том числе интерфейсных:
Параллельно со сборкой прототипа интерфейса (что обычно занимает время), имеет смысл начинать работы по поиску его стилистики и визуализации.
Почему не раньше, спросите вы? До схем и, возможно, даже до дизайн-документа? Можно и раньше. Но в таком случае вы рискуете столкнуться с (очень возможной) ситуацией, когда картинка, нарисованная по абстрактному ТЗ, совершенно не впишется в реальные требования конкретно вашего проекта, и придется искать стилистику с начала.
Перед началом отрисовки экранов исполнителю (художнику или дизайнеру — короче, тому кто будет отрисовывать) необходимо прежде всего максимально дотошно расспросить заказчика о том, каким он видит интерфейс проекта. На что тот будет похож? Какие игры (по мнению заказчика) близки к вашему проекту визуально и атмосферно? А какие игры нравятся самому заказчику, во что он играет, какие проекты уважает? Здорово, если у вас на руках уже будут какие-то атмосферные концепты, отражающие стилистику будущей игры, или фейк-скрины, но чаще всего подобная роскошь на этом этапе недоступна.
Вообще, общение с заказчиком — это очень важная часть работы, которая может сэкономить (или потерять, в случае пропуска) всем в производственной цепочке кучу времени. К сожалению, большинство дизайнеров сложно назвать эталоном по части общения с клиентом (я тут, кстати, не исключение). Именно поэтому так важно сделать над собой психологическое усилие, а также объяснить (как себе, так и заказчику) смысл и важность происходящего. Приемка интерфейсов, как и приемка арта — дело сугубо субъективное, от этого никуда не денешься, и крутится оно вокруг личности и системы ценностей заказчика. В процессе работы вы можете давать рекомендации или советы, высказывать мнения и приводить примеры, но последнее слово всегда остается за заказчиком или его представителем, и это логично. А заказчики бывают очень разные: кто-то хорошо представляет, чего хочет, кто-то — нет. Одни могут сформулировать запрос в виде картинок (что просто прекрасно), другие готовы описать на словах (что тоже неплохо), третьим не хватает насмотренности или опыта (а иногда и желания, т.к. они считают, что выполняют тем самым чужую работу) и им требуется помощь с формулировкой мыслей. Вообще, это тема для отдельной статьи. В рамках этого материала мы на этом задерживаться не будем.
Заметка на полях: требования и пожелания от заказчика лучше фиксировать в письменном виде — таким образом ему сложнее потом “передумать” или “забыть” сказанное. И никогда не соглашайтесь на “ой, не знаю, вы там давайте рисуйте что-нибудь, а там разберемся”. Это мартышкин труд, который никому не нужен, в том числе заказчику.
Результаты работы с интерфейсом на втором этапе:
Во-первых, создан или ведется работа по сборке прототипа интерфейса, основанного на схемах и заглушечном визуале.
Во-вторых, собран набор референсов для чистового визуала, которые нравятся и одобрены заказчиком. Каждый реф может зацепить заказчика чем-то конкретным (цветовой гаммой, решение главного меню, системой навигации) или просто общим впечатлением от картинки. Храните эти рефы как зеницу ока — они станут краеугольным камнем для следующего этапа.
Примеры реф-листов:
Заметка на полях: в первую очередь лучше набирать референсы из той же рыночной ниши, что и ваш проект. Дело в том, что если вы наберете отличные рефы из ААА игр для ПК, а сами занимаетесь разработкой мобильной игры, то согласовать-то их может быть будет и проще, а вот реализовать всю эту красоту в ограниченном мобильном формате будет практически невозможно. В результате на каком-то этапе вы столкнетесь с закономерным вопросом от заказчика: “Мы же подобрали такие крутые рефы, почему в результате получилось ВОТ ЭТО?”.
Еще одна заметка на полях: уделяйте на этом этапе побольше времени и сил изучению конкурентов. Смотрите скриншоты, читайте обзоры, проходите на ютубе, в конце концов. Чем больше будет ваша насмотренность, тем проще вам будет понять, что лучше работает (или не работает) в аналогичных проектах и тем легче аргументировать свое мнение. Не спешите изобретать велосипеды и не бойтесь простоты.
Шаг третий. Обкатка прототипа, отрисовка превью экранов.
Итак, у нас есть рабочий прототип, в котором реализован заглушечный интерфейс. Он, в целом, работает, выполняет свою функцию. А еще у нас есть визуальный ориентир для отрисовки экранов в виде набора референсов. Самое время их совместить: “одеть” несколько экранов в понравившуюся “шкурку”.
В процессе отбора рефов обычно становятся понятны основные направления для отрисовки первых экранов-превью: Скажем, если у вас sci-fi сеттинг, а в одобренных заказчиком рефах лежат Deus Ex и XCOM… ну, я бы сказал, что вам придется делать превью как минимум в двух вариациях:
А если в рефах лежат какие-то близкие по стилистике экраны (тот же XCOM и, скажем, Mass effect) а времени не очень много, то вполне можно обойтись и одним:
После того, как мы довели один экран-превью до состояния, которое нравится заказчику, имеет смысл отрисовать еще парочку в той же стилистике, выбирая их по принципу “максимально отличающихся”. К примеру, если первым был экран с небольшим количеством крупных элементов, то имеет смысл в дополнение к нему взять экран с большим количество маленьких элементов (например, инвентарь) и что-нибудь табличное (вроде таблицы рейтингов или статистики боя). Таким образом, вы уже на старте отработаете максимальное количество различных элементов и будете более-менее уверены в том, что выбранная “одежда” универсальна и будет достойно выглядеть на любом экране.
На этапе отрисовки превьюшек вполне можно пренебречь какими-то элементами или делать допущения в стиле “эту рамку потом придется подправить, иначе в движок ее не вставить” или «вот эти иконки надо будет подогнать под один размер». Здесь важно за минимальное количество времени получить максимально презентабельную, “продающую” картинку, которую уже не стыдно показывать инвесторам, использовать в презентациях и т.д.
Результат этого этапа: 3-4 отрисованных экрана “чистового” качества, одобренных заказчиком и обкатанная в прототипе схема интерфейса.
Шаг четвертый. Отрисовка экранов, составление UI kit’а, документация.
Это самый объемный этап работы с интерфейсом, занимающий примерно 70% всего рабочего времени. Причем для него у меня нет каких-то хитростей и лайф-хаков, только кропотливая работа и чугунный зад. Планомерно и постепенно, экран за экраном отрисовываются и внедряются в движок. Одновременно с этим обновляется их состав и функционал (потому что с момента рисовки схем обычно многое уже поменялось), а также составляется документация.
Пара слов о документации. Как показала практика, очень полезно описывать функционал экранов. Письменно. Для кого-то это прозвучит очевидным советом от кэпа, но вы удивитесь, как часто этот этап пропускают (особенно в небольших компаниях). Не в последнюю очередь это происходит потому что, во-первых, никто не любит бюрократии (у нас же тут геймдев и рок-н-ролл или что?), а во-вторых, потому что с документацией надо уметь работать. Это подразумевает как умение грамотно сформулировать описание со стороны ГД или UI/UX дизайнеров, так и умение и привычку использовать его при сборке экрана программистами. Ну и в-третьих, документацию ведь надо держать в свежем виде и регулярно обновлять. Это тоже требует времени, сил, желания и, главное, понимания, зачем оно всё нужно.
Без письменных описаний экранов вы рискуете столкнуться со всеми проблемами, связанными с человеческим фактором, забывчивостью и коммуникационными проблемами. Ваш UX-дизайнер внезапно увольняется и улетает на Бали. Программисты собирают экраны не так, как задумывалось, а так, как они считают правильным, апеллируя к тому, что “им про это не сказали”. Геймдизайнер или проект-менеджер забывает принятые решения, поскольку они не были зафиксированы, и всякий раз выдает новую версию.
Короче, приучайте себя к работе с документацией. Договоритесь внутри команды, как именно это делать: какая должна быть структура, какие инструменты использовать, на чем акцентировать внимание. А если вы уже вовсю пользуетесь документацией на проекте и сейчас только понимающе усмехаетесь, покручивая ус — берите печеньку, вы клёвые.
Дальше немного про GUI pack (или, как его еще называют, UI kit или design case). После отрисовки нескольких базовых экранов обычно становится понятен основной набор элементов, из которых будет состоять ваш интерфейс, а также правила их компановки. При дальнейшей работе с экранами будет примерно на 60-80% состоять из реюза уже готовых элементов по уже готовым правилам. Имеет смысл вынести этот “конструктор” с элементами и описаниями в отдельный, эталонный файл. Выглядит он примерно вот так:
Автор изображения — Johnny Waterman
С готовым UI KIT’ом все в команде (особенно это актуально для верстальщиков и программистов) будут знать, где содержатся самые последние, эталонные версии всех интерфейсных элементов. В то же время, в макетах конкретных экранов дизайнерам можно будет не держать десятки дублирующих слоев вроде всех состояний кнопок и переключателей.
Шаг пятый. Внедрение в игровой движок, контроль качества.
Этот этап выделен условно, т.к. сборка интерфейсов в движке обычно идет параллельно их разработке. Взяли экран со схемы, отрисовали, нарезали, отдали программистам, взялись за следующий. При этом вы “ведете” экран, находящийся в производстве, до победного конца. Только когда он собран в версии для целевых устройств (кстати, вы же не забыли про планшеты?), выглядит и работает на них так, как планировалось изначально, вы можете облегченно выдохнуть и мысленно поставить галочку в графе “сделано”. До следующей итерации.
Помните, что результат работы UX/UI специалистов — не статичная фотошопная картинка и не абстрактная схема, а красивый и, главное, функциональный интерфейс, с которым будет работать пользователь. То, насколько хорош финальный продукт, показывает, настолько хороши конкретно вы как специалист. Поэтому будьте строги и внимательны ко всем звеньям в производственной цепи, и в первую очередь к себе. Не закрывайте глаза на всякую лажу под предлогом того, что это “не моя ответственность”.
Шаг шестой. Полировка и добавление анимаций.
Это бонусный этап. Будем откровенны: при приближении даты релиза (обычно уже несколько раз перенесенной) у всех в команде начинают пылать различные части тела. Времени на полировку (а особенно полировку интерфейса, которому исторически отводят второстепенное значение) никогда не хватает. Поэтому важно изначально задумываться о том, что и когда вы будете доделывать, а также об интерфейсных анимациях. Есть возможность — добавляйте их сразу, еще при первой сборке экрана. Нет такой возможности — выделите на это отдельное, конкретное время в планах разработки. Жестко стойте на своем и не соглашайтесь отодвигать доделки и анимации на неопределенное “потом”, регулярно напоминайте про них.
Хороший игровой интерфейс “живет” и динамично реагирует на действия игроков. Интерфейсная анимация — как щепотка специй, способная преобразить вкус и ощущения от всего “блюда”. Она делает интерфейс более плавным, связанным, последовательным. Она сглаживает резкие переходы, привлекает внимание к нужным местам, развлекает — короче, улучшает игровой опыт пользователей в целом. При этом, как и в кулинарии, важно не переборщить и не поддаться искушению заанимировать всё подряд. Знайте меру.
Шаг седьмой. Аналитика интерфейсов.
Еще один условно-бонусный этап. В идеальном мире разработчики проверяют основные гипотезы (в т.ч. интерфейсные), привлекая для тестов реальных пользователей из своей ЦА, и принимают решения, исходя из полученных данных. При правильном подходе такой метод позволяет (в теории) отразить более-менее объективное положение дел и дать ответ на вопрос, что в интерфейсе действительно работает, а что нет.
В реальности такое встречается редко: не все могут позволить себе дорогостоящие плей-тесты, мало кто умеет с ними работать и понимает, зачем они нужны. Даже после софт-ланча часто анализируются только базовые показатели вроде DAU, WAU ROI и т.п., не касающиеся напрямую интерфейсов. Т.е. то, что какая-то кнопка никуда не ведет, на этапе софт-ланча заметят, а вот то, что игроки не догадываются вызвать всплывающую по тапу подсказку, уже нет.
В своей практике я, к своему сожалению и стыду, до сих пор еще не сталкивался с полноценным UX-тестированием и последующей аналитикой результатов. Основным методом принятия решений всегда была т.н. “экспертная” оценка. Это когда решения по теме принимает одно лицо (или небольшая группа лиц) которое, как считается, обладает необходимым опытом и компетенцией. Понятно, что это не самый точный и, мягко говоря, довольно субъективный метод.
Однако тот факт, что я лично не сталкивался в с UX-тестированием в геймдеве, не означает, что его не существует в природе. Насколько мне известно, отдельные игровые компании имеют возможность и желание проводить полноценные плей-тесты и активно ими пользуются. Мне очень интересно было бы узнать об их методиках и результатах, а также о том, как они к этому пришли к организации подобных мероприятий. Если вам есть что сказать на эту тему — пожалуйста, свяжитесь со мной или расскажите об этом опыте в комментариях или собственном материале.
На этом, пожалуй, всё. Несмотря на то, что многие вещи я обрисовал очень коротко или пропустил вовсе, статья вышла объемнее, чем рассчитывалась изначально. Спасибо, что были стойкими и дочитали ее до конца! Надеюсь, что вы нашли для себя что-то полезное и интересное. Будет вдвойне приятно, если что-то из прочитанного показалось вам достаточно интересным для того, чтобы опробовать это на практике.
Буду благодарен за любые комментарии, вопросы и замечания по сути, а также просто интересные истории из жизни, связанные с игровыми интерфейсами. Не стесняйтесь писать на почту.
Всем удачи!
Вступительное слово. В своей практике я не раз сталкивался с тем, что разработкой и проектированием игровых интерфейсов занимаются люди, напрямую к этой области не относящиеся. Скажу больше, часто это люди, для которых обязанности, связанные с интерфейсом, являются дополнительным и нежелательным обременением. Чаще всего это связка геймдизайнер+художник, в которой геймдизайнер продумывает функционал и разметку экранов, а художник добросовестно старается “сделать красиво”. При этом зачастую ни тот, ни другой не имеют опыта работы с интерфейсами, не задумываются о юзабилити, пользовательских сценариях или единообразии элементов и в целом не понимают, как организовать процесс работы с интерфейсом, чтобы получить гарантированно хороший результат. И это происходит не по вине художников или геймдизайнеров, просто сама ниша игровых интерфейсов очень специфическая и узкая, информации по работе с ними очень мало, и людям банально негде набраться опыта, не с чего начать. Я хотел бы поделиться своим опытом и наблюдениями в этой сфере и предложить некую структуру, чек-лист, с которым можно сверяться при разработке игрового интерфейса на (вашем) проекте.
Пара слов о себе: работу в геймдеве я начал в 2011 году как flash- и web дизайнер. C 2013 работаю исключительно как дизайнер интерфейсов на игровых проектах, в основном мобильных. За это время я поработал в офисах как небольших стартапов, так и в крупных, устоявшихся компаниях; попробовал себя в качестве фрилансера-удаленщика и приходящего “эксперта”. Всего я поучаствовал в создании примерно двух десятков игр разного масштаба и качества, из которых около дюжины дожили до релиза и лежат в маркете. Если кому интересны конкретные тайтлы — пишите в личку.
И давайте договоримся сразу: то, что написано ниже — ни в коем случае не истина в последней инстанции. Мой опыт ограничен. Если вы считаете, что где-то я написал ерунду (или знаете, как сделать что-то лучше) — пожалуйста, свяжитесь со мной или опишите свое видение в комментариях.
Окей, теперь к сути. Давайте для начала окинем всю последовательность предлагаемых мною шагов разом, а затем я постараюсь объяснить, зачем нужен каждый из них и какие грабли вы рискуете собрать, пропустив или недооценив каждый из шагов.
1) Определение структуры и главных функциональных частей интерфейса.
2) Прототипирование ключевых экранов в виде схем.
3) Сброка и тестирование прототипа. Поиск стилистики и внешнего вида.
4) Отрисовка экранов, составление UI kit’а. Документация.
5) Внедрение в игровой движок, приемка и контроль качества.
6) Добавление интерфейсных анимаций.
7) Аналитика результатов.
Пойдем по порядку.
Шаг первый. Определение структуры и главных функциональных частей интерфейса.
Разработка интерфейса (в идеале) начинается после того, как сформирован дизайн-документ, описывающий базовый функционал проекта. Исходя из него, игра разбивается на логические части (к примеру, боевая сессия, глобальная карта, клановые интерфейсы и т.д.), которые, в свою очередь, дробятся на конкретные экраны. Затем команда, включающая в себя всех заинтересованных, набивается в переговорку и проходится по каждой части проекта, в дискуссионной форме стараясь ответить на вопрос “что именно там должно быть?”. В результате таких дискуссий формируются ТЗ для первых мокапов, которые затем попадают в руки UX-специалистов.
В процессе накидывания этих первичных мокапов будут материализовываться “правила”, по которым строится интерфейс на данном конкретном проекте. Как осуществляется навигация? Где будут располагаться кнопки? Сколько текста понадобится и какого примерно размера он будет? Нужны ли тултипы и иные всплывающие элементы и если да, то где и в каком формате?
На выходе вы должны получить генеральную схему экранов проекта, по возможности минимизировав при этом количество “белых пятен” на ней. Выглядит это как-то так:
На что тут следует обращать внимание:
- На связи между экранами.
- На функционал (удобно ли делать то, для чего экран нужен).
- На размеры и расположение основных элементов.
Хочу сконцентрировать ваше внимание на одной важной, на мой взгляд, мысли: геймдизайн должен значительно опережать графический дизайн. На этапе, когда детальных описаний экранов либо нет вообще, либо когда они есть, но только для одного-двух экранов, не надо начинать работать с интерфейсом, по крайней мере не на чистовую — используйте заглушки. В противном случае вы потеряете массу времени и денег на переделки. Помните, что перерисовывать макеты в заглушечном формате в разы проще и быстрее, чем переделывать уже «финализированный» интерфейс, не говоря уже о собранном и реализованном. Причем, чем больше базовых игровых фич вы откладываете на “потом”, с тем бОльшим количеством проблем столкнетесь в будущем, пытаясь впихивать новый функционал в уже устаканившуюся систему взаимодействия.
Понятно, что в реальности продумать все заранее невозможно, и вы постоянно будете сталкиваться с ситуацией, когда надо “добавить сюда еще вот это и вон то”. Это абсолютно нормально, будьте готовы к таким ситуациям: заранее закладывайте возможность добавления в экран новых элементов, обговаривайте этот вопрос с гейм-дизайнерами или проект-менеджерами (“как думаешь, что еще может добавиться на этот экран в ближайшей перспективе?”) Надо понимать, что у каждого экрана есть свой предел прочности, по достижении которого понимаешь, что проще все удалить и сделать по-другому, чем продолжать попытки впихнуть невпихуемое.
Это, кстати, классическая и неизбежная проблема проектов-долгожителей, особенно мобильных и браузерных. Чем дольше живет игра, чем шире и разнообразнее становится ее функционал, тем безобразнее, замусореннее выглядит ее интерфейс.
Шаг второй. Сборка прототипа, поиск стилистики.
Итак, у нас на руках есть дизайн-документ, общая, более-менее цельная заглушечная схема экранов и связей между ними. Теперь мы уже более-менее понимаем, какой объем работы по части интерфейса предстоит сделать, понимаем количество экранов и примерный набор элементов на каждом из них. Это прекрасный момент для того, чтобы начать собирать на коленке уродливый прототип интерфейса из квадратиков и кружочков. Да, вы никогда не покажете его своим друзьям и маме, но он ответит на множество вопросов, в том числе интерфейсных:
Параллельно со сборкой прототипа интерфейса (что обычно занимает время), имеет смысл начинать работы по поиску его стилистики и визуализации.
Почему не раньше, спросите вы? До схем и, возможно, даже до дизайн-документа? Можно и раньше. Но в таком случае вы рискуете столкнуться с (очень возможной) ситуацией, когда картинка, нарисованная по абстрактному ТЗ, совершенно не впишется в реальные требования конкретно вашего проекта, и придется искать стилистику с начала.
Перед началом отрисовки экранов исполнителю (художнику или дизайнеру — короче, тому кто будет отрисовывать) необходимо прежде всего максимально дотошно расспросить заказчика о том, каким он видит интерфейс проекта. На что тот будет похож? Какие игры (по мнению заказчика) близки к вашему проекту визуально и атмосферно? А какие игры нравятся самому заказчику, во что он играет, какие проекты уважает? Здорово, если у вас на руках уже будут какие-то атмосферные концепты, отражающие стилистику будущей игры, или фейк-скрины, но чаще всего подобная роскошь на этом этапе недоступна.
Вообще, общение с заказчиком — это очень важная часть работы, которая может сэкономить (или потерять, в случае пропуска) всем в производственной цепочке кучу времени. К сожалению, большинство дизайнеров сложно назвать эталоном по части общения с клиентом (я тут, кстати, не исключение). Именно поэтому так важно сделать над собой психологическое усилие, а также объяснить (как себе, так и заказчику) смысл и важность происходящего. Приемка интерфейсов, как и приемка арта — дело сугубо субъективное, от этого никуда не денешься, и крутится оно вокруг личности и системы ценностей заказчика. В процессе работы вы можете давать рекомендации или советы, высказывать мнения и приводить примеры, но последнее слово всегда остается за заказчиком или его представителем, и это логично. А заказчики бывают очень разные: кто-то хорошо представляет, чего хочет, кто-то — нет. Одни могут сформулировать запрос в виде картинок (что просто прекрасно), другие готовы описать на словах (что тоже неплохо), третьим не хватает насмотренности или опыта (а иногда и желания, т.к. они считают, что выполняют тем самым чужую работу) и им требуется помощь с формулировкой мыслей. Вообще, это тема для отдельной статьи. В рамках этого материала мы на этом задерживаться не будем.
Заметка на полях: требования и пожелания от заказчика лучше фиксировать в письменном виде — таким образом ему сложнее потом “передумать” или “забыть” сказанное. И никогда не соглашайтесь на “ой, не знаю, вы там давайте рисуйте что-нибудь, а там разберемся”. Это мартышкин труд, который никому не нужен, в том числе заказчику.
Результаты работы с интерфейсом на втором этапе:
Во-первых, создан или ведется работа по сборке прототипа интерфейса, основанного на схемах и заглушечном визуале.
Во-вторых, собран набор референсов для чистового визуала, которые нравятся и одобрены заказчиком. Каждый реф может зацепить заказчика чем-то конкретным (цветовой гаммой, решение главного меню, системой навигации) или просто общим впечатлением от картинки. Храните эти рефы как зеницу ока — они станут краеугольным камнем для следующего этапа.
Примеры реф-листов:
Заметка на полях: в первую очередь лучше набирать референсы из той же рыночной ниши, что и ваш проект. Дело в том, что если вы наберете отличные рефы из ААА игр для ПК, а сами занимаетесь разработкой мобильной игры, то согласовать-то их может быть будет и проще, а вот реализовать всю эту красоту в ограниченном мобильном формате будет практически невозможно. В результате на каком-то этапе вы столкнетесь с закономерным вопросом от заказчика: “Мы же подобрали такие крутые рефы, почему в результате получилось ВОТ ЭТО?”.
Еще одна заметка на полях: уделяйте на этом этапе побольше времени и сил изучению конкурентов. Смотрите скриншоты, читайте обзоры, проходите на ютубе, в конце концов. Чем больше будет ваша насмотренность, тем проще вам будет понять, что лучше работает (или не работает) в аналогичных проектах и тем легче аргументировать свое мнение. Не спешите изобретать велосипеды и не бойтесь простоты.
Шаг третий. Обкатка прототипа, отрисовка превью экранов.
Итак, у нас есть рабочий прототип, в котором реализован заглушечный интерфейс. Он, в целом, работает, выполняет свою функцию. А еще у нас есть визуальный ориентир для отрисовки экранов в виде набора референсов. Самое время их совместить: “одеть” несколько экранов в понравившуюся “шкурку”.
В процессе отбора рефов обычно становятся понятны основные направления для отрисовки первых экранов-превью: Скажем, если у вас sci-fi сеттинг, а в одобренных заказчиком рефах лежат Deus Ex и XCOM… ну, я бы сказал, что вам придется делать превью как минимум в двух вариациях:
А если в рефах лежат какие-то близкие по стилистике экраны (тот же XCOM и, скажем, Mass effect) а времени не очень много, то вполне можно обойтись и одним:
После того, как мы довели один экран-превью до состояния, которое нравится заказчику, имеет смысл отрисовать еще парочку в той же стилистике, выбирая их по принципу “максимально отличающихся”. К примеру, если первым был экран с небольшим количеством крупных элементов, то имеет смысл в дополнение к нему взять экран с большим количество маленьких элементов (например, инвентарь) и что-нибудь табличное (вроде таблицы рейтингов или статистики боя). Таким образом, вы уже на старте отработаете максимальное количество различных элементов и будете более-менее уверены в том, что выбранная “одежда” универсальна и будет достойно выглядеть на любом экране.
На этапе отрисовки превьюшек вполне можно пренебречь какими-то элементами или делать допущения в стиле “эту рамку потом придется подправить, иначе в движок ее не вставить” или «вот эти иконки надо будет подогнать под один размер». Здесь важно за минимальное количество времени получить максимально презентабельную, “продающую” картинку, которую уже не стыдно показывать инвесторам, использовать в презентациях и т.д.
Результат этого этапа: 3-4 отрисованных экрана “чистового” качества, одобренных заказчиком и обкатанная в прототипе схема интерфейса.
Шаг четвертый. Отрисовка экранов, составление UI kit’а, документация.
Это самый объемный этап работы с интерфейсом, занимающий примерно 70% всего рабочего времени. Причем для него у меня нет каких-то хитростей и лайф-хаков, только кропотливая работа и чугунный зад. Планомерно и постепенно, экран за экраном отрисовываются и внедряются в движок. Одновременно с этим обновляется их состав и функционал (потому что с момента рисовки схем обычно многое уже поменялось), а также составляется документация.
Пара слов о документации. Как показала практика, очень полезно описывать функционал экранов. Письменно. Для кого-то это прозвучит очевидным советом от кэпа, но вы удивитесь, как часто этот этап пропускают (особенно в небольших компаниях). Не в последнюю очередь это происходит потому что, во-первых, никто не любит бюрократии (у нас же тут геймдев и рок-н-ролл или что?), а во-вторых, потому что с документацией надо уметь работать. Это подразумевает как умение грамотно сформулировать описание со стороны ГД или UI/UX дизайнеров, так и умение и привычку использовать его при сборке экрана программистами. Ну и в-третьих, документацию ведь надо держать в свежем виде и регулярно обновлять. Это тоже требует времени, сил, желания и, главное, понимания, зачем оно всё нужно.
Без письменных описаний экранов вы рискуете столкнуться со всеми проблемами, связанными с человеческим фактором, забывчивостью и коммуникационными проблемами. Ваш UX-дизайнер внезапно увольняется и улетает на Бали. Программисты собирают экраны не так, как задумывалось, а так, как они считают правильным, апеллируя к тому, что “им про это не сказали”. Геймдизайнер или проект-менеджер забывает принятые решения, поскольку они не были зафиксированы, и всякий раз выдает новую версию.
Короче, приучайте себя к работе с документацией. Договоритесь внутри команды, как именно это делать: какая должна быть структура, какие инструменты использовать, на чем акцентировать внимание. А если вы уже вовсю пользуетесь документацией на проекте и сейчас только понимающе усмехаетесь, покручивая ус — берите печеньку, вы клёвые.
Дальше немного про GUI pack (или, как его еще называют, UI kit или design case). После отрисовки нескольких базовых экранов обычно становится понятен основной набор элементов, из которых будет состоять ваш интерфейс, а также правила их компановки. При дальнейшей работе с экранами будет примерно на 60-80% состоять из реюза уже готовых элементов по уже готовым правилам. Имеет смысл вынести этот “конструктор” с элементами и описаниями в отдельный, эталонный файл. Выглядит он примерно вот так:
Автор изображения — Johnny Waterman
С готовым UI KIT’ом все в команде (особенно это актуально для верстальщиков и программистов) будут знать, где содержатся самые последние, эталонные версии всех интерфейсных элементов. В то же время, в макетах конкретных экранов дизайнерам можно будет не держать десятки дублирующих слоев вроде всех состояний кнопок и переключателей.
Шаг пятый. Внедрение в игровой движок, контроль качества.
Этот этап выделен условно, т.к. сборка интерфейсов в движке обычно идет параллельно их разработке. Взяли экран со схемы, отрисовали, нарезали, отдали программистам, взялись за следующий. При этом вы “ведете” экран, находящийся в производстве, до победного конца. Только когда он собран в версии для целевых устройств (кстати, вы же не забыли про планшеты?), выглядит и работает на них так, как планировалось изначально, вы можете облегченно выдохнуть и мысленно поставить галочку в графе “сделано”. До следующей итерации.
Помните, что результат работы UX/UI специалистов — не статичная фотошопная картинка и не абстрактная схема, а красивый и, главное, функциональный интерфейс, с которым будет работать пользователь. То, насколько хорош финальный продукт, показывает, настолько хороши конкретно вы как специалист. Поэтому будьте строги и внимательны ко всем звеньям в производственной цепи, и в первую очередь к себе. Не закрывайте глаза на всякую лажу под предлогом того, что это “не моя ответственность”.
Шаг шестой. Полировка и добавление анимаций.
Это бонусный этап. Будем откровенны: при приближении даты релиза (обычно уже несколько раз перенесенной) у всех в команде начинают пылать различные части тела. Времени на полировку (а особенно полировку интерфейса, которому исторически отводят второстепенное значение) никогда не хватает. Поэтому важно изначально задумываться о том, что и когда вы будете доделывать, а также об интерфейсных анимациях. Есть возможность — добавляйте их сразу, еще при первой сборке экрана. Нет такой возможности — выделите на это отдельное, конкретное время в планах разработки. Жестко стойте на своем и не соглашайтесь отодвигать доделки и анимации на неопределенное “потом”, регулярно напоминайте про них.
Хороший игровой интерфейс “живет” и динамично реагирует на действия игроков. Интерфейсная анимация — как щепотка специй, способная преобразить вкус и ощущения от всего “блюда”. Она делает интерфейс более плавным, связанным, последовательным. Она сглаживает резкие переходы, привлекает внимание к нужным местам, развлекает — короче, улучшает игровой опыт пользователей в целом. При этом, как и в кулинарии, важно не переборщить и не поддаться искушению заанимировать всё подряд. Знайте меру.
Шаг седьмой. Аналитика интерфейсов.
Еще один условно-бонусный этап. В идеальном мире разработчики проверяют основные гипотезы (в т.ч. интерфейсные), привлекая для тестов реальных пользователей из своей ЦА, и принимают решения, исходя из полученных данных. При правильном подходе такой метод позволяет (в теории) отразить более-менее объективное положение дел и дать ответ на вопрос, что в интерфейсе действительно работает, а что нет.
В реальности такое встречается редко: не все могут позволить себе дорогостоящие плей-тесты, мало кто умеет с ними работать и понимает, зачем они нужны. Даже после софт-ланча часто анализируются только базовые показатели вроде DAU, WAU ROI и т.п., не касающиеся напрямую интерфейсов. Т.е. то, что какая-то кнопка никуда не ведет, на этапе софт-ланча заметят, а вот то, что игроки не догадываются вызвать всплывающую по тапу подсказку, уже нет.
В своей практике я, к своему сожалению и стыду, до сих пор еще не сталкивался с полноценным UX-тестированием и последующей аналитикой результатов. Основным методом принятия решений всегда была т.н. “экспертная” оценка. Это когда решения по теме принимает одно лицо (или небольшая группа лиц) которое, как считается, обладает необходимым опытом и компетенцией. Понятно, что это не самый точный и, мягко говоря, довольно субъективный метод.
Однако тот факт, что я лично не сталкивался в с UX-тестированием в геймдеве, не означает, что его не существует в природе. Насколько мне известно, отдельные игровые компании имеют возможность и желание проводить полноценные плей-тесты и активно ими пользуются. Мне очень интересно было бы узнать об их методиках и результатах, а также о том, как они к этому пришли к организации подобных мероприятий. Если вам есть что сказать на эту тему — пожалуйста, свяжитесь со мной или расскажите об этом опыте в комментариях или собственном материале.
На этом, пожалуй, всё. Несмотря на то, что многие вещи я обрисовал очень коротко или пропустил вовсе, статья вышла объемнее, чем рассчитывалась изначально. Спасибо, что были стойкими и дочитали ее до конца! Надеюсь, что вы нашли для себя что-то полезное и интересное. Будет вдвойне приятно, если что-то из прочитанного показалось вам достаточно интересным для того, чтобы опробовать это на практике.
Буду благодарен за любые комментарии, вопросы и замечания по сути, а также просто интересные истории из жизни, связанные с игровыми интерфейсами. Не стесняйтесь писать на почту.
Всем удачи!