Привет! Меня зовут Настя, я UX-дизайнер внутренних сервисов в Лемана ПРО (Леруа Мерлен). Мы с командой создаем чертовски сложный внутренний продукт, и нам критически важно, чтобы сервисы и разделы в нем были понятны коллегам и удобны в использовании.

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

Сегодня расскажу про наши процессы, а также про исследования и инструменты, которые помогают проектировать продукт.

О продукте

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

Условно TechGate делится на 3 части:

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

• Раздел аналитики, а также FinOps — масса таблиц и сводной информации, необходимой командам для бюджетирования и отслеживания своих расходов и затрат. 

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

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

Как мы создаем и проектируем решения

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

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

О чем пойдет речь:

1. Сложности и спецификации продукта, «коридор ограничений».

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

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

4. Работа с полученными данными: инструменты и примеры организации процесса.

Некоторые сложности при проектировании и инструменты для решения

При проектировании сложных, нагруженных решений есть проблемы:

• часто это закрытые системы с ограниченным доступом;

• необходимо разрабатывать решение под наши бизнес-требования, невозможно полноценно использовать уже существующие решения, представленные на рынке;

• ограниченное количество методов и инструментов для сбора информации.

Эти сложности можно решить при помощи нескольких инструментов.

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

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

Иногда нужно спроектировать что-то новое, но нет четкого представления о том, что должно быть. В этом случае мы опираемся на результаты изучения целевой аудитории (ЦА), потребностей, «болей».

Как мы изучали целевую аудиторию, какие инструменты использовали

У нашего продукта интересная и сложносегментированная целевая аудитория. 

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

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

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

Наша цель — изучить потребности и сделать так, чтобы все сегменты нашей ЦА успешно справились со своей задачей. 

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

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

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

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

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

По технике проведения экспертное интервью ничем не отличается от обычного:

1. Задаем цель исследованию — зачем нам нужно интервью?

2. Определяем целевую аудиторию — ставим задачи исследования.

3. Формируем структуру интервью с несколькими ветками возможных ответов. Ветки возможных ответов — что-то вроде плана «Б» на случай, если пользователь на какой-то вопрос ответит не так, как мы ожидали. Нужно не растеряться, а все равно уточнить у него детали и продолжать интервью.

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

5. Проводим интервью. У меня на практике сложилось, что это совмещение направленного и неориентированного типов интервью.

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

Как мы знакомились с конкурентами и проводили сравнительный анализ

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

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

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

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

Получить ответ на вопрос «а как же там у конкурентов?» можно несколькими путями:

• из статей или видео, которые публикуют сами конкуренты;

• из записей демо, на очных закрытых встречах, где компании, которые продают свой продукт, могут о нем рассказать;

• из пробных версий, если таковые имеются;

• из личного общения: нетворкинг в помощь.

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

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

Как я работаю с полученными данными: инструменты и примеры организации процесса

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

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

Затем я анализирую, синтезирую и составляю необходимые под конкретную цель артефакты. Для этого использую различные инструменты для работы с данными: Affinity map (Affinity Diagram), User Story, CJM, JTBD, несколько раз составляла Value Proposition, для последующей работы и приоритизации — фреймворк RICE и Метод MoSCoW, а также бинарную приоритизацию.

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

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

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

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

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

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

Самое важное

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

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

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

А на этом все, до встречи в следующих постах!