Привет! Меня зовут Настя, я UX-дизайнер внутренних сервисов в Лемана ПРО (Леруа Мерлен). Мы с командой создаем чертовски сложный внутренний продукт, и нам критически важно, чтобы сервисы и разделы в нем были понятны коллегам и удобны в использовании.
Поэтому исследования ради исследований нам не нужны. Нужно понимать, какие данные помогут что-то улучшить и, возможно, даже сделать рывок или скачок, а какие ни к чему не приведут, а ресурсы компании будут потрачены впустую.
Сегодня расскажу про наши процессы, а также про исследования и инструменты, которые помогают проектировать продукт.
О продукте
TechGate — портал отдела Технологии, в котором продуктовые команды могут отслеживать и управлять развернутыми ресурсами, заказывать техническую обвязку для своего продукта, начиная с баз данных и заканчивая гибридным облаком. Я работаю над этим продуктом более двух лет, и число приходящих в него внутренних пользователей постоянно растет.
Условно TechGate делится на 3 части:
Каталог сервисов, где большая часть функционала — это конфигураторы различной сложности, посредством которых пользователи могут самостоятельно развернуть необходимую для их продукта инфраструктуру. Например, конфигураторы для сервисов DevOps, DBaaS, YandexCloud, OpenStack, конфигураторы активностей поддержки, работы с микрофронтэндами и т. д. Еще в этот раздел входят сводные таблицы, общие страницы, где можно просмотреть информацию по своим запросам, калькуляторы и входные точки на другие сервисы.
Раздел аналитики, а также FinOps — масса таблиц и сводной информации, необходимой командам для бюджетирования и отслеживания своих расходов и затрат.
Раздел с информацией для команд по более чем 800 продуктам. В нем можно узнать, что входит в продукт, какие сервисы подключены, какие ресурсы и связи имеются, а также посмотреть, какие оптимизации портал предлагает. Плюс в карточке отображается, какой углеродный след у продукта.
Наш продукт внутренний, сложный. Пользователь должен обладать определенным набором характеристик и навыков. Это не тот случай, когда разбираться в интерфейсе должна даже бабушка. Это история про управление самолетом, когда без определенных умений не полетишь. Есть сложности и условия, которые нельзя не учитывать.
Как мы создаем и проектируем решения
Работаем осознанно, опираясь на данные, полученные в ходе использования различных инструментов.
Ниже я постараюсь расписать процесс, как мы выстраиваем работу и что происходит дальше,
поделюсь своим практическим опытом. Какие фокусы учитываю для эффективного формирования минимального набора методов и инструментов, которые помогают проходить итерационный цикл при проектировании решений в работе над задачами. А также расскажу, как работаю с полученными данными.
О чем пойдет речь:
Сложности и спецификации продукта, «коридор ограничений».
Целевая аудитория и инструменты, которые используем, чтобы быть гибкими.
Конкурентный анализ, как его собрать для внутренних продуктов.
Работа с полученными данными: инструменты и примеры организации процесса.
Некоторые сложности при проектировании и инструменты для решения
При проектировании сложных, нагруженных решений есть проблемы:
часто это закрытые системы с ограниченным доступом;
необходимо разрабатывать решение под наши бизнес-требования, невозможно полноценно использовать уже существующие решения, представленные на рынке;
ограниченное количество методов и инструментов для сбора информации.
Эти сложности можно решить при помощи нескольких инструментов.
Иногда достаточно просто оцифровать что-то существующее, избавив специалистов от рутинной работы. В нашем продукте это части, связанные с конфигураторами и отображением на фронте информации, для поиска которых раньше требовалось потратить несколько дней.
Иногда нужно что-то доработать с учетом уже имеющегося. Например, доработка «коробочных решений», интеграции с системами, на которые мы не можем повлиять.
Иногда нужно спроектировать что-то новое, но нет четкого представления о том, что должно быть. В этом случае мы опираемся на результаты изучения целевой аудитории (ЦА), потребностей, «болей».
Как мы изучали целевую аудиторию, какие инструменты использовали
У нашего продукта интересная и сложносегментированная целевая аудитория.
Сразу прослеживалось полярное деление пользователей на две группы: «могу рассказать, как нужно сделать и почему, как можно оптимизировать и какую фичу добавить, что за этим может последовать» и тех, кто мало погружен в предметный контекст, ни разу не сталкивался с нашими инструментами, не владеет специфичной терминологией и не понимает, какие возможности мы предлагаем.
Еще одну часть ЦА составляют пользователи, которых надо учить работать с имеющимися возможностями. Это еще не эксперты, но и не новички. Они приходят на портал, чтобы закрыть свои потребности: заказать ресурсы для продуктовой команды, добавить администраторов, получить поддержку продукта и сопровождение продуктовой команды линией поддержки.
Забегая вперед: впоследствии эти группы мы разделили по потребностям — ввели разделы, разграничили функциональность, добавили подсказки.
Наша цель — изучить потребности и сделать так, чтобы все сегменты нашей ЦА успешно справились со своей задачей.
Чтобы полноценно проанализировать целевую аудиторию, мы использовали различные методы исследований. По опред��ленным причинам трудно набрать достаточное количество респондентов на количественные исследования, поэтому в основном проводили качественные. А с ними не все так однозначно, потому что пользователи имеют разный опыт взаимодействия с продуктом.
В итоге мы использовали опросы, наблюдения и серии интервью. Опросами сегментировали нашу ЦА и выявили тех, кто знал о нас — был опыт взаимодействия, а также тех, кто являлся нашим потенциальным пользователем, но еще к нам не пришел. Наблюдением определили проблемные места продукта и то, как различные роли взаимодействуют с возможностями продукта. Также были проведены серии интервью, о них расскажу подробнее.
Мы проводим много интервью, работаем с обратной связью и обращениями в поддержку, стараемся услышать и понять пользователя. А затем стремимся наложить решение его «боли» и его пожелания на реальность бизнес-процесса и технических ограничений, получив таким образом лучший продукт.
Экспертное интервью помогает собрать и обработать информацию для проектирования решений на основании экспертного мнения. После чего прототипы, промежуточные решения мы тестируем на нашей целевой аудитории. При этом фокус не всегда нацелен на экспертов, с которыми проводили интервью. Фактически получается, что эксперты проверяют, правильно ли мы поняли процесс и технические особенности. А от остального сегмента пользователей получаем, выявляем «боли» и проблемные места, которые касаются пользовательского взаимодействия с интерфейсами.
Процесс проходит циклично в несколько итераций, пока не получаем оптимальное решение.
По технике проведения экспертное интервью ничем не отличается от обычного:
Задаем цель исследованию — зачем нам нужно интервью?
Определяем целевую аудиторию — ставим задачи исследования.
Формируем структуру интервью с несколькими ветками возможных ответов. Ветки возможных ответов — что-то вроде плана «Б» на случай, если пользователь на какой-то вопрос ответит не так, как мы ожидали. Нужно не растеряться, а все равно уточнить у него детали и продолжать интервью.
Собираем необходимые атрибуты к проведению исследования. Определяем формат (онлайн или офлайн), подготавливаем список респондентов, составляем адженду встречи. Если на интервью необходимо присутствие еще одного специалиста, договариваемся об этом. Проверяем технику, ссылки, доступы и т. п.
Проводим интервью. У меня на практике сложилось, что это совмещение направленного и неориентированного типов интервью.
Можно сказать, что изучение ЦА не прекращается. Мы регулярно смотрим, как растет и меняется аудитория, насколько она удовлетворена взаимодействием с нашим функционалом. Делаем это через поддержку, входящие запросы на обогащение и развитие портала, опросы по SCAT, собираем различные метрики. Полученные данные и выводы мы сверяем раз в полгода — это помогает определить, насколько мы можем измениться и как помочь пользователю. Впоследствии разрабатываемые решения, корректируем и улучшаем.
Как мы знакомились с конкурентами и проводили сравнительный анализ
Необходимо четко понимать, кто и в какой степени является конкурентом, а кто не является. Это нужно, чтобы найти ключевые показатели конкурентов и сравнивать их со своими, идти в ногу со временем, проработать точки роста, быть более удобными и привлекательными для внутренней работы и поддержки продуктовых команд.
Первая сложность носит общий характер: определить критерии, по которым будет проходить анализ. Нужно понимать «атрибуты конкурентности», их достаточность и влияние, агрессивность и потенциальность.
Вторая сложность заключается в том, что информация о похожих продуктах закрыта. Найти прямых конкурентов или приближенный референс очень непросто. Мало того, что необходимо найти что-то похожее, так еще нужно и соотнести, насколько этот похожий продукт нам «конкурент». Бывало, что при сопоставлении атрибутов похожий продукт конкурентом не являлся.
Фактически нам нужно сопоставить «решение первой сложности» с «решением второй сложности» и определить на основании выделенных параметров и атрибутов, является ли схожий продукт нам конкурентом или нет.
Получить ответ на вопрос «а как же там у конкурентов?» можно несколькими путями:
из статей или видео, которые публикуют сами конкуренты;
из записей демо, на очных закрытых встречах, где компании, которые продают свой продукт, могут о нем рассказать;
из пробных версий, если таковые имеются;
из личного общения: нетворкинг в помощь.
Для анализа конкурентов мы собирали информацию всеми этими способами. Плюс искали технологические порталы, которые условно можно назвать аналогами, и смотрели не на весь продукт как на конкурента, а на его части, функциональные блоки.
Поэтому часто конкурентный анализ мы проводим не «продукт к продукту», а «функция к функции». Мы постоянно следим за рынком и его развитием, на основании чего выявляем у себя потребность, инициируем новые исследования и обогащаем наш бэклог.
Я рассказала про сложности. Но у нас есть и неоспоримое преимущество: поскольку потребитель внутренней системы не уйдет к конкуренту, мы, по сути, являемся монополистами. Это позволяет делать клиентоориентированный продукт в собственном темпе, без погони за рынком.
Как я работаю с полученными данными: инструменты и примеры организации процесса
При формировании предложений по решению проблем пользователей и бизнеса, при работе над задачами применяю методы исследования, инструменты бизнес-ТРИЗ, комбинирую некоторые из них в зависимости от входящих условий.
Важно уметь не только получить данные, но еще и корректно их обработать.
Всю информацию — референсы, скрины систем, итоги интервью, обратную связь от команд — собираю на доске Miro, затем обрабатываю и формирую результаты. Кстати, добывать и приносить информацию могут участники разных команд — чем больше вводных данных, тем лучше.
Затем я анализирую, синтезир��ю и составляю необходимые под конкретную цель артефакты. Для этого использую различные инструменты для работы с данными: Affinity map (Affinity Diagram), User Story, CJM, JTBD, несколько раз составляла Value Proposition, для последующей работы и приоритизации — фреймворк RICE и Метод MoSCoW, а также бинарную приоритизацию.
Например, я провожу текстовое кодирование интервью и формирую Affinity map, то есть представляю полученную информацию в виде смысловых блоков. В таком представлении можно наглядно увидеть групповые срезы по темам, а в них — количество по соотношению проблем и предложений. Более того, после текстового кодирования и обработки информации, она открепляется от личности респондента и происходит анализ только полученной информации.
Как это выглядит. Я переношу информацию относительно групп на стикеры, параллельно распределяя ее на три смысловых блока: розовый — «проблемы», желтый — «нейтральность», зеленый — «предложения». Название групп на синих стикерах.
Блоки формируются по тематическим/смысловым группам, которые я самостоятельно задаю в зависимости от цели и задач интервью или смыслового контекста продукта. Получается своего рода сегментация, где можно быстро просмотреть количество триггеров в каком-то из сегментов, увидеть проблемы и предложения.
Интересное наблюдение: если респонденты после интервью видят, что их «боль» отработана, к следующим интервью они готовятся лучше, заранее формулируют их описание и четкие предложения.
Несколько раз я совмещала совместное проектирование и экспертное интервью, когда респонденты во время общения сами передвигают элементы интерфейса и комментируют свои действия. Это помогает понять, как эксперт или пользователь представляет вложенность объектов и иерархию взаимосвязей.
Кроме того, бывает полезно совместить оценку предпочтений и полевые исследования. Если во время наблюдений удается выявить закономерность, в следующих итерациях, часть времени интервью я выделяю на оценку решений, которые могут улучшить продукт, исходя из этой закономерности. То есть следующие респонденты не просто проходят путь в интерфейсе, но еще и оценивают предложенные варианты его прохождения.
Самое важное
Нужно понимать, что не стоит проводить всевозможные исследования и применять все существующие методы анализа данных одновременно. Ни одному бизнесу не нужно исследование ради исследования, это целенаправленная работа, которая требует немало времени и ресурсов.
Наибольшую ценность несут качественные выводы — именно они позволяют понять, что теперь необходимо делать, сформировать картину продукта/проекта/задачи, выявить существующие ограничения.
Независимо от объемов и сложности входящей задачи, ее всегда можно декомпозировать, или разбить на части. Итерационный путь позволяет избежать неподъемных исследований, выделить из них часть и остаться в рамках продукта или проекта.
А на этом все, до встречи в следующих постах!
