В самом начале своего пути на позиции UX/UI-дизайнера, я воспринимал защиту дизайна каждой фичи перед разработчиками и проджектами как битву. Мой внутренний “адвокат пользователя” всегда пытался внедрить в продукт максимальное количество удобных функций, а проджект-менеджер с разработчиками старались отпилить все лишнее, чтобы побыстрее зарелизить продукт или обновление.  Для меня было загадкой, зачем урезать удобный для пользователя функционал? Я был молод, и не понимал как построен весь продуктовый процесс целиком.  А продуктовый процесс строится вокруг создания сильного продуктового решения: то есть такого решения, которое будет удобно пользователю, технически реализуемо и экономически выгодно.  За каждый из этих аспектов продуктового решения отвечает отдельный специалист или команда:  Продуктовый дизайнер отвечает за удобство для пользователя Разработка отвечает за техническую реализацию Продакты и проджекты отвечают за экономическую целесообразность.  Загвоздка в том, что у дизайнеров, разработчиков и проджектов — свои фреймворки, которые они используют для поиска сильного решения. Проще говоря, все эти специалисты разговаривают на разных языках.  Сейчас мы рассмотрим фреймворки, которые мы используем в iSpring, чтобы добиться взаимопонимания между всеми участниками процесса работы над продуктом. При анализе существующего или проектировании нового сервиса, большинство дизайнеров используют фреймворк CJM (карта пути пользователя). Этот инструмент позволяет увидеть и проанализировать существующий или новый путь пользователя.  На картинке ниже вы видите пример заполненного CJM. Это карта пути пользователя в мобильном приложении для электронного обучения. На карте описан сценарий прохождения курса студентом: от получения уведомления о появлении нового курса и до получения оценки за домашнюю работу по курсу. На этом примере мы будем рассматривать все фреймворки, описанные в этой статье — поэтому рекомендую изучить картинку подробнее. Базовый CJM строится вокруг пользователя, который идет по некоему сценарию, состоящему из ряда конкретных шагов. Каждому шагу соответствуют определенные боли, с которыми сталкивается клиент при решении своей задачи, и возможности, которыми мы можем эти боли закрыть. CJM — это гибкий инструмент, который можно расширить дополнениями, поэтому в интернете есть так много вариаций CJM.  Одно из главных ограничений фреймворка CJM в том, что он описывает только сам путь пользователя, но не техническую реализацию этого пути — поэтому для общения с разработчиками он малоэффективен. Service blueprint (карта сервисного сценария) — это еще один фреймворк, который также описывает путь пользователя. Только в отличие от CJM, описание пути пользователя происходит не со стороны пользовательского опыта, а с точки зрения взаимодействия пользователя и системы.  Базовый Service blueprint состоит из двух разделов: “на сцене” и “за кулисами”.   В разделе “на сцене” располагаются элементы, которые видит пользователь: Путь пользователя — это шаги пользователя, как в CJM Механики и интерфейсы — элементы сервиса (системы), с которыми напрямую взаимодействует пользователь В разделе “за кулисами” отображаются бизнес-процессы, с которыми пользователь не взаимодействует напрямую, но которые поддерживают выполнение пути пользователя. С такой картой уже можно продуктивно общаться с разработчиками, потому что на карте сразу видно, как работает система в целом и без чего она точно работать не будет.  Рассмотрим на примере нашего приложения для электронного обучения. Мы видим, что если убрать из закулисья процесс обработки домашних заданий, то пользователь в принципе не сможет сдать задание, а значит — сценарий будет разорван и пользователь не достигнет своей цели.  В чем польза этого фреймворка для дизайнеров и разработчиков?  При разработке фичей разработчики часто стремятся максимально оптимизировать процесс и отпилить то, что считают ненужным. Фреймворк Service blueprint помогает им не отпилить что-то важное, из-за чего сценарий будет разорван.  Дизайнеры, наоборот, стараются внедрить как можно больше удобных функций для пользователя. В нашем примере дизайнер предусмотрел 5 типов уведомлений, чтобы пользователь точно не пропустил новый курс: push-уведомление, письмо на почту и т.п. Разработка скорее всего предложит оптимизировать этот этап и реализовать в рамках MVP два типа уведомлений, а не пять. На карте дизайнер видит, что шаг не разрывается, поскольку на этом этапе у нас остаются еще два элемента, а значит, в рамках в MVP можно отказаться от дополнительных уведомлений. Когда мы уже нашли общий язык с разработчиками и сошлись во мнении, какие элементы фичи оставляем, а какие — выпиливаем, приходит проджект-менеджер и говорит, что фичу нужно зарелизить не через год, а через квартал.  И тут — хочешь или нет — придется разделять фичу на MVP-шки (минимально жизнеспособные версии), чтобы начать как можно быстрее решать задачи пользователей и отгружать ценность. Глобально используется два подхода для разделения фичи на MVP:  Идти от системы  — то есть разделять фичи на такие MVP, которые логичнее реализовать с технической стороны   Идти от пользователя — то есть внедрять сначала тот функционал, который пользователю нужнее С точки зрения развития сервиса, оба подхода имеют право на жизнь, но мы в iSpring придерживаемся философии HCD (человеко-центричного дизайна) и поэтому выбор очевиден: при разделении на MVP идем от пользователя.  В таком случае, нам важно понять, какие элементы фичи несут наибольшую ценность для пользователя — и расставить приоритеты по выпуску. Есть множество методологий для приоритизации фичей: коэффициенты RICE или ICE, карты историй, взвешенные оценки и др. Эти инструменты подходят для сравнения цельных фичей между собой, но не подходят, когда мы оцениваем элементы одной фичи, которые влияют друг на друга.  А в нашем случае необходим простой фреймворк, который покажет отношение пользователей к определенному элементу фичи. Под эту задачу отлично подходит модель Кано, которая за счет своей элементарной структуры здорово упрощает принятие решений и хорошо интегрируется с другими фреймворками.  В рамках модели Кано мы делим элементы фичи по важности для пользователя на 5 категорий:  Безусловные (красные): без которых сервис фактически не будет работать Линейные (желтые): наличие которых прямо пропорционально удовлетворенности пользователей Привлекательные (голубые): элементы фичи, которых пользователь не ожидает, но будет приятно удивлен их увидеть Безразличные (серые): что есть, что нет — пользователю безразлично Нежелательные (фиолетовые): лучше бы их не было Распределить функционал по этим категориям можно на основании пользовательских исследований. Обычно при проведении пользовательских интервью, я задаю такие вопросы, чтобы по итогу исследования можно было сразу построить эту модель.  Если интересно узнать подробнее, как я готовлюсь к пользовательским интервью, отпишись в комментариях — и я напишу об этом отдельную статью. Итак, рассмотрим на нашем примере. После того, как мы распределили элементы нашей фичи по категориям, берем Service blueprint и начинаем окрашивать элементы закулисья, механик и интерфейсов в цвета соответствующие приоритизации по модели Кано.  Как видите, мы нанесли на карту не только красные элементы фичи, но и желтые, и даже голубые. В принципе, в первую MVP-шку можно внести только красные фичи — и сервис уже будет в каком-то виде решать задачи пользователя.  Однако желтые фичи также полезны, потому что напрямую влияют на удовлетворенность пользователя и делают наш сервис лучше, а голубые (привлекательные фичи) помогают сервису выделиться на фоне конкурентов. Не стоит на них забивать 😉 По итогу, мы имеем на руках инструмент, с помощью которого дизайнеры, проджекты и разработчики могут говорить на одном языке и принимать решения о последовательном развитии сервиса.  Если вам понравилась статья и не терпится начать применять этот подход в работе, вот ссылка на шаблон в фигме Удачи в ваших проектах! UX/UI-дизайнер