User Experience Flow
Блог

Как составлять User Experience Flow

Гайд о том, как составить UXF для разработки приложения, игры в данном случае. Этот документ поможет увидеть картину в целом, количество игровых компонентов, их связи. User Experience Flow является частью фундамента приложения, который составляется в фазе предпродакшена (планирования).

Сразу приношу свои извинения тем, кому обещал написать этот гайд сразу после доклада в «I Business Incubator» о подготовительной работе перед стартом проекта. В первую очередь эта заметка будет интересна: PM, PO, Producer, GD, BA.

Кто работает с User Experience Flow

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

Готовый UXF читают всё те, кто задействован в предпродакшене. Технический специалист, глядя на схему, определяет наилучшие технические решения, что оставить на бэкэнде, а что взять на клиент. UI-дизайнер берет UXF за основу при составлении карты экранов, и также определяет объем работы. Будет огромным плюсом команде, где Project Manager умеет читать такие схемы. Таким образом он может понимать как именно строится проект, какие его части более трудоемки и ресурсозатратны, и в дальнейшем сможет увидеть, долю реализации проекта от общего объема.

Обозначения

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

В своих блок схемах я использую следующие элементы:

Flowchart start stop.png
Flowchart connector.png
Начало / Конец алгоритма и соединитель. Такими элементами соединяются блоки, разрывы в схеме.
Экран или поп-ап — форма вывода чего-то на экран.
Выбор пользователя: это может быть кнопка на экране или выбор из списка или любой другой способ принятия решения. Такой подход функционально показывает результат действия, но не влияет на визуализацию, которой потом займутся дизайнеры.
Системный анализ, проверка, которую делает игра. Например: хватает ли пользователю энергии, чтобы начать уровень, первая ли сессия у игрока сегодня, достаточно ли денег для покупки.
Системные действия, которых пользователь не видит. Например: верификация платежа, загрузка контента или создание нового пользователя в базе данных.

Flowchart preprocess.png
Блок процессов, который внутри себя содержит другой алгоритм. Это как контейнер, в котором может лежать реализация целого компонента игры. В такие контейнеры мы помещаем каждый игровой компонент. Например: ингейм процесс, процесс оплат, процесс взаимодействия с друзьями социальных сетей.

Важно помнить

  • Все разветвления могут быть только из «ромбов». Изменить игровой процесс может только пользователь, при помощи своего выбора или системная проверка, которая повлияет на игру.
  • Линии не должны пересекаться и проходить «под» блоками схемы, иначе возникают проблемы с чтением схемы.
  • Если возникают сложности с замыканием схемы, сделайте переход через элемент соединения разрыва (круг)
  • Линии могут соединяться в одну, если их назначение равнозначно, т.е. связь одинакова. Например выход в ЛОББИ из любого экрана — всегда будет одинаковым.
  • Используйте закругленные края — это поможет точно определить направления процессов на стыках линий
  • Используйте сноски и комментарии, это всегда полезно в больших и сложных схемах.

Как составить алгоритм

Начиная с загрузки приложения нужно схематически изобразить все процессы во всех вариациях, которые только возможны. Следует также выносить в отдельные блоки (контейнеры) отдельные процессы.

  1. В начале изобразите основной процесс — General
    На нем будут основные экраны и базовые ответвления. На этой схеме будет полноценная игровая петля.
  2. Каждый отдельный блок выносите на отдельные схемы (листы). В дальнейшем, если у вас в проекте что-то изменится вы можете попросту заменить/улучшить/оптимизировать содержание контейнера, что не  повлияет на весь алгоритм
  3. Блок Ingame — ваша Core-механика, так же, как и любой компонент, лежит в отдельном блоке. Может содержать отсылки на другие алгоритмы, и содержать множество процессов. Содержание этого контейнера в блок схеме может меняться в процессе разработки, и тут стоит посоветоваться с техническим специалистом, который будет реализовывать этот игровой компонент.

Для простой, казуальной, f2p игры составление такого алгоритма составит 1-2 дня, и занимает он порядка 10 листов:  General (1), Ingame (1-3) и еще порядка 7 отдельных компонентов.

Инструментарий

Карандаш, Линейка и Голова. В своей практике использую Cacco и Gliffy — удобные web-сервисы, с возможностью создания вложенностей и отдельных страниц, управление правами доступа и прочие фишки. Из локальных — можно скачать Pencil — расширенные функции импорта и удобный UI.

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

Поделись с коллегами: