Процесс UX/UI редизайна Maps.me в колаборации British Higher School of art & design и Mail.ru Group

Всем привет!

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

Почти во всех школах дизайна учат примерно такой последовательности:👇

• Категоризируем и приоритезируем проблемы, которые выявили
• Создаём персоны и карты путешествий
• Генерируем идеи
• Создаём прототип на основе гипотез
• Делаем предварительные тестирования прототипа
• Делаем UI для протестированного прототипа
• Передайте финальную версию разработчикам
• Контролируем реализацию и запускаем продукт или флоу
• Делаем все сначала, отталкиваясь от фитбека пользователей

В крупных компаниях, процесс чаще происходит примерно так👇

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

Здесь я не буду описывать полный процесс обучения в «‎британке», ведь статей обзора «‎британки» и интенсивов более чем достаточно.

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

Как вообще так получилось?

В 2017 году, во время обучения в «британке», я принял участие в так называемом «интенсиве — практикуме» по направлению « UX & UI : Продуктовый дизайн».

В рамках данного практикума, и благодаря моему наставнику и куратору курса Юрию Ветрову, «британка» делала коллабы с известными продуктами корпорации Mail.ru и не только, о чем он написал отдельную статью.

Начало.

У каждого из нас был выбор, над каким приложениемили сервисом мы будем работать:

1 — главная страница Mail.ru2 — почта Mail.ru3 — приложение Delivery Club4 — приложение MAPS.ME5 — главная страница Альфабанка6 — мессенджер «там там»

Задача для студентов была классической:

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

В итоге мы должны были предоставить презентацию процесса и результатов нашей работы в следующем формате:

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

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

То ли сердцем, то ли логикой я сразу отмёл все страницы mail.ru, понимая, что независимо от качества дизайна, шансы, что наш концепт попадёт на продакшн, минимальны (и я не ошибся).

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

Для меня оставалось всего 2 приемлемых варианта: Delivery Club или MAPS.ME.

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

Мой выбор пал на MAPS.ME по 4 причинам:

• MAPS.ME — единственный из вышестоящих сервисов с юзерами по всему миру. Это было сложнее, но интереснее!
• Продуктовнер MAPS.ME обещал поделиться аналитическими данными, раскрыв команде немного метрик по запросу, а также хорошие показатели DAO и MAO (около 10 тыс. юзеров в сутки).

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

3. Можно было напрямую предложить фичи владельцам продукта, и был шанс, что хоть что — то доберётся до продакшна, а когда твои фичи на продакшене — это кайф!

4. Я сам путешественник, поэтому неоднократно юзал maps.me при поездках в разные страны, видел ценность в концепте оффлайн карт, но признаюсь, меня всегда раздражал дизайн приложения и словно сама Вселенная дала мне шанс все исправить)

Ключ к успеху — ответственность! Вперёд!!!

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

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

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

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

Как проходили этапы работы?

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

Чтобы процесс дизайна сразу не ушёл в полную субъективность, а команда выстраивала гипотезы без типичных ошибок, таких как:

1 - Примерка роли юзера на себя,

2 - Cтроение гипотез и выводов на основе «экспертности» дизайнеров,

3 - Типичной «ошибки выжившего» или невалидности аудитории.

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

Для этого мы решили сделать 4 простых действия:

1 - Изучить функционал приложения;

2 - Изучить все возможные отзывы о приложении в интернете (AppStore, Play Маркет, тематические форумы и все возможные упоминания, на которые приведёт Гугл или Яндекс);

3 - Выписать список наиболее частотных проблем, с которыми сталкиваются пользователи, и приоритизировать их;

4 - Провести опрос среди пользовалей, задав следующие вопросы:

«‎В каких ситуациях вы используете приложение чаще всего?»«‎Какие функции приложения самые ценные для вас?»«‎Какие проблемы вы испытываете в работе с приложением?».

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

Для разделения аудитории на обобщенные сегменты, роли, портреты пользователей, мы сделали три простые вещи:

1 — Провели дополнительные опросы среди пользователей:“Кто и как юзает продукт?”;

2 — Приоритизировали контексты использования;

3 — Воспользовались предварительными исследованиями и здравым смыслом.

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

Также, удалось выяснить, какие категории пользуются преимущественно офлайн и онлайн.

1 — 👽🗺 Используют Maps.me здесь и сейчас (Больше Online)

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

2 — ✏🗓 Планировщики (больше Оffline)

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

3 — 🚗 🛣 Автомобилисты (больше Оffline)

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

4 — 🔍🏠 Домашние пользователи (больше Online)

Ищут интересные события рядом с собой и ожидают высокую информативность сервиса (ищут места и локации по карте в своём районе и прокладывают маршруты).

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

Выяснив основные контексты использования, мы попросили респондентов выполнить самые популярные сценарии и задачи, например: «‎найдите ближайший банкомат или ресторан» или «‎проложите маршрут к найденой локации»….

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

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

Полет нормальный, летим дальше…

Перед тем как начать строить или проверять гипотезы, нужно всегда держать в голове один вопрос: Зачем мы это делаем?!

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

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

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

Итак, мы точно выяснили 3 самые важные вещи для первых гипотез:

1 — Аудитория и контексты использования;

2 — Наиболее частые проблемы при использовании;

3 — Самые релевантные воркфлоу.

Совокупность этих данных позволила выяснить и приоритизировать недостатки и преимущества приложения.

Нам удалось получить какие-то количественные статистические данные (но они были очень общими, и мы их почти не использовали)

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

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

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

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

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

Каждый из нас накидал от 3 до 5 самых важных по его мнению проблем и идей, после чего мы их обсуждали и голосовали — какие гипотезы мы точно берем в работу.

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

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

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

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

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

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

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

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

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

Здесь вы найдете статью о правилах применения сенсорного дизайна

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

Конечно же, можно забить в гугле, но тогда зачем пользоваться MAPS.ME? А если нет интернета? Для чего тогда нужны оффлайн карты?

Здесь мы добавили умные теги, привязанные к запросам. Например, по запросу «‎еда», можно показывать такие теги, как «‎японская кухня» или «‎здоровая еда» и подобные. Также можно сразу посмотреть места по тегам на карте или воспользоваться умным фильтром.

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

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

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

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

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

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

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

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

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

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

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

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

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

Основной источник дохода приложения — реферальные соглашения с продуктами, заинтересованными в тревел трафике (Booking и другие).

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

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

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

В конце, мы тезисно дополнили нашу презентацию краткими идеями, которые мы не успели реализовать, но тоже считали полезными)

Спасибо всем, кто прочитал этот немаленький текст!Надеюсь, он будет хоть кому-то полезен)

Это моя первая статья на Medium, так что не судите строго 🙃Вместе мы сделаем мир лучше! 🙌