Как стать автором
Обновить
0
iSpring
Платформа для онлайн-обучения

Как UX/UI-дизайнеру достичь взаимопонимания с разработчиками и проджектами: комбинируем UX-фреймворки

Время на прочтение 6 мин
Количество просмотров 6.4K

В самом начале своего пути на позиции UX/UI-дизайнера, я воспринимал защиту дизайна каждой фичи перед разработчиками и проджектами как битву. Мой внутренний “адвокат пользователя” всегда пытался внедрить в продукт максимальное количество удобных функций, а проджект-менеджер с разработчиками старались отпилить все лишнее, чтобы побыстрее зарелизить продукт или обновление. 

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

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

Инструмент для создания сильного продуктового решения: матрица DFV от консалтингового агентства IDEO
Инструмент для создания сильного продуктового решения: матрица DFV от консалтингового агентства IDEO

За каждый из этих аспектов продуктового решения отвечает отдельный специалист или команда: 

  • Продуктовый дизайнер отвечает за удобство для пользователя

  • Разработка отвечает за техническую реализацию

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

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

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

Как дизайнеры общаются между собой: Customer Journey Map (CJM)

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

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

На этом примере мы будем рассматривать все фреймворки, описанные в этой статье — поэтому рекомендую изучить картинку подробнее.

Пример заполненного CJM для приложения по электронному обучению
Пример заполненного CJM для приложения по электронному обучению

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

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

Как дизайнеры общаются с разработчиками: Service blueprint

Service blueprint (карта сервисного сценария) — это еще один фреймворк, который также описывает путь пользователя. Только в отличие от CJM, описание пути пользователя происходит не со стороны пользовательского опыта, а с точки зрения взаимодействия пользователя и системы. 

Пример заполненного Service blueprint для приложения по электронному обучению
Пример заполненного Service blueprint для приложения по электронному обучению

Базовый Service blueprint состоит из двух разделов: “на сцене” и “за кулисами”.  

  1. В разделе “на сцене” располагаются элементы, которые видит пользователь:

    1. Путь пользователя — это шаги пользователя, как в CJM

    2. Механики и интерфейсы — элементы сервиса (системы), с которыми напрямую взаимодействует пользователь

  2. В разделе “за кулисами” отображаются бизнес-процессы, с которыми пользователь не взаимодействует напрямую, но которые поддерживают выполнение пути пользователя.

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

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

Если убрать из бизнес-процессов процесс обработки домашних заданий, сценарий будет разорван и пользователь не сможет достичь своей цели
Если убрать из бизнес-процессов процесс обработки домашних заданий, сценарий будет разорван и пользователь не сможет достичь своей цели

В чем польза этого фреймворка для дизайнеров и разработчиков? 

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

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

Как общаются UX/UI-дизайнеры, разработчики и проджекты: Service blueprint + Кано

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

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

Глобально используется два подхода для разделения фичи на MVP: 

  1. Идти от системы  — то есть разделять фичи на такие MVP, которые логичнее реализовать с технической стороны  

  2. Идти от пользователя — то есть внедрять сначала тот функционал, который пользователю нужнее

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

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

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

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

В рамках модели Кано мы делим элементы фичи по важности для пользователя на 5 категорий: 

  • Безусловные (красные): без которых сервис фактически не будет работать

  • Линейные (желтые): наличие которых прямо пропорционально удовлетворенности пользователей

  • Привлекательные (голубые): элементы фичи, которых пользователь не ожидает, но будет приятно удивлен их увидеть

  • Безразличные (серые): что есть, что нет — пользователю безразлично

  • Нежелательные (фиолетовые): лучше бы их не было

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

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

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

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

Пример заполненного Service blueprint с приоритизацией по модели Кано для приложения по электронному обучению
Пример заполненного Service blueprint с приоритизацией по модели Кано для приложения по электронному обучению

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

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

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

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

Удачи в ваших проектах!

Теги:
Хабы:
+6
Комментарии 8
Комментарии Комментарии 8

Публикации

Информация

Сайт
www.ispring.ru
Дата регистрации
Дата основания
2001
Численность
201–500 человек
Местоположение
Россия
Представитель
Илья Шихалеев

Истории