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

Таким процессом является «Двойной Бриллиант». Дизайн процесс Двойного бриллианта проектирования состоит из четырех фаз:

  1. Исследование (Discover)
  2. Определение проблемы (Define)
  3. Разработка решения (Develop)
  4. Внедрение (Deliver)

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

Таким образом на первой фазе «Исследования» вы максимально широко пытаетесь изучить проблемы.

На этапе «Определения проблемы» вы ищите ту единую самую важную проблему на которой хотите сосредоточиться и сужаете концентрацию на нее (не распыляетесь).

На третьем этапе «Разработка решения» вы вновь становитесь открытыми и смотрите широкого на все возможные решения вашей проблемы.

На последнем этапе «Внедрение» ваша задача выбрать лучшее решение и внедрить его в жизнь.

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

Я рассмотрю все этапы по порядку.

Этап 1. Исследование (Discover)

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

Методы проведения исследований:

  • Воркшопы
  • Пользовательское исследование
  • Анализ конкурентов

Проведение воркшопов

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

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

Матрица предположений

Это специальная матрица в 4 части которая определят степень важности гипотезы для валидации. Все стартовые идеи и гипотезы накидываются в эту матрицу и расставляется приоритетность.

Воркшоп по персонам

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

Воркшоп по пользовательскому пути

Это микроисследование помогает понять как пользователи навигируются в продукте или сервисе.

Воркшоп по ценовому предложению

Проектируем предположительную ценность продукта для пользователя. Это позволяет определить общее видение для продукта

Бренд видение, Миссия и Ценности

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

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

Пользовательские исследования

Есть множество «методов» исследования для этого этапа. Самым простым считается кабинетное исследование. Его можно провести имея только компьютер с интернетом.

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

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

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

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

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

Анализ конкурентов

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

Полевое исследование

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

Этап 2. Определение проблемы (Define)

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

Существуют уже опробованные миром методики обработки информации:

  1. Метод юзер персон
  2. Jobs to be done (JTBD)
  3. Как мы бы могли

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

Кратко об этих методах:

Метод юзер персон

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

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

Как составить портрет пользователя?

  • Найдите реальное фото клиента
  • Дайте ему имя и работу
  • Дайте ему возраст и семейное положение
  • Опишите его мотивы и цели
  • Опишите его проблемы и барьеры
  • Добавьте как он решает свои проблемы сейчас
  • Укажите какими устройствами он пользуется (для цифровых продуктов это супер важно)

Про демографические данные в User Persona

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

Метод Jobs to be Done

В отличие от Юзер персон, JTBD ориентирован не на характер пользователей, а на цели которые они преследуют. Этот метод отлично работает в паре с Юзер персоной, поэтому одно не исключает другое. Подробнее было в этой статье: Jobs To Be Done — что это за зверь?

Jobs to be done делает человека лучше

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

Как мы можем?

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

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

Далее попробуйте задавать вопросы, которые будут развивать ваше воображение:

  • Как мы можем…?
  • Что нас останавливает?
  • Каким образом мы могли бы…?
  • Что произойдет если…?
  • Другие вопросы в подобном духе

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

В конце этапа «Определения проблемы» у нас должна оказаться на руках следующая информация:

  • Потрет пользователя
  • Работы которые он выполняет с помощью нашего продукта
  • Инсайты
  • Сгенерированные идеи, как мы будем пользователю помогать

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

Этап 3. Разработка решения.

Генерация решений, определение и приоритезация функциональности

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

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

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

Карта пути пользователя (Customer Journey Map)

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

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

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

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

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

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

Как составить пользовательский путь?

  1. Выделите основные задачи и цели, которые решает ваш продукт. Пользовательский путь должен иметь конкретную задачу, мотивацию и контекст.
  2. Пропишите каждое действие, которое совершает пользователь на пути к поставленной цели.
  3. Добавьте описание эмоций, которые переживает пользователь на каждом этапе. Эту информацию лучше брать с реальных исследований, а не придумывать.  Визуализация может быть в форме текста или эмоджи, как вам удобнее.
  4. Учитывайте, что для достижения целей пользователь может пойти разными путями. Составьте альтернативный путь, но не усложняйте. Вам нужно выделить самые популярные пути.

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

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

Пример составления пользовательской истории выглядит примерно так:

Пример из жизни:

Я как руководитель отдела продаж хочу делать больше продаж ежемесячно, чтобы увеличить прибыль

Другой вариант того же утверждения:

Я как руководитель отдела продаж хочу контролировать статус сделок моих подчиненных, чтобы уменьшить количество потерянных сделок и увеличить прибыль

Построение информационной архитектуры(IA)

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

Самым популярным методом для валидации при создании архитектуры нового продукта является карточная сортировка.

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

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

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

Наброски

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

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

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

Этап 4. Передача. Подготовка макетов и прототипов

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

  1. Прототип в низком разрешении
  2. Прототип в высоком разрешении
  3. Подготовка к передаче на технический отдел

Низкоуровневый прототип

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

Инструменты:

  • Figma/Sketch для макетов
  • Figma/InVision/Marvel/Axure для подготовки кликабельного прототипа

Что нужно учитывать при подготовке чернового макета:

  1. Не используйте рыбные тексты. Они сбивают с толку и не дают понять контекст. Лучше сразу думать о UX-копирайтинге, т.к. он играет ключевую роль в понятности продукта.
  2. Используйте более менее стандартные паттерны UI. Они проверены годами.
  3. Готовьте макеты в первую очередь под мобильный. Это не просто фраза из книг. Согласно аналитике нескольких последних проектов есть действительно огромный сдвиг в сторону мобильного трафика, когда из 100% посетителей сайта 80% приходят с мобильных устройств. Это норма.
  4. Тестируйте прототип на людях, и вносите изменения после юзер-тестов. Ведь именно для этого вы их и делали. Как правило хватает 5-10 юзер-тестов, чтобы увидеть 80% проблем в навигации.

Высокоуровневый прототип

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

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

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

Подготовка к передаче

На этом этапе вам требуется подготовить макеты к передаче разработчикам. Для этого нужно предусмотреть что:

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

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

И самое важное в любом дизайн процессе

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