Особенности создания интерфейса для мобильной игры

Принципы и правила работы с небольшими экранами.

При создании интерфейсов для мобильных игр разработчикам порой приходится идти на компромиссы из-за относительно небольших дисплеев. И речь не только о размерах иконок и окон или об их расположении.

Ведущий UX и UI-дизайнер студии Azur Games Екатерина Кузьмичёва написала для DTF колонку об основных принципах, которыми следует руководствоваться при создании интерфейса для мобильной игры и о том, на что нужно обращать внимание.

Создание любого интерфейса предполагает комплексную работу с несколькими аспектами: с UX, со стилистикой, с синтаксической структурой, с эргономичностью, с логичностью и многими другими. В этой статье я хочу рассказать об особенностях UI мобильных игр, а также о том, как решаются характерные для этого вида интерфейсов проблемы.

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

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

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

Реальность такова, что при работе с небольшим экраном мы имеем условно маленький диапазон (по сравнению с десктопными играми) вариантов размера и возможностей расположения элементов. Эргономическая составляющая диктует некоторым элементам UI находиться в определённом месте и быть определенного размера.

Помните мультфильм о купце, который принёс портному маленькую меховую шкурку с просьбой сшить из неё шапку? Потом он вошёл в свой купцовый раж и начал просить сшить две, три, нет семь (!) шапок из всё той же шкурки.

Этот сюжет я пересказываю коллегам и называю его «Притча о юайщике», потому что вижу сходство ситуаций. В мультфильме всё закончилось бодрым нравоучением о том, как плохо быть жадным. В работе UI-дизайнера вводные данные — это условная маленькая шкурка с большим ожиданием. Примерно так воспринимается эта сложная задача и её решение.

Ключевым принципом является подход: «Одна пользовательская задача — один экран». Этот принцип не нов, но я пишу о нём, поскольку до сих пор встречаются трудности его воплощения. Главным препятствием является нежелание прятать некоторые функции «далеко», за дополнительные клики. Есть риски, что эти клики так и не будут совершены. Кроме того, понятие «одна пользовательская задача» не всегда однозначно определимо. То, что является одной задачей для одного человека, может дробиться на несколько других.

И если мы понимаем, что на нашем экране будет чуть больше, чем одна пользовательская задача, то нужно максимально удобно и логично организовать пространство экрана. В этом помогает понятие зонирования — определение внешнего вида фрагментов UI (зон) со сходными функциями и принципы сочленения этих зон.

Зоны, определённые проектировщиком, должны организовываться на экране в соответствии с тем, какова выбранная ориентация устройства — портретная или пейзажная. Идея «у нас много вертикали, но мало горизонтали» (или наоборот) определяет работу проектировщика интерфейса на глобальном уровне. Картинка ниже иллюстрирует подобную стратегию расположения элементов UI.

Иногда встречаются мобильные игры в пейзажной ориентации, которые «считают» себя играми в портретной ориентации — именно так там организован контент.

Не стоит забывать пользоваться пространством за пределами экрана. К нашим услугам всевозможные слайд-панели. Информация на них должна обладать определённым свойством — быть необходимой ситуативно, по требованию. При обращении к этой информации пользователь никуда не перемещается, а значит продолжает находиться в том же контексте, что и был.

Ещё один принцип проектирования интерфейса мобильной игры звучит как жесткий императив — «ни одного лишнего элемента на экране». До сих пор находится огромное количество мобильных игр с элементами UI, не делающими собственно для UI ничего.

Среди доводов в защиту подобных завитков можно услышать «это стилистика, завитушка принесла атмосферу фэнтези». Да, резонно, но в условиях решения сложной задачи по приобретению пространства приходится быть требовательнее к элементам на экране.

Носители стилистической идентичности могут в то же самое время выполнять ещё какую-либо задачу, то есть «работать на двух работах». Например, завиток фэнтезийного типа одновременно разбивает пространство на зоны, или «сай-файное свечение» на одних элементах даёт понять, что эти элементы кликабельны в отличие от элементов без свечения. Поместить завиток ради завитка — непозволительная роскошь в условиях работы над интерфейсом мобильной игры.

Тезис «ни одного лишнего элемента на экране» не исчерпывается лишь крестовым походом против условных завитков. Убирание лишних элементов иногда может касаться даже не собственно элементов, а расстояний между ними. Вообще, пространство между элементами — это то, о чём следует думать не меньше, чем над самими элементами. Качество восприятия сложносоставных объектов определяется тем, сколько воздуха в них.

Получается некое противоречие, ведь мы знаем, что пространство мобильного экрана невелико, но хорошие воздушные отступы между элементами положительно сказываются на их читабельности. Возможным решением может показаться уменьшение самих элементов. Но это действие под запретом — мельчить на экране мобильного устройства нельзя.

Первое, что стоит сделать для решения задачи приобретения пространства — это внимательно изучить свои элементы. Если какая-либо информация появляется на экране более одного раза, почти наверняка она может быть вынесена за скобки.

Проверьте: если сложносоставной объект представлен последовательностью элементов, то нет ли возможности какой-либо из этих элементов переформулировать и представить его другим образом?

Выше описаны разумные способы приобретения пространства, интуитивно понятные многим проектировщикам. Теперь настала очередь «читерских». Главное условие их использования — ювелирность исполнения. И постоянное отслеживание воплощения на всех стадиях разработки, поскольку в командной работе всегда происходят коммуникационные потери. И есть опасность осуществления сценария «ювелирность + коммуникационные потери = топорность».

Наложение элементов друг на друга — своего рода использование третьего измерения экрана. Подобный приём не может быть применён к элементам, клики на которые обрабатываются отдельно. Здесь важно определить внешний вид каждого из участников наложения таким образом, чтобы они не мешали друг другу. Например, кто-то из них всегда тёмный, кто-то светлый.

Ещё одно использование третьего измерения экрана — «отступы без отступов». Здесь мы пользуемся способностью человеческого мозга самостоятельно дорисовывать образ.

Ходовая единица проекта, многократно встречающаяся в определённом размере, может быть порезана маской сверху-снизу (слева-справа) для какого-то конкретного окна. Её узнаваемость сохранилась: для пользователя это ровно та же самая картинка. Возможная альтернатива этому действию — пропорциональное уменьшение — иногда рискует потерять в площади клика и в целом выглядеть неприглядно.

Итак, перечислим последовательно стратегии, помогающие преодолеть трудности с небольшими экранами.

Если разработчик UI мобильного проекта грамотно распоряжается своим экранным пространством, то он приобретает большую свободу в других аспектах.

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

Можно выделить четыре группы стратегий, помогающих работать над UI растущих проектов.

Представьте, что вы работаете над UI игры какого-то определённого жанра. Если это не первая в мире игра-представитель этого жанра, то у вас есть великолепная возможность ознакомиться с играми-предшественниками. И почти наверняка большая часть фичей из этих игр будет и у вашей игры. А это значит, что на начальном этапе проектирования своего UI вы сразу учитываете всю сумму этих фичей. Отсюда и название этой стратегии — «Хрустальный шар», вы заглядываете в будущее и готовитесь к нему.

В каком-то смысле любая разработка придерживается стратегии предсказывания фичей, ведь существуют планирование и дорожные карты. Но при работе с UI это предсказывание должно стать очень конкретным. Вплоть до того, что вы размещаете в своих макетах прототипы пока ещё несуществующих фичей, резервируете для них место. И чтобы не запутать самого себя и ваших коллег, чётко разграничивайте актуальные на данном этапе сущности от тех, которые появятся потом.

Разумеется, наступившее будущее будет не таким, каким вы его ожидали. Потому что рабочие процессы внесут свои коррективы, некоторые фичи так и не будут введены. Но ваша подготовленность в любом случае облегчит вам работу.

Если новые функции структурно похожи на уже имеющиеся, пользователю будет легче в них освоиться. Его внутренний диалог «а, я понял, здесь всё работает так же, как в мастерской» (например) — это хороший шаг на пути к пониманию. То есть при проектировании UI новой фичи не стоит изобретать велосипед — лучше воспользоваться имеющимся решением.

А это значит, что нужно иметь некоторое количество шаблонов, с помощью которых генерируются новые макеты. В идеале, услышав от продюсера описание фичи, UI-дизайнер сразу представляет, каким конкретно шаблоном он воспользуется.

Но работая с шаблоном не стоит забывать и о «разрыве шаблона». Стройные ряды однотипных окон могут сыграть с вами злую шутку, ваши фичи могут потерять свою индивидуальность. Поэтому после того, как вы воспользовались конкретным шаблоном, подумайте о том, что станет отличительным маркером этого фичи, её изюминкой.

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

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

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

Если однажды в вашей игре появятся кланы, чат, сезонные распродажи и тематические ивенты, нужно, чтобы пользователь смог туда пройти.

Потенциально мест, куда может захотеть переместиться пользователь, бесконечно много, поэтому нужен «бесконечный коридор». Конечность экрана кажется проблемой на пути решения этой задачи.

Чтобы преодолеть эту проблему мы можем:

Расширить экран с помощью свайпа. В игре «Star Wars Галактика героев» в центральной части главного экрана установлены объекты для взаимодействия, являющиеся по сути пунктами меню. Естественное движение свайпа обеспечивает быстрый доступ к этим пунктам.

Спроектировать сквозные переходы. Это актуально для смежных по смыслу фичей. Вообще если в какое-то окно пользователь может попасть строго через одну дверь, то это не очень хорошо для юзабилити. Если конечно речь не идёт о парадной двери.

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

Делать UI мобильных игр сложно. Часто нужно учитывать большое количество параметров и удовлетворять большому количеству условий. И иногда это взаимоисключающие условия. Надеюсь, что описанные в этой статье стратегии помогут другим разработчикам при проектировании UI.

#основы