Редизайн системы управления игровыми сессиями в клубах виртуальной реальности

В статье распишу коротко процесс редизайна админ-системы для крутой компании Arvi VR, которая является одним из мировых лидеров по разработке решений для клубов виртуальной реальности

Краткая предыстория: в конце августа 2020-го года со мной связался Михаил Дементий, основатель компании Arvi VR, которая является одним из мировых лидеров по разработке решений для клубов виртуальной реальности. В 2018-м компания выпустила первую версию админ-системы, которая на данный момент уже морально устарела и требовалось разработать новую версию, которая будет представлять компанию на мировом рынке. Собственно, получив эту вводную информацию я и приступил к работе над проектом…

1. Исследования и формирование требований к продукту

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

После живого общения и получения нужной мне информации я получил понимание задачи, тут опишу её тезисно:

• компания Arvi VR находится на рынке с 2018-го года и предлагает решения для клубов виртуальной реальности по всему миру (в решение входят игры, админ-система управления игровыми сессиями, помощь клиентам по настройке системы а также тех-поддержка);
• в 2018-м году компания выпустила первую версию админ-системы;
• первая версия на данный момент уже морально устарела, и не отвечает текущим требованиям как рынка и пользователей, так и требованиям самой компании (с учетом долгосрочных планов);
• первая версия не адаптивна и не может запускаться на разных устройствах, поэтому нужно решение которое будет запускаться через браузер на разных устройствах;
• через работу с админ-системой клиенты воспринимают компанию и принимают решение работать ли с компанией дальше.

Ниже на фото показана текущая первая версия админ-системы (далее админка), для которой и нужно было сделать редизайн.

Итого, после анализа вводной информации я определил задачу для себя так:

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

Коротко и понятно. После определения задачи и разработки стратегии работы над проектом можно приступать к работе. 👌😎

Исследования

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

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

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

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

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

Я посетил три разных клуба и пообщался там же вживую с тремя админами, которые дали мне первую вводную информацию.

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

После полевых исследований и интервью с админами была составлена первая версия Customer Journey Map, в которой я разложил процесс предоставления услуги на ключевые шаги и на каждом шаге определил что важно, какие есть проблемы и какие есть идеи как решить существующие проблемы.

Всего у меня получилось 4 шага:

• запись на игру;
• перед игрой;
• во время игры;
• после игры.

Эти шаги я отобразил в виде майнд-мепа и отметил ключевую информацию.

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

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

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

В какой-то день у нас было 5 созвонов, что оказалось многовато, лучше делать в день 2–3 интервью, а то не успеваешь как следует проанализировать полученную информацию, да и устаешь от общения.

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

Кроме того я изучил несколько админ-систем которые являются прямыми конкурентами админки от Arvi VR. Эти системы являются достаточно простыми с точки зрения функционала: в основном они дают возможность запускать игры но не дают возможности управлять оборудованием и помогать игрокам во время игровой сессии. Однако я все же подчерпнул некоторые интересные решения, которые можно было позаимствовать.

Анализ текущей ситуации

Во время хождения по клубам и общения с админами я составил первую версию Customer Journey Map, в которой разложил процесс предоставления услуги на ключевые шаги. После серии живых интервью с иностранными клиентами карта была дополнена новой информацией.

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

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

Когда над проектом работают несколько человек то не очень удобно работать с Customer Journey Map в цифровом виде, поэтому мы распечатали таблицу на формате А0 и повесили в офисе на стену.

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

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

Генерация идей и формирование требований

В процессе бреинштормига, который представлял несколько коротких сессий в течение 3–4 дней, мы выдвигали возможные варианты решений той или иной проблемы. Так как основатель компании, с которым мы генерировали и обсуждали идеи, разбирался во всех технических деталях мы сразу же по ходу обсуждения понимали как реализовать ту или иную функцию (идею). Этот момент очень ускорил этот этап, мы достаточно быстро все обсудили без бюрократии, которая показана в одном известном видео…

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

После того как мы обсудили все идеи я сформировал таблицу с требованиями. В эту таблицу вошли идеи, которые соответствовали двум простым критериям:

• решает текущую проблему;
• технически реализуема.

Таблица с требованиями представляет собой четкое описание функционала, который должен быть реализован в следующей версии админки. Это дает возможность четко ограничить объем работ по текущей версии продукта и не затягивать сроки реализации проекта. Функционал, который не входит в эту таблицу, или удаляется или переносится на следующую версию.

Таблица разбита на три колонки:

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

2. Проектирование опыта взаимодействия и прототипирование

Определив все функциональные требования можно переходить к проектированию нового взаимодействия пользователя с интерфейсом.

Логика работы (User Flow)

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

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

Пользовательские сценарии

Определив логику работы с админкой я начал проектировать новый опыт взаимодействия пользователя в виде пользовательских сценариев. Лично для меня такой способ описания подходит лучше все так как помогает сфокусироваться на важных моментах:

• контекст использования продукта;
• какая стоит задача перед пользователем;
• как пользователь решает свою задачу;
• какой в итоге результат пользователь получает.

Я прописал все ключевые сценарии, в которых описывается как админ использует админку в течение рабочего дня, при этом особое внимание я уделил именно новому функционалу.

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

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

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

Принципы

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

Основываясь на этих принципах я определил общую схему построения интерфейса и определил расположение ключевых элементов:

• рабочая зона с основной информацией;
• меню;
• кнопка с ключевым действием;
• панель с заголовком, кнопками действий и уведомлениями;
• учетная запись.

Прототипирование

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

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

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

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

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

Я сделал новую “темную” версию админки и вставил туда изображения игр, чтобы можно было оценить эту идею.

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

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

В этом прототипе можно покликать на все ключевые элементы и получить полное представление как должна работать новая версия админки. Ссылка на прототип: https://xd.adobe.com/view/63cd0839-de70-406f-8414-9c4af4ddbf6e-369e/

Тестирование

Чтобы убедиться, что новая версия админки, которая достаточно сильно отличается от текущей, будет понятной и не создаст новых проблем я провел небольшое тестирование на админе, который работает в одном из клубов виртуальной реальности. Я прописал сценарии тестирования, в которых описаны ключевые действия админа.

Тестирование показало, что проблем с выполнением этих действий нет, админ сразу находит то, что нужно.

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

3. Графическое оформление, гайдлайны и пояснения для разработчиков

После того как финальную версию утвердили я приступил к проработке графического интерфейса и подготовил документации с пояснениями для разработчиков. К слову сказать, моей специализацией является UX Design но в работе над этим проектом я провел полный объем работ.

Графическое оформление я делаю только для ключевых сценариев и на их основе разработчик может определить как будут выглядеть все остальные.

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

Ключевые экраны и гайдлайны были сделаны для всех трех версий: для десктопа, планшета и мобильного телефона.

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

Результат работы

Работа над проектом длилась около двух с половиной месяцев, при этом я работал в среднем около 3–4х часов в день. Работая над этим проектом я прошел все шаги, которые проходит UX Designer / Product Designer работая над проектом без спешки и постоянного подгорания одного места, что и сказалось благотворно на результате. В итоге получился современный продукт, который позиционирует компанию как одну из лучших в своем деле и который можно смело предлагать на мировом рынке.

Что было (старая текущая версия).

Что получилось (новая версия).

А вот и видеопрезентация новой админки, круто пролучилось!