Как разработать UIKit для сети гипермаркетов. Часть вторая

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

Алгоритм действий такой же, как и при изучении действующей:

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

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

Получилось 11 популярных целей. Включили в пути их достижения важные задачи, которые набрали мало баллов за незнанием пользователя или уникальностью. Возможно путь «Купить товары по рецепту от “Глобус” с доставкой на дом» в реальной жизни и редкое явление, но зато мы прорабатываем и рецепты и доставку.

В дорожной карте указано, что мы действуем классическим методом персон. Выделяем группы пользователей, анализируем сценарии решения задач для каждой группы. Например, Иван, 23 года, переехал учиться в новый город, рядом с его домом в одном из спальных районов есть гипермаркет сети «Глобус». Мария, 33 года, двое детей, работает бухгалтером, ездит за покупками раз в неделю. Но на практике проанализировать все возможные группы пользователей нереально. Аудитория «Глобус» слишком велика и разнородна.

Поэтому мы строили и анализировали пути CJM (Customer Journey Map, карта путей пользователя) на основе метода Jobs-To-Be-Done. Фокус на целях пользователя в определенных обстоятельствах. Первым делом для составления CJM проработаны юзер-кейсы. Аналитик на основе своего опыта, директив от бизнеса и пользователей сформировал полноценные пути для достижения каждой из 11 целей. Предусмотрены точки касания бренда с клиентом после совершения целевого действия. Например, оставить отзыв, составить маршрут по магазину, подписаться на рассылку, посмотреть персональные предложения.

Давайте разберем на примере одной из 11 карт, как это работает.

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

Колонки — этапы решения задачи. Начало пути — возникновение потребности. Конец пути — удовлетворение потребности.

Первая строка — действия пользователя. «На globus.ru ввести название товара в строке поиска», «Перейти на страницу результатов» и так далее. Действия, которые пользователь совершает для решения задачи и действия выгодные гипермаркету. Пусть он кроме знакомства с рецептом оставит отзыв или купит для него ингредиенты. Цель интерфейса — продлить контакт с пользователем.

Вторая строчка — перечисление точек контакта. На какой странице, кнопке на данном этапе находится пользователь.

Третья строка — барьеры текущей системы. Что может затормозить пользователя на пути к цели.

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

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

Шестая строка — скриншоты барьеров. Опущены вниз для удобства восприятия.

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

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

Чеклист мы отправили «Глобус». Требовалось проставить статус к каждой рекомендации: да, нет, обсудить, воздержался. Матрица стала основой для проектировщика — структурированный перечень элементов, функций интерфейсов и отдельных элементов UIKit.

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

Так как наша цель — UI Kit, мы выбрали 10 наиболее сложных, насыщенных интерфейсов для прототипа.

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

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

10 проверенных прототипов интерфейсов ушли к дизайнеру. Он проработал новую визуальную оболочку интерфейсов.

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

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

Как мы формируем UIKit «Глобус»:

Компоненты-атомы, которые невозможно поделить на более мелкие составляющие. Это неизменный базис для дизайна:

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

Компоненты UIKit разделены на блоки:

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

Созданный UIKit достиг своей цели — рассказать и показать «Глобус», как правильно и единообразно представлять свой бренд в вебе. На каждый вопрос «А как сделать карточку нового товара?» «А как сделать баннер?» «А какой отступ нужен между блоками?» можно найти ответ в гайде.

Разработка новых интерфейсов или их элементов на основе UIKit требует от нас минимум времени. Макеты дизайна от других авторов будут проходить проверку на прочность. Мы верифицируем их с UIKit. В случае несоответствия, «Глобус» будут принимать решение менять макет или правила в UIKit.

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