На занятии мы разберём, что происходит после проведения пользовательских интервью. На этапе исследования команда получает много отдельных высказываний: кто-то жалуется на сложность, кто-то рассказывает о привычках, кто-то описывает конкретную ситуацию, а кто-то противоречит другим респондентам.
Сами по себе эти ответы ещё не являются исследовательским результатом.
Задача UX-исследователя или продуктового дизайнера — превратить набор разрозненных наблюдений в понятную систему: увидеть повторяющиеся паттерны, понять причины поведения пользователей, сформулировать инсайты и определить области, в которых продукт может создать дополнительную ценность.
Результатом занятия станет карта инсайтов аудитории, в которой пользовательские цитаты будут связаны с паттернами поведения, болями, мотивами, барьерами и потенциальными направлениями развития продукта.
2. Вводная часть
Представим, что команда провела восемь глубинных интервью.
Каждое интервью длилось около часа. После исследования у команды осталось:
— восемь расшифровок;
— несколько десятков страниц текста;
— сотни отдельных высказываний;
— заметки исследователя;
— интересные цитаты;
— наблюдения о поведении пользователей.
Возникает проблема.
Что со всем этим делать?
Очень распространённая ошибка начинающих исследователей — закончить анализ на уровне пересказа интервью:
«Пользователь №1 сказал это. Пользователь №2 сказал другое. Пользователь №3 хотел бы такую функцию».
Такой материал трудно использовать продуктовой команде. Разработчику, дизайнеру или менеджеру всё равно приходится самостоятельно читать десятки страниц и пытаться понять, что из этого действительно важно.
Поэтому после сбора пользовательских данных начинается второй этап — синтез данных.
Синтез отвечает не на вопрос:
«Что сказал каждый пользователь?»
а на вопрос:
«Какие закономерности мы видим в поведении аудитории и что они означают для продукта?»
Именно на этом этапе исследовательские данные превращаются в знания, которые можно использовать при проектировании продукта.
3. Основная идея темы
Главная мысль сегодняшней лекции:
Инсайт нельзя придумать. Его нужно вывести из пользовательских данных.
Между интервью и продуктовым решением должна существовать логическая цепочка:
Ответы пользователей → наблюдения → группы похожих наблюдений → паттерны → причины поведения → инсайты → opportunities → продуктовые гипотезы.
Если перескочить через несколько этапов, возникают слабые решения.
Например, пользователь говорит:
«Мне неудобно каждый раз вводить адрес доставки».
Дизайнер может сразу решить:
«Нужно сделать автозаполнение адреса».
Но это уже решение.
Исследование пока показало только конкретную проблему одного человека.
Если посмотреть на остальные интервью, может выясниться, что пользователи вообще не столько недовольны вводом адреса, сколько боятся ошибиться в данных доставки.
Тогда более глубокая проблема заключается не в скорости заполнения формы, а в неуверенности пользователя в правильности введённых данных.
И продуктовые решения становятся совершенно другими:
— сохранённые адреса;
— проверка адреса;
— карта;
— подтверждение перед оплатой;
— возможность быстро изменить данные.
Поэтому между пользовательской цитатой и интерфейсным решением всегда должен существовать этап интерпретации.
4. Что такое синтез пользовательских данных
Синтез данных — это процесс объединения отдельных наблюдений исследования в более общие закономерности и выводы.
Во время анализа мы сначала разделяем информацию на части.
Например:
«Я всегда смотрю отзывы перед покупкой».
«Если отзывов мало, я обычно не заказываю».
«Мне важнее фотографии покупателей, чем описание магазина».
На уровне отдельных цитат это три самостоятельных факта.
Во время синтеза мы замечаем, что все три высказывания связаны с одной более широкой темой:
пользователь ищет подтверждение качества у других покупателей, потому что не полностью доверяет информации продавца.
Это уже не пересказ интервью, а объяснение поведения.
Синтез помогает перейти от уровня «что произошло» к уровню «почему это происходит».
5. Единица пользовательских данных
Прежде чем группировать данные, их желательно разбить на небольшие смысловые элементы.
Одна карточка в Affinity Map должна содержать одну законченную мысль.
Например, плохая карточка:
«Мне сложно выбирать товары, отзывам я не всегда доверяю, характеристики непонятные, а ещё доставка иногда дорогая».
Здесь сразу четыре разные темы.
Лучше разделить:
«Мне сложно сравнивать похожие товары».
«Я не всегда доверяю отзывам».
«Некоторые характеристики мне непонятны».
«Стоимость доставки иногда становится причиной отказаться от покупки».
Так карточки проще сравнивать между собой.
Очень полезно сохранять вместе с наблюдением источник:
Р3: «Если доставка получается дороже 500 рублей, я обычно начинаю искать другой магазин».
Обозначение Р3 позволяет позже вернуться к конкретному респонденту и проверить контекст.
6. Affinity Mapping
Что это такое
Affinity Mapping, или аффинити-маппинг, — метод группировки пользовательских наблюдений по смысловому сходству.
Проще говоря, команда размещает множество отдельных карточек с цитатами и фактами, а затем начинает объединять похожие карточки.
Важно, что группы обычно появляются снизу вверх.
То есть сначала мы смотрим на данные, а уже потом называем категории.
Не стоит заранее создавать разделы:
«Цена»
«Интерфейс»
«Доставка»
«Отзывы»
и затем механически раскладывать ответы по этим коробкам.
Такой подход заставляет данные соответствовать нашей заранее придуманной структуре.
В настоящем affinity mapping структура должна постепенно возникать из самих интервью.
7. Как строится Affinity Map
Предположим, у нас есть следующие высказывания пользователей интернет-магазина:
«Перед заказом я почти всегда ищу фотографии покупателей».
«Если отзыв выглядит слишком идеальным, я ему не доверяю».
«Когда отзывов меньше десяти, мне кажется, что товар мало кто покупал».
«Описание магазина я читаю уже после отзывов».
Все карточки связаны с одной темой.
Мы можем сначала назвать группу:
Отзывы и социальное доказательство.
Но это пока просто тема.
Посмотрим глубже.
Что объединяет поведение пользователей?
Они используют отзывы не просто ради получения дополнительной информации.
Отзывы помогают им уменьшить неопределённость перед покупкой.
Тогда название группы может стать более содержательным:
Пользователи используют опыт других покупателей как способ снизить риск неудачной покупки.
Так мы постепенно приближаемся к инсайту.
8. Тема, наблюдение и инсайт — это не одно и то же
Для начинающих специалистов это одно из самых важных различий.
Наблюдение
Что конкретно произошло или что сказал пользователь.
«Респондент проверяет отзывы перед покупкой».
Паттерн
Повторяющаяся закономерность.
«Большинство опрошенных проверяют отзывы перед оформлением заказа».
Тема
Область, к которой относятся наблюдения.
«Отзывы и доверие».
Инсайт
Объяснение того, почему пользователь ведёт себя таким образом и какое значение это имеет.
«Когда пользователь не может самостоятельно проверить качество товара, он переносит часть решения на опыт других покупателей. Поэтому отсутствие убедительных отзывов воспринимается не просто как нехватка информации, а как дополнительный риск покупки».
Инсайт находится глубже темы.
Фраза:
«Пользователям важны отзывы»
— ещё не инсайт.
Она сообщает нам факт, но практически ничего не объясняет.
9. Что такое хороший пользовательский инсайт
Хороший инсайт обычно содержит четыре элемента:
Контекст → поведение → причина → последствие.
Например:
Пользователи, которые покупают товар впервые, внимательно проверяют отзывы и фотографии покупателей, потому что не доверяют описанию продавца как единственному источнику информации. Если независимых подтверждений мало, они откладывают покупку или продолжают искать альтернативы.
Здесь присутствуют:
Контекст: первая покупка.
Поведение: изучение отзывов.
Причина: необходимость независимого подтверждения.
Последствие: отказ или продолжение поиска.
Такой инсайт уже можно использовать в продуктовой работе.
10. Боли пользователей
Pain point, или пользовательская боль, — проблема, трудность или негативный опыт, который мешает человеку достичь цели.
Боль возникает не потому, что интерфейс «некрасивый».
Она появляется, когда между целью пользователя и её достижением возникает препятствие.
Например:
Пользователь хочет быстро заказать товар.
Но стоимость доставки показывается только в конце оформления.
Получается:
Цель: понять итоговую стоимость покупки.
Препятствие: цена доставки скрыта до checkout.
Боль: пользователь тратит время на оформление заказа, не понимая заранее итоговую стоимость.
Хорошая формулировка боли описывает проблему пользователя, а не недостаток интерфейса.
Слабо:
«На карточке товара нет информации о доставке».
Сильнее:
«Пользователь не может заранее оценить полную стоимость покупки и боится потратить время на оформление заказа, который окажется слишком дорогим».
11. Мотивы пользователей
Мотив отвечает на вопрос:
«Почему человек вообще хочет совершить это действие?»
Например, человек покупает ежедневник.
Функциональная причина:
записывать задачи.
Но мотив может находиться глубже:
чувствовать контроль над большим количеством дел.
Именно второй уровень часто оказывается полезнее для дизайнера.
Если команда понимает только действие пользователя, она проектирует функции.
Если понимает мотив — начинает проектировать ценность.
Например:
Пользователь хочет не просто «посмотреть статус заказа».
Он хочет убедиться, что ситуация находится под контролем.
Поэтому хороший трекинг доставки должен не только показывать статус, но и снижать тревогу.
12. Барьеры
Барьер — фактор, который мешает пользователю совершить действие, даже если сама потребность существует.
Например, человек хочет пройти онлайн-курс.
Потребность есть.
Мотивация есть.
Но действие не происходит.
Почему?
Возможные барьеры:
— слишком высокая цена;
— непонятно, сколько времени понадобится;
— человек боится, что не закончит обучение;
— не доверяет преподавателю;
— сомневается, подходит ли уровень курса;
— не понимает, какой результат получит.
Барьер особенно важен для продуктовых и маркетинговых задач, потому что объясняет разницу между:
«Мне это нужно»
и
«Я готов это использовать или купить».
13. Боль и барьер — не одно и то же
Представим приложение для тренировок.
Пользователь говорит:
«Мне сложно регулярно заниматься спортом».
Это боль.
Но затем он добавляет:
«Я несколько раз покупал подписку, но переставал пользоваться приложением через две недели».
Почему?
«Тренировки занимали по часу, а вечером у меня редко остаётся столько времени».
Вот это уже барьер.
Боль:
трудно поддерживать регулярные тренировки.
Барьер:
формат тренировки плохо вписывается в реальный график пользователя.
Для дизайнера различие принципиально важно.
14. Opportunities
После того как мы поняли проблемы, мотивы и барьеры, появляется следующий уровень — opportunities, или продуктовые возможности.
Opportunity — это не конкретная функция.
Это область, в которой продукт может создать дополнительную ценность.
Например, инсайт:
Пользователи откладывают покупку незнакомого товара, если не могут быстро убедиться в его качестве.
Слишком раннее решение:
Добавить видеоролики.
Opportunity:
Помочь пользователю быстрее получить независимое подтверждение качества товара.
Внутри одной opportunity может появиться много решений:
— отзывы;
— фотографии покупателей;
— рейтинг;
— сравнение;
— экспертная оценка;
— гарантия возврата;
— видеообзор;
— рекомендации знакомых.
Так команда не фиксируется на первой пришедшей в голову функции.
15. От инсайта к opportunity
Полезная логика:
Что пользователь пытается сделать?
↓
Что ему мешает?
↓
Почему это для него важно?
↓
Какой опыт можно улучшить?
Например:
Наблюдение:
Пользователи несколько раз перепроверяют итоговую стоимость перед оплатой.
Причина:
Они опасаются неожиданных дополнительных расходов.
Инсайт:
Перед финансовым обязательством пользователю важно чувствовать, что итоговая сумма полностью предсказуема. Любой неожиданный платёж резко снижает доверие к сервису.
Opportunity:
Сделать стоимость максимально прозрачной до момента оплаты.
Обратите внимание: мы пока не говорим, как именно это сделать.
16. Подтверждающие цитаты
Инсайт без доказательств легко превращается в мнение исследователя.
Поэтому рядом с каждым важным инсайтом желательно сохранять пользовательские свидетельства.
Например:
Инсайт
Пользователь воспринимает неизвестную стоимость доставки как риск и не хочет начинать оформление, пока не понимает итоговую цену.
Подтверждающие данные
Р2:
«Я сначала пытаюсь найти, сколько будет доставка. Не хочу всё заполнять, а потом увидеть ещё тысячу сверху».
Р5:
«Если доставка появляется только в конце, иногда просто закрываю магазин».
Р7:
«Мне важно сразу понимать итоговую сумму».
Цитата не заменяет инсайт.
Она показывает, из каких данных инсайт появился.
17. Не каждая яркая цитата является инсайтом
Иногда исследователь слышит эффектную фразу:
«Я ненавижу регистрацию».
И сразу делает вывод:
Пользователи ненавидят регистрацию.
Но необходимо проверить контекст.
Почему пользователь её ненавидит?
Возможно:
— пароль слишком сложный;
— регистрации требуют до того, как пользователь увидел ценность сервиса;
— нужно заполнять много полей;
— пользователь боится рекламных рассылок;
— он не понимает, зачем вообще нужен аккаунт.
Одинаковая фраза может скрывать совершенно разные причины.
Поэтому задача исследователя — не коллекционировать эффектные цитаты, а объяснять поведение.
18. Сила инсайта
Все найденные инсайты не обязательно одинаково надёжны.
Условно их можно разделить на:
Сильные — подтверждаются несколькими независимыми интервью и поведением пользователей.
Средние — встречаются у нескольких пользователей, но контекст ещё требует уточнения.
Слабые / гипотезы — интересная закономерность появилась в одном или двух случаях и пока требует дополнительной проверки.
Важно не превращать качественное исследование в голосование.
Фраза «5 из 8 пользователей сказали» может быть полезным описанием выборки, но сама по себе ещё не доказывает универсальность вывода для всей аудитории.
Глубинное интервью прежде всего помогает понять причины и механизмы поведения, а не вычислить точные проценты пользователей.
19. Как провести Affinity Mapping пошагово
После завершения интервью работа может выглядеть следующим образом.
Шаг 1. Собрать данные
Мы переносим важные фрагменты интервью в единое пространство.
Это могут быть:
— прямые цитаты;
— описания поведения;
— проблемы;
— цели;
— обходные решения;
— сомнения;
— причины принятия решений.
Шаг 2. Атомизировать данные
Одна карточка — одна мысль.
Не соединяем несколько разных наблюдений.
Шаг 3. Убрать раннюю интерпретацию
В начале полезно фиксировать максимально близко к данным:
«Проверяет стоимость доставки до оформления».
а не:
«Пользователь ценит прозрачность бизнеса».
Вторая формулировка уже является интерпретацией.
Шаг 4. Найти похожие карточки
Команда начинает двигать карточки и формировать небольшие кластеры.
Не нужно стремиться сразу построить идеальную структуру.
Шаг 5. Назвать группы
Название должно отражать смысл группы.
Слишком общее:
«Цена».
Сильнее:
«Пользователь хочет понимать полную стоимость до принятия решения».
Шаг 6. Найти причины
Задаём вопросы:
Почему это происходит?
Что пользователь пытается защитить?
Чего он пытается достичь?
Почему существующее решение его не устраивает?
Шаг 7. Сформулировать инсайт
Инсайт связывает контекст, поведение и внутреннюю причину.
Шаг 8. Добавить evidence
Подбираем цитаты и наблюдения, которые подтверждают вывод.
Шаг 9. Определить opportunity
Спрашиваем:
Что в пользовательском опыте можно улучшить, если этот инсайт верен?
Шаг 10. Сформировать HMW
Переводим opportunity в исследовательско-дизайнерский вопрос.
20. HMW — How Might We
HMW — How Might We, или «Как мы можем…?», — формат вопроса, который превращает проблему пользователя в пространство для поиска решений.
Например:
Инсайт:
Новые пользователи боятся сделать неправильный выбор тарифа, потому что плохо понимают различия между тарифами и последствия ошибки.
Слабый HMW:
Как сделать таблицу тарифов?
Это уже конкретное решение.
Лучше:
Как мы можем помочь новому пользователю уверенно выбрать подходящий тариф без необходимости подробно разбираться во всех функциях сервиса?
Такой вопрос оставляет пространство для разных идей.
21. Как отличить хороший HMW
HMW должен быть достаточно конкретным, чтобы задавать направление, но достаточно широким, чтобы не диктовать решение.
Слишком широкий:
Как мы можем сделать сервис лучше?
Непонятно, какую проблему решать.
Слишком узкий:
Как мы можем добавить кнопку «Сравнить тарифы»?
Решение уже выбрано.
Рабочий вариант:
Как мы можем помочь пользователю быстро увидеть различия между подходящими ему тарифами?
22. Связь всей цепочки
Рассмотрим полный пример.
Пользовательская цитата
«Я обычно открываю несколько сайтов и выписываю цены, потому что сразу непонятно, что входит в тариф».
Наблюдение
Пользователь вручную сравнивает предложения между сервисами.
Паттерн
Похожие действия выполняют несколько респондентов.
Боль
Сравнение предложений требует дополнительной ручной работы.
Мотив
Пользователь хочет убедиться, что принимает экономически рациональное решение.
Барьер
Разные сервисы описывают тарифы по-разному, поэтому прямое сравнение затруднено.
Инсайт
Когда пользователь выбирает между похожими сервисами, ему недостаточно знать цену — ему нужно чувствовать, что он понимает разницу в ценности предложений. Если сравнение требует самостоятельных расчётов, решение откладывается.
Opportunity
Сделать ценность и различия между вариантами легко сопоставимыми.
HMW
Как мы можем помочь пользователю быстро сравнить ценность вариантов без самостоятельного сбора информации?
Вот такую цепочку и необходимо научиться строить.
23. Как выглядит карта инсайтов аудитории
Итог синтеза можно оформить в таблице.
Кластер | Подтверждающие данные | Боль / мотив / барьер | Инсайт | Opportunity | HMW |
|---|---|---|---|---|---|
Стоимость | Цитаты Р2, Р5, Р7 | Барьер: неопределённая итоговая цена | Пользователь избегает обязательств, пока не понимает полную стоимость | Сделать расходы предсказуемыми | Как мы можем помочь пользователю заранее понять полную стоимость? |
Отзывы | Цитаты Р1, Р4, Р6 | Мотив: снизить риск ошибки | Пользователь доверяет независимому опыту больше, чем описанию продавца | Усилить независимые доказательства | Как мы можем быстрее давать пользователю убедительные доказательства качества? |
Выбор | Цитаты Р3, Р5, Р8 | Боль: трудно сравнивать | Избыток похожих вариантов увеличивает сомнения вместо ощущения выбора | Упростить сравнение | Как мы можем помочь пользователю сузить выбор без ощущения потери контроля? |
Именно такой артефакт становится мостом между исследованием и дальнейшим проектированием.
24. Как это работает на практике
Представим команду, которая разрабатывает приложение для поиска онлайн-курсов.
После интервью команда собрала следующие ответы:
«Я сохраняю курсы, но потом почти никогда к ним не возвращаюсь».
«Иногда программа выглядит интересно, но я не понимаю, хватит ли у меня времени».
«Если курс длится полгода, я уже начинаю сомневаться».
«Мне сложно понять, насколько курс рассчитан на новичков».
«Обычно сначала ищу отзывы выпускников».
«Не люблю отзывы прямо на сайте курса — кажется, что там оставили только хорошие».
«Часто открываю YouTube и ищу обзоры отдельно».
«Мне важнее увидеть реальные работы студентов».
Начинающий дизайнер может быстро сформировать список функций:
— сделать избранное;
— добавить фильтр по длительности;
— поставить отзывы;
— добавить видео.
Но исследователь сначала группирует данные.
Появляются кластеры:
Кластер 1. Реалистичность обучения
Пользователи пытаются понять, смогут ли встроить курс в свою жизнь.
Здесь проблема не просто в том, что «нет информации о длительности».
Глубже находится потребность:
оценить личные усилия и риск бросить обучение.
Кластер 2. Доверие к результату
Пользователи ищут информацию за пределами сайта.
Причина заключается в недоверии к рекламным заявлениям.
Им нужны независимые доказательства.
Теперь появляются два инсайта.
Инсайт 1.
Когда пользователь выбирает длительное обучение, он оценивает не только содержание курса, но и вероятность того, что сможет его закончить. Чем сложнее представить нагрузку в реальной жизни, тем выше вероятность отложить решение.
Инсайт 2.
Перед дорогой или длительной покупкой пользователь не воспринимает информацию самого продавца как достаточное доказательство качества и ищет независимые свидетельства результата.
Теперь команда может искать разные решения, не ограничиваясь первой идеей.
25. Частые ошибки и заблуждения
Ошибка 1. Называть любую проблему инсайтом
«Пользователям сложно найти фильтр» — это наблюдение или проблема.
Инсайт должен объяснять, почему происходящее важно и что стоит за поведением.
Ошибка 2. Придумывать инсайт раньше анализа
Если исследователь заранее уверен, что проблема пользователей — цена, он будет замечать только ответы о цене.
Affinity Mapping нужен в том числе для того, чтобы уменьшить влияние таких ожиданий.
Ошибка 3. Группировать по разделам интерфейса
«Главная», «Каталог», «Корзина», «Профиль» — удобная структура для UI-аудита, но слабая структура для синтеза исследования.
Пользовательские проблемы часто проходят сразу через несколько экранов.
Ошибка 4. Терять исходные цитаты
Через неделю команда может уже не помнить, почему сформулировала конкретный инсайт.
Поэтому важна связь:
вывод ↔ пользовательские данные.
Ошибка 5. Делать вывод из одного яркого интервью
Один эмоциональный респондент может сильно повлиять на восприятие команды.
Интересное наблюдение можно сохранить как гипотезу, но его не следует автоматически превращать в общий вывод об аудитории.
Ошибка 6. Путать мотив с функцией
«Пользователь хочет push-уведомления» — не мотив.
Мотив может быть:
не забыть о важном событии.
Push-уведомление — лишь один способ решить задачу.
Ошибка 7. Формулировать opportunity как готовое решение
«Добавить фильтр» — решение.
«Помочь пользователю быстрее сократить количество неподходящих вариантов» — opportunity.
Ошибка 8. Делать HMW слишком широким
«Как улучшить приложение?» почти не помогает генерации идей.
HMW должен быть связан с конкретным инсайтом.
Ошибка 9. Считать количество упоминаний единственным критерием важности
Редкая проблема может оказаться критической, если её последствия серьёзны.
Например, только один пользователь мог столкнуться с двойным списанием денег. Но продуктовая команда всё равно должна обратить на это внимание.
26. Ограничения метода
Affinity Mapping полезен, но не является универсальным доказательством.
Он хорошо помогает анализировать:
— интервью;
— пользовательские отзывы;
— результаты usability-тестирования;
— дневниковые исследования;
— открытые ответы опросов.
Но affinity map не отвечает на вопросы масштаба.
Если восемь из десяти участников говорят о проблеме, мы ещё не можем утверждать:
«80% всех пользователей имеют эту проблему».
Для оценки распространённости нужны количественные методы: аналитика, опросы, эксперименты и работа с более крупными выборками.
Кроме того, synthesis сильно зависит от качества исходного исследования.
Если интервью состояло из наводящих вопросов, affinity mapping не исправит плохие данные.
27. Работа с инструментами
Для занятия удобно использовать несколько инструментов.
Miro или FigJam — основное пространство для Affinity Mapping. Каждая цитата размещается на отдельном стикере, после чего команда группирует карточки и формирует кластеры.
Google Sheets удобно использовать как исследовательский репозиторий. В таблице можно хранить респондента, цитату, тему, контекст, тег, инсайт и ссылку на запись интервью.
Google Docs или Notion подходят для оформления итогового research report и карты инсайтов.
ChatGPT можно использовать как вспомогательный инструмент: например, для проверки понятности формулировки инсайта или поиска альтернативных HMW-вопросов. Но модель не должна самостоятельно придумывать пользовательские выводы, которых нет в исследовательских данных.
Полезное правило:
ИИ может помогать структурировать данные, но источником инсайта остаётся исследование.
Если AI сформулировал красивый вывод, необходимо уметь показать цитаты и наблюдения, которые этот вывод подтверждают.
28. Практическое задание на занятии
Практическая работа: «От интервью к карте инсайтов»
Цель
Научиться превращать сырые пользовательские ответы в структурированные исследовательские выводы.
Исходные данные
Каждая команда получает набор ответов из нескольких пользовательских интервью.
Оптимально использовать 25–50 отдельных цитат.
Работа выполняется в FigJam или Miro.
Пошаговая инструкция
Этап 1. Подготовьте данные — 10 минут
Перенесите ответы пользователей на отдельные стикеры.
Один стикер должен содержать одну мысль.
Укажите номер респондента.
Не переписывайте цитаты сразу в виде выводов.
Этап 2. Проведите Affinity Mapping — 20 минут
Начните перемещать похожие карточки друг к другу.
На этом этапе не пытайтесь сразу определить идеальные категории.
Смотрите прежде всего на смысл:
— одинаковые проблемы;
— похожие ситуации;
— одинаковые способы поведения;
— повторяющиеся страхи;
— одинаковые цели;
— похожие обходные решения.
Карточка может временно находиться между двумя группами.
Этап 3. Назовите кластеры — 10 минут
Для каждой группы придумайте название.
Сначала можно использовать рабочие названия:
«Доверие»
«Цена»
«Выбор»
«Время»
После этого попробуйте сделать их более содержательными.
Вместо:
«Цена»
лучше:
«Пользователям сложно оценить итоговые расходы заранее».
Этап 4. Определите боли, мотивы и барьеры — 15 минут
Для каждого крупного кластера ответьте:
Что человек пытается сделать?
Что ему мешает?
Почему это для него важно?
Что он делает сейчас, чтобы решить проблему?
Что заставляет его отказаться или отложить действие?
Этап 5. Сформулируйте инсайты — 20 минут
Сформулируйте минимум 4 инсайта.
Можно использовать конструкцию:
Когда [контекст], пользователь [поведение], потому что [причина/мотив/барьер], из-за чего [последствие].
Но не превращайте все инсайты в механически одинаковые предложения.
Проверьте каждый вывод вопросом:
«Объясняет ли эта формулировка что-то новое о поведении пользователя?»
Если ответ просто повторяет цитату — это ещё не инсайт.
Этап 6. Добавьте evidence — 5 минут
Для каждого инсайта найдите минимум две подтверждающие цитаты или наблюдения, если данные это позволяют.
Не подбирайте цитаты только потому, что они звучат похоже. Они должны действительно подтверждать смысл вывода.
Этап 7. Сформулируйте opportunities и HMW — 10 минут
Для каждого сильного инсайта определите область возможностей.
После этого сформулируйте один HMW-вопрос.
Пример:
Инсайт: пользователю сложно сравнивать предложения.
Opportunity: снизить усилия, необходимые для осознанного сравнения.
HMW: Как мы можем помочь пользователю быстро сравнить важные для него различия между вариантами?
Что должно получиться
К концу практики команда должна иметь карту инсайтов аудитории, содержащую:
сырые цитаты → affinity-кластеры → боли / мотивы / барьеры → инсайты → opportunities → HMW.
29. Рекомендуемая структура итоговой карты
Для каждого инсайта оформите карточку:
INSIGHT №1
Тема / кластер
…
Наблюдения
…
Подтверждающие цитаты
Р1: «…»
Р4: «…»
Боль
…
Мотив
…
Барьер
…
Инсайт
…
Opportunity
…
HMW
Как мы можем…?
30. Домашнее задание
Домашняя работа: «Карта инсайтов аудитории»
Цель
Закрепить переход от исследовательских данных к аргументированным продуктовым выводам.
Что нужно сделать
На основе данных интервью сформулировать:
8 пользовательских инсайтов;
5 HMW-вопросов.
Каждый инсайт должен быть связан с конкретными пользовательскими данными.
Формат сдачи
FigJam, Miro, Figma, Google Slides или документ.
Главное — должна быть видна логика:
данные → паттерн → инсайт → opportunity → HMW.
Для каждого из восьми инсайтов нужно указать:
название темы или кластера;
формулировку инсайта;
подтверждающие цитаты;
боль, мотив или барьер, лежащий в основе;
opportunity.
Для пяти выбранных инсайтов дополнительно сформулировать HMW.
Минимальный вариант
8 инсайтов + подтверждающие цитаты + 5 HMW.
Расширенный вариант
Дополнительно:
— разделить инсайты на сильные, средние и требующие дополнительной проверки;
— объединить их в 3–5 крупных тематических кластеров;
— определить 3 наиболее важные opportunities;
— объяснить, почему именно их стоит исследовать или проектировать в первую очередь.
31. Критерии проверки
1. Опора на исследовательские данные
Высокая оценка ставится, если каждый инсайт можно связать с конкретными пользовательскими наблюдениями.
Слабая работа:
«Людям нужен современный удобный интерфейс».
Непонятно, из каких данных появился вывод.
Сильная работа:
«Когда пользователю приходится сравнивать большое количество похожих вариантов, дополнительные параметры не облегчают выбор, а увеличивают сомнение. Поэтому ему требуется способ быстро сузить выбор по действительно значимым критериям».
И рядом представлены подтверждающие цитаты.
2. Глубина инсайтов
Инсайт должен объяснять причину поведения, а не просто пересказывать факт.
Наблюдение:
Пользователи читают отзывы.
Инсайт:
Когда пользователь не может самостоятельно оценить качество до покупки, он использует опыт других людей как способ уменьшить риск ошибочного решения.
3. Корректность кластеризации
В одной группе должны находиться данные, объединённые общим смыслом.
Нельзя объединять карточки только потому, что в них встречается одинаковое слово.
4. Качество подтверждающих цитат
Цитаты должны действительно подтверждать инсайт.
Особенно хорошо, если один вывод подкрепляется данными нескольких независимых респондентов.
5. Различение боли, мотива и барьера
Студент должен понимать:
боль — что создаёт негативный опыт;
мотив — почему человеку важно достичь результата;
барьер — что препятствует действию.
6. Качество opportunities
Opportunity описывает пространство для улучшения пользовательского опыта, а не готовую функцию.
Слабо:
Добавить фильтр.
Сильнее:
Помочь пользователю быстрее исключить неподходящие варианты.
7. Качество HMW
HMW должен:
— происходить из инсайта;
— описывать пользовательскую задачу;
— не быть слишком общим;
— не содержать заранее выбранного решения;
— позволять придумать несколько вариантов решения.
32. Итоги лекции
После пользовательских интервью исследование ещё не закончено.
Интервью даёт нам сырой материал.
Affinity Mapping помогает найти в этом материале повторяющиеся закономерности.
Дальше мы пытаемся понять:
Что происходит?
Почему это происходит?
Что пользователь пытается получить?
Что ему мешает?
Какие последствия возникают?
Из ответов появляются боли, мотивы и барьеры.
На их основе формируются инсайты.
Инсайты помогают определить opportunities.
А opportunities превращаются в HMW-вопросы, с которых уже может начинаться этап генерации продуктовых решений.
Поэтому правильная логика выглядит так:
Интервью → данные → Affinity Mapping → паттерны → боли / мотивы / барьеры → инсайты → opportunities → HMW → идеи решений.
Главный навык этого занятия заключается не в том, чтобы красиво раскладывать стикеры.
Главный навык — уметь аргументированно переходить от слов конкретного пользователя к пониманию причин его поведения, не придумывая того, чего в исследовании нет.