Kitabı oxu: «UX-исследования для дизайнеров. Дизайн основанный на фактах»

Серия «Программирование для всех»

© Дмитрий Фокеев, текст

© ООО Издательство «АСТ»

Введение

Когда-то сайты были странными. Непонятными. Перегруженными случайной информацией, без чёткой структуры и логики.

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

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

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

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

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

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

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

Пользовательский опыт тогда ещё не был ценностью. Это была эпоха технологий ради технологий.

Заглянем в прошлое. Кстати, любой из вас может сделать это самостоятельно. Для этого достаточно зайти на сайт https://web.archive.org/ – это веб-архив, который сохраняет снимки сайтов разных лет. По сути, настоящая машина времени прямо в вашем браузере.

Изучая сайты прошлого, невольно задаёшься вопросом, как мы

пришли от этого:

к этому:

от этого:

к такому:

или от этого:

к такому:

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

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

Но так было не всегда.

Когда-то все эти привычные нам вещи были открытием. Они появились благодаря годам проб и ошибок, многочисленным исследованиям и тестированиям с реальными пользователями. Всё то, что сегодня кажется очевидным, в прошлом приходилось «изобретать» – и доказывать, что это действительно работает.

Стандарты интерфейсов – это не что-то врождённое. Это результат эволюции. И за этой эволюцией стояла главная цель – сделать взаимодействие с цифровыми продуктами понятным и удобным для людей. Лучшие решения в индустрии становились стандартом и укоренялись у пользователей. Тест за тестом, проверка за проверкой – так шаг за шагом начала формироваться новая профессия: UX-дизайнер. Или, как их ещё называют, UX-исследователь.

UX – это сокращение от User Experience, что переводится как «пользовательский опыт». Именно этот опыт и стал главным объектом внимания новой профессии.

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

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

Современные пользователи ожидают быстрых решений и ясных путей к ним. Они ценят своё время. Если сайт или приложение мешает, тормозит или запутывает – пользователь просто не станет им пользоваться.

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

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

Ответ прост: исследуйте и тестируйте.

Именно этому и посвящена эта книга. Вместе мы разберём, как понимать своих пользователей, как находить и устранять слабые места в интерфейсе, как превращать продукт из «непонятного» в «удобный и любимый».

Мы изучим современные методы UX-исследований и тестирования – те подходы, которые за последние годы стали основой работы лучших команд и дизайнеров. Главное: все эти методы можно применять на практике, даже если вы работаете в одиночку или в маленькой команде.

Готовы? Тогда давайте начинать наше увлекательное путешествие в мир юзабилити – в мир, где продукты делают для людей.

Об этой книге

В этой книге мы подробно разберём всё, что связано с UX при создании IT-продуктов (сайтов, приложений, программ и т. д.). Мы рассмотрим не только теоретические основы, но и практические инструменты, методы и примеры, чтобы помочь вам применять UX-исследования на реальных проектах. Книга ориентирована на начинающих и опытных специалистов, желающих систематизировать знания. Вот подробный план её структуры – с разбивкой по частям и ключевыми темами внутри каждой.

Книга состоит из семи частей, каждая из которых строится на предыдущей, начиная от основ и переходя к практическим методам и их интеграции:

Часть об основах UX.

Эта часть закладывает фундамент для понимания дисциплины. Мы разберём ключевую терминологию (например, usability, user experience, user interface), приведём реальные примеры применения UX в IT-продуктах (от мобильных приложений до корпоративного софта) и объясним, что такое UX-исследования как таковые – их цели, этапы и роль в продуктовом цикле. Также обсудим историю развития UX, ключевые принципы (например, человекоцентричность по Нильсену) и типичные ошибки новичков. Это поможет читателю понять, почему UX – не просто «красивый дизайн», а инструмент для повышения удовлетворённости пользователей и бизнес-метрик.

Часть о проведении интервью с пользователями.

Интервью – один из лучших способов выяснить реальный опыт взаимодействия с продуктом, понять проблемы пользователей, поставить себя на их место и создать продукт, действительно ориентированный на людей. Мы подробно разберём типы интервью (структурированные, полуструктурированные, глубинные), подготовку (составление вопросов, рекрутинг респондентов), проведение (техники активного слушания, избежание биасов) и анализ результатов (транскрипция, кодирование тем). Приведём примеры скриптов, шаблоны и кейсы из практики, чтобы вы могли сразу применить метод в своём проекте.

Часть о других видах тестирования в группе качественных методов.

Мы поговорим о таких подходах, как JTBD (Jobs to Be Done – анализ, помогающий понять, какую задачу пользователь пытается решить, когда выбирает продукт или услугу), пользовательские сценарии (user stories и journeys), карты эмпатии (empathy maps для визуализации мыслей и чувств пользователей), а также другие методы – вроде фокус-групп, дневниковых исследований и кард-сортинга.

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

Часть об опросах.

Опросы – это один из лучших методов в группе количественных исследований, позволяющий масштабировать данные. Они помогут проверить наши гипотезы и предположения на большой группе респондентов, получив таким образом количественное подтверждение нашим догадкам. Мы обсудим методы проведения опросов (онлайн-формы, анкеты, surveys в Google Forms или Typeform), основы социологии (избежание предвзятости, формулировка вопросов), работу с выборками и совокупностями (репрезентативность, расчёт размера выборки), а также все ключевые аспекты их организации – от дизайна вопросов до анализа данных (статистика, визуализация результатов).

Часть о других видах количественных исследований.

Здесь мы рассмотрим такие инструменты, как A/B-тесты (сравнение версий интерфейса по метрикам), тепловые карты (heatmaps для анализа внимания), карты кликов (click maps для отслеживания взаимодействий), аналитика сессий (session recordings) и многое другое. Цель – дать вам полное понимание всех возможных методов в группе количественных исследований с акцентом на инструменты вроде Google Analytics, Hotjar или Amplitude. Мы объясним, когда применять каждый метод и как интерпретировать данные для улучшения продукта.

Часть о юзабилити-тестировании.

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

Заключительная часть об интеграции и практике.

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

Часть 1
Основы UX

Глава 1
Развеем заблуждения: что такое UX-исследования?

Если мы хотим создавать действительно удобные сайты, сервисы и вообще любые цифровые продукты, без UX-исследований не обойтись.

Исследовать поведение пользователя – это единственный способ проверить, насколько продукт реально удобен и понятен. Это единственный способ увидеть продукт глазами пользователей, а не глазами команды, которая его разрабатывает.

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

Человек, который откроет ваш сайт или приложение, либо поймёт его с первой секунды, либо закроет, так и не поняв, что вы ему предлагали.

UX-исследования – это процесс, который помогает превратить продукт из «мы считаем, что он удобный» в «люди действительно им пользуются, и им удобно».

Таким образом, UX-исследования (User Experience Research) – это системный сбор и анализ данных о поведении, потребностях и мотивах пользователей при взаимодействии с продуктом или сервисом.

Цель UX-исследований – принимать дизайн-решения на основе фактов, а не на интуиции или чьём-то мнении.

UX-исследования – это конкретный процесс, направленный на то, чтобы сделать продукт удобным и понятным. Чтобы этого добиться, UX-исследования ставят перед собой четыре основные задачи.

Основные задачи UX-исследований

1. Понять пользователей.

Кто они? Зачем пришли в ваш продукт? В каком контексте будут им пользоваться – с телефона в метро, на бегу или за ноутбуком в спокойной обстановке? Какие задачи хотят решить? Без понимания этого вы проектируете интерфейс вслепую.

2. Выявить проблемы.

На каких этапах люди «спотыкаются»? Что вызывает затруднения, раздражение или полное непонимание? Где они теряются? UX-исследования помогают увидеть реальные барьеры, о которых команда часто не догадывается.

3. Проверить гипотезы.

Любая новая фича – это гипотеза. Любой прототип – это предположение о том, как будет удобно. UX-исследования позволяют проверить, работает ли задуманное. Поняли ли идею? Дошли ли до цели?

4. Оценить удовлетворённость.

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

Этапы UX-исследований

Каждое исследование, независимо от масштаба, проходит примерно одинаковые этапы:

1. Подготовка.

Определяются цели исследования и формулируются ключевые вопросы. Что именно мы хотим узнать? Какие аспекты поведения или восприятия хотим изучить? Также выбираются методы – интервью, тестирование, опросы или их комбинации.

2. Сбор данных.

Это «полевой» этап. Здесь проводится работа с пользователями: интервью, юзабилити-тесты, онлайн-опросы, трекинг кликов, карточные сортировки. Главное – собрать реальные данные о взаимодействии людей с продуктом.

3. Анализ.

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

4. Формирование рекомендаций.

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

5. Валидация.

После внесённых изменений важно проверить, сработали ли они. Для этого проводится повторное тестирование или A/B-тест. Цель этапа – убедиться, что продукт действительно стал лучше для пользователей.

Распространённые мифы об UX-исследованиях

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

Миф 1. UX-исследования – это только юзабилити-тесты.

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

Миф 2. Достаточно один раз опросить пользователей.

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

Миф 3. Нам не нужны исследования – у нас есть аналитика.

Количественная аналитика показывает, что происходит (например, где люди уходят с сайта), но не объясняет, почему это происходит. Только UX-исследования позволяют заглянуть глубже – понять причины поведения пользователей.

Миф 4. UX-исследования замедляют разработку.

Наоборот. Правильно спланированное мини-исследование с 5–7 реальными пользователями занимает 1–2 недели и позволяет заранее выявить серьёзные ошибки, которые потом будут стоить команде месяцев переделок и исправлений. UX-исследования экономят время, а не тратят его.

Миф 5. Пользователь всегда прав.

Пользователь действительно знает, что ему неудобно. Но он не всегда может объяснить, почему или сформулировать, что нужно изменить. Задача UX-исследователя – слушать слова респондента, но анализировать его поведение. Люди часто не осознают своих глубинных потребностей, но их действия показывают гораздо больше, чем их слова.

Глава 2
Продуктовые исследования – что это такое?

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

Для удобства всё это объединяется в одно понятие: продукт.

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

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

• Решает ли продукт задачу пользователя?

• Насколько хорошо он это делает?

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

Жизненный цикл продукта и подход к исследованиям

Подход к продуктовым исследованиям напрямую зависит от того, на какой стадии находится продукт. Разные этапы жизни продукта диктуют разные методы работы.

1. Новый продукт (подготовка)

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

• Мало или нет пользователей. Проверять гипотезы практически не на ком.

• Сложность сбора количественных данных. Нет базы, с которой можно было бы работать.

• Высокая степень неопределённости. Непонятно, какие сценарии будут действительно востребованы.

• Гипотезы часто не подтверждаются. Многое, что кажется логичным внутри команды, в реальности оказывается нерабочим.

Поэтому в основном при работе с новым продуктом используются качественные методы: глубинные интервью, исследования потребностей, анализ аналогов, построение Customer Journey Map.

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

2. Работающий продукт (развитие)

Когда продукт уже существует, подход меняется:

• Есть база пользователей. Можно собирать как количественные, так и качественные данные.

• Аудитория становится разной. Появляются группы пользователей с разными задачами и ожиданиями, и это нужно учитывать.

• У продукта появляется сценарий использования. Пользователи привыкают к определённой логике, и любые изменения могут вызвать сопротивление.

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

Главная задача – улучшить продукт, не разрушив привычные сценарии.

Продуктовые исследования сопровождают продукт на всём его жизненном пути – от первых шагов до зрелого состояния.

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

Глава 3
Сначала был сигнал

В процессе работы над продуктом команда собирает огромные массивы данных: метрики, отзывы, комментарии, аналитику поведения. Однако не вся эта информация одинаково полезна. Большая часть данных – это шум. В нём легко потеряться.

Именно поэтому UX-исследователи используют понятие сигнала.

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

Все сигналы можно разделить на два основных типа: внутренние и внешние.

Внутренние сигналы

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

Примеры внутренних сигналов:

• Поведение пользователей.

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

• Обратная связь через каналы поддержки.

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

• Анализ метрик.

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

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

Внешние сигналы

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

Примеры внешних сигналов:

• Отзывы на сторонних платформах.

Комментарии и рейтинги в App Store, Google Play, на сторонних форумах или сайтах с отзывами – это внешний сигнал. Даже если пользователь не обратился напрямую в вашу службу поддержки, он оставил след в публичном пространстве. Повторяющиеся жалобы или похвалы – важная информация.

• Тренды в отрасли.

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

• Конкурентный анализ.

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

Почему сигналы важны?

Сигналы – это как подсказки в большом количестве информации. Они позволяют команде:

• видеть реальные проблемы продукта;

• понимать, что важно для пользователей;

• находить точки роста и улучшения;

• улавливать изменения в поведении и ожиданиях людей;

• быть в курсе изменений на рынке.

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

Глава 4
Кабинетные исследования – взгляни вокруг

В UX принято выделять два основных типа исследований: полевые (field research) и кабинетные (desk research).

Полевые методы – это, например, интервью, юзабилити-тесты, наблюдения за пользователями. То есть ситуации, когда исследователь напрямую взаимодействует с пользователями, выходит к ним «в поле».

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

Обычно кабинетные исследования – это один из первых шагов в любом UX-исследовании. Простыми словами, это поиск и анализ всей доступной информации: в интернете, внутри компании, в существующих отчётах и аналитических системах.

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

Почему они так называются?

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

Кабинетные исследования (desk research) – это сбор и анализ уже существующих данных без прямого контакта с пользователями. Исследователь не спрашивает, не тестирует и не наблюдает. Он собирает информацию из доступных открытых и внутренних источников, систематизирует её и делает выводы.

Задача кабинетного исследования – быстро и недорого получить обзор ситуации:

• понять рынок и поведение пользователей;

• изучить конкурентов;

• найти готовые решения и лучшие практики;

• выявить проблемы и тенденции;

• сформулировать гипотезы для будущих полевых исследований.

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

Без кабинетного исследования можно:

• повторить чужие ошибки;

• не увидеть очевидных решений;

• изучать не то, что действительно важно.

Поэтому профессиональные UX-исследователи начинают именно с анализа доступной информации. Это позволяет:

• избежать лишних затрат;

• быстро изучить контекст;

• подготовить качественные вопросы для интервью и тестов.

Когда проводить кабинетные исследования

• На старте проекта – чтобы изучить рынок и сформулировать начальные гипотезы.

• Если нет ресурсов на дорогое полевое исследование – жалобы, внутренние отчёты, данные аналитики могут дать ценные инсайты.

• Перед началом полевых методов – кабинетное исследование позволяет лучше понять контекст и правильно сформулировать вопросы для интервью или опросов.

Глава 5
Основные источники данных в кабинетных исследованиях

Источники данных в кабинетных исследованиях разнообразны и могут быть разделены на несколько категорий. Каждая из них предлагает уникальный взгляд на проблему: от внутренних метрик компании до глобальных тенденций. В этой главе мы разберём эти категории подробнее, с примерами их применения в UX-контексте. Помните, что ключ к успеху – в комбинации источников: один даёт глубину, другой – ширь. Давайте рассмотрим их по порядку.

Внутренние источники: данные из «сердца» компании

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

• Отчёты о продажах. Эти документы показывают, какие функции или страницы продукта генерируют доход, а какие приводят к оттоку. Например, если продажи падают после обновления интерфейса – это сигнал к пересмотру дизайна.

• Аналитика сайта или приложения. Инструменты вроде Google Analytics или встроенной телеметрии предоставляют данные о посещаемости, времени на странице и bounce rate. В UX это помогает понять, где пользователи «застревают» – например, на форме регистрации.

• CRM-системы. Системы управления отношениями с клиентами (например, Salesforce или Bitrix24) хранят историю взаимодействий: жалобы, запросы и предпочтения. Это источник для создания персон, основанных на реальных сценариях.

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

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

Публичные источники: открытые данные для глобального взгляда

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

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

• Отчёты консалтинговых компаний. PwC, Gartner или McKinsey публикуют ежегодные обзоры трендов в IT и UX. Эти отчёты могут вдохновить на новые фичи – например, интеграцию AI в интерфейсы на основе глобальных тенденций.

• Рыночные тренды и макрометрики. Источники вроде Statista или World Bank дают данные об экономике и технологиях, помогая предсказать, как изменится поведение пользователей (например, рост мобильного трафика в регионах).

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

Конкурентные источники

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

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

• Отзывы на маркетплейсах. Платформы вроде App Store, Google Play или Ozon собирают пользовательские отзывы. Анализ их показывает «болевые точки» – от медленной загрузки до неинтуитивных элементов.

• Анализ ассортимента, цен, пользовательских комментариев. Изучите, как конкуренты позиционируют продукты: цены влияют на восприятие ценности, а комментарии – на эмоциональный отклик пользователей.

В UX это приводит к benchmarking: сравните ваш продукт с лидерами, чтобы улучшить usability.

Академические источники

Академические источники предоставляют проверенные знания, подкреплённые исследованиями. Они особенно полезны для глубокого понимания поведенческих моделей в UX. Например:

• Научные статьи. Журналы вроде Human-Computer Interaction публикуют работы о когнитивных аспектах интерфейсов.

• Исследования в Google Scholar. Поиск по ключевым словам (например, user experience mobile apps) даёт доступ к мета-анализам и кейсам.

• Проверенные теоретические модели и подходы. Модели вроде Nielsen's Heuristics или Fitts' Law помогают обосновать дизайн-решения на научной базе.

Используйте их для валидации гипотез – академия добавляет credibility вашим отчётам.

Социальные медиа и сообщества

Социальные сети – динамичный источник, отражающий реальные мнения и тренды в реальном времени. Например:

• Форумы, блоги, видеообзоры, соцсети. Reddit, VK или YouTube содержат обсуждения продуктов, где пользователи делятся «болевыми точками».

• Мнения и «болевые точки» пользователей. Анализ хэштегов или комментариев выявляет эмоциональные барьеры в UX.

• Запросы аудитории. Поиск по запросам вроде «как выбрать app для фитнеса» показывает unmet needs.

В UX это источник для sentiment analysis, помогающий адаптировать продукт под актуальные ожидания.

Аналитические платформы

Эти инструменты агрегируют данные из интернета, предоставляя метрики для объективного анализа. Например:

• Google Analytics, SimilarWeb, App Annie. Они дают данные о трафике, источниках пользователей и вовлечённости.

• Трафик, источники пользователей, уровень вовлечённости. Это помогает понять, откуда приходят пользователи и почему уходят.

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

Искусственный интеллект

ИИ – относительно новый, но мощный источник, выступающий как вспомогательный инструмент для генерации идей. Например:

• Нейросети для сбора первичной информации и формирования гипотез. Инструменты вроде ChatGPT или Grok могут анализировать публичные данные, генерировать summaries или симулировать пользовательские сценарии. Однако всегда проверяйте ИИ на accuracy: он дополняет, а не заменяет человеческий анализ.

В UX ИИ полезен для быстрого prototyping гипотез, но этика требует прозрачности в использовании.

Глава 6
Плюсы и минусы кабинетных исследований в UX

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

Однако, как и любой метод, кабинетные исследования имеют свои сильные и слабые стороны. В этой главе мы разберём ключевые преимущества и недостатки, чтобы вы могли осознанно интегрировать их в свою стратегию. Анализ плюсов поможет понять, почему desk research часто становится первым шагом, а минусы подскажут, когда стоит перейти к полевым методам, таким как интервью или юзабилити-тестирование. Для наглядности мы представим сравнение в таблице в конце главы, а также приведём примеры из практики IT-продуктов.

Преимущества кабинетных исследований

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

• Быстро и недорого. В отличие от полевых методов, кабинетные исследования не требуют затрат на рекрутинг респондентов, аренду оборудования или проведение сессий. Всё, что необходимо, – доступ к источникам данных (часто бесплатным или внутренним) и время на их анализ. Это делает метод идеальным для стартапов или команд с ограниченным бюджетом. Например, при разработке мобильного приложения для фитнеса вы можете за несколько часов изучить отчёты Gartner о трендах в health-tech, не тратя ни копейки на опросы.

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

• База для формирования гипотез. Кабинетные исследования служат основой для первичных гипотез и планирования дальнейших шагов. Они помогают определить ключевые вопросы для пользователей и приоритеты в полевых исследованиях. Например, изучив отзывы конкурентов на App Store, вы можете сформулировать гипотезу: «Пользователи жалуются на сложную навигацию в аналогичных CRM – стоит протестировать упрощённый дизайн в нашем продукте».

Эти преимущества делают кабинетные исследования незаменимым инструментом для быстрого старта, особенно в agile-командах, где время – критический фактор.

Недостатки кабинетных исследований

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

• Данные могут быть устаревшими или нерелевантными. Публикации, отчёты и статистика быстро теряют актуальность в динамичном IT-мире. Рынок эволюционирует, поведение пользователей меняется под влиянием технологий (например, после внедрения AI в интерфейсы), а внешние источники не всегда отражают текущую реальность. Опираясь на отчёт PwC двухлетней давности, вы рискуете упустить свежие тренды, такие как рост использования voice search в мобильных приложениях.

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

• Риск неверных выводов. Без валидации реальными пользователями гипотезы из кабинетных исследований могут оказаться ошибочными. Это приводит к неверным приоритетам в дизайне. Например, рыночные тренды могут указывать на популярность минимализма, но для вашей нишевой аудитории (скажем, пожилых пользователей) это окажется неудобным. Поэтому desk research всегда нужно дополнять полевыми методами, такими как интервью или A/B-тесты.

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

Сравнение плюсов и минусов в таблице

Для удобства составлена таблица, суммирующая преимущества и недостатки кабинетных исследований. Она поможет быстро оценить, когда метод подойдёт для вашего проекта.

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

Глава 7
Этапы кабинетных исследований в UX

Кабинетные исследования – это не хаотичный «поиск в интернете», а структурированная работа с чёткими этапами, обеспечивающими эффективность и релевантность результатов.

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

Этап 1: Определение целей

Первый и самый важный шаг – понять, зачем вы проводите исследование. Без чёткой цели вы рискуете утонуть в море информации, тратя время на нерелевантные данные. Задайте себе вопросы: «Что именно я хочу узнать? Какую задачу решить через UX-улучшения?»

Примеры целей в контексте UX:

• Как конкуренты формируют цены на аналогичные продукты и как это влияет на восприятие ценности пользователями?

• Какие функции чаще всего упоминают в отзывах пользователей, чтобы выявить неудовлетворённые потребности в нашем интерфейсе?

• Какие отраслевые тренды (например, рост AI в приложениях) могут повлиять на наш продукт в ближайшие годы?

Чёткая цель сужает фокус: если вы разрабатываете мобильное приложение для онлайн-шопинга, цель может звучать как «Изучить UX-конкурентов, чтобы улучшить навигацию в корзине». Это помогает выбрать релевантные источники и избежать отвлечений.

Этап 2: Формирование вопросов и метрик

После постановки цели конкретизируйте, какие данные нужны для ответа на неё. Разделите на типы: количественные (цифры и метрики) и качественные (мнения и описания). Заранее определите параметры сравнения, чтобы анализ был объективным.

• Количественные данные: цены, количество посещений сайтов, рыночные доли.

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

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

Этап 3: Сбор данных

На этом этапе переходите к активному поиску и сбору информации. Используйте источники из предыдущей главы: внутренние (CRM, аналитика), публичные (отчёты Gartner), конкурентные (сайты и отзывы) и другие. Ключ – систематизировать процесс.

Возможные действия:

• скачивание отраслевых отчётов (например, из Statista для трендов в e-commerce);

• выгрузка метрик из аналитических систем (Google Analytics для вашего сайта);

• сбор статистики с открытых источников (Росстат для демографии аудитории);

• анализ сайтов конкурентов, отзывов на маркетплейсах, форумов и блогов (например, Reddit для пользовательских жалоб);

• работа с CRM и внутренними системами компании для исторических данных о взаимодействиях.

Сохраняйте всё в удобном формате: таблицы в Google Sheets для чисел, текстовые заметки в Notion для отзывов, скриншоты интерфейсов. Это упростит переход к анализу и минимизирует потери данных.

Этап 4: Анализ и синтез

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

В UX это включает:

• сравнение метрик (например, время загрузки страниц у конкурентов vs вашего продукта);

• выявление трендов (рост использования dark mode в приложениях);

• анализ сегментов аудитории и сценариев (как пользователи 35+ взаимодействуют с интерфейсами);

• отмечание сильных сторон конкурентов (интуитивная навигация) и слабых (медленная регистрация).

• Цель – синтезировать разрозненные факты в логичную картину: используйте инструменты вроде mind maps или SWOT-анализа для визуализации.

Этап 5: Выводы и формирование гипотез

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

Возможные выводы:

• Что происходит на рынке (например, сдвиг к мобильным интерфейсам)?

• Где у конкурентов слабые места (сложная форма оплаты)?

• Как ведут себя пользователи (предпочитают минималистичный дизайн)?

Из выводов генерируйте гипотезы для валидации:

• Возможно, пользователи ищут более простой интерфейс, что стоит проверить в юзабилити-тестах.

• Возможно, высокая цена конкурентов – точка входа для нашего предложения, подтвердите опросами.

Гипотезы должны быть тестируемыми и связанными с UX-целями, чтобы направлять следующие шаги.

Этап 6: Документирование

Завершающий этап – оформление результатов для команды. Без документации инсайты рискуют потеряться.

Включите:

• таблицы и графики для визуализации данных (например, сравнительная диаграмма интерфейсов);

• основные инсайты (ключевые тренды и проблемы);

• список рекомендаций (что улучшить в продукте);

• гипотезы и предложения по следующим шагам (план интервью или A/B-тестов).

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

Заключение: от этапов к интеграции в практику

Структура кабинетных исследований обеспечивает системность: от цели к выводам, с фокусом на релевантности и практически применимые инсайты. В UX это особенно важно, поскольку desk research – мостик к более глубоким методам, таким как интервью или количественные тесты. Всегда адаптируйте этапы под проект: для малого стартапа сократите сбор данных, для enterprise – добавьте автоматизацию.

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

Глава 8
Пример кабинетного исследования на практике

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

Задача примера: понять, какие ценовые модели предлагают конкуренты в вашей нише онлайн-курсов. Это классическая ситуация для анализа рынка, где нужно изучить открытые источники, чтобы выявить, как другие компании формируют тарифы и предложения. Такой подход позволяет собрать данные о ценах, функциях и отзывах, чтобы на их основе спроектировать собственный продукт. Мы разберём процесс по шагам, с практическими рекомендациями, и объясним, зачем это нужно для UX-команды. Этот пример демонстрирует, как кабинетные исследования служат основой для гипотез и улучшений интерфейса, экономя время и ресурсы.

Шаги кабинетного исследования

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

1. Сбор тарифов и опций с сайтов конкурентов.

Начните с выбора 5–10 прямых и смежных конкурентов (например, Coursera, Udemy или локальных платформ вроде Skillbox). Зайдите на их сайты и зафиксируйте ключевую информацию:

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

• какие функции входят в каждый тариф (доступ к материалам, сертификаты, поддержка);

• как формируются цены (фиксированная сумма, помесячная подписка, годовой абонемент).

Сохраняйте данные в таблице для удобства – это упростит дальнейший анализ и сравнение. Например, в Excel или Google Sheets создайте столбцы для компании, тарифа и функций.

2. Анализ отзывов на сторонних платформах.

Соберите отзывы пользователей из независимых источников, чтобы понять реальное восприятие ценовых моделей:

• на Яндекс, Google, маркетплейсах (App Store, Google Play) или тематических форумах (Reddit, Habr);

• обратите внимание на то, что хвалят или критикуют в платных версиях (например, «премиум стоит своих денег за личного куратора» или «базовый тариф слишком ограничен»);

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

Это даст качественные инсайты о болевых точках, таких как неудобство оплаты или отсутствие ценности в тарифах.

3. Выявление популярных функций для разных тарифов.

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

• доступ к личному наставнику – обычно только в топовых пакетах;

• групповые сессии – начиная со среднего тарифа;

• сертификат – в любом пакете, как базовая функция.

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

4. Составление сравнительной таблицы.

Объедините все данные в единую таблицу для визуального сравнения:

• название компании;

• стоимость тарифов (с указанием валюты и периода);

• доступные функции в каждом пакете;

• отзывы и средняя оценка пользователей (из расчёта по отзывам).

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

5. Формирование гипотез для дальнейшей работы.

На основе анализа сделайте выводы и сформулируйте гипотезы для проверки в полевых исследованиях:

• что происходит на рынке (например, рост подписок вместо разовых покупок);

• где у конкурентов слабые места (завышенные цены без добавленной ценности);

• как ведут себя пользователи (предпочитают тарифы с гарантиями возврата).

Пример гипотезы: «Если мы добавим модуль персональной обратной связи в средний тариф, конверсия вырастет на X %». Эти предположения станут основой для интервью, опросов или A/B-тестов, связывая кабинетные данные с практическими улучшениями UX.

6. Кабинетное исследование в таком формате даёт команде ценный фундамент для дизайна продукта:

• понимание, как конкуренты формируют ценность своих предложений (через функции, цены и интерфейсы оплаты);

• информацию о рыночных ожиданиях пользователей (что они ценят в тарифах, какие барьеры видят);

• основание для проектирования собственных тарифов (адаптация под нужды аудитории);

• гипотезы для проверки в реальных условиях (чтобы избежать ошибок на этапе разработки).

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

7. Заключение

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

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

Глава 9
Разновидности исследований на все случаи жизни продукта

На протяжении многих лет в процессе проведения UX-исследований специалисты накапливали и структурировали различные методы изучения поведения пользователей. Эти методы рождались из практики: одни появлялись как результат конкретных кейсов, другие – как попытка систематизировать хаотичный сбор данных. Со временем их начали классифицировать, объединять в группы, искать между ними связи.

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

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

Если же говорить о самом фундаментальном разделении всех методов UX-исследований, то оно выглядит следующим образом:

• Качественные исследования – методы, помогающие понять, почему люди ведут себя определённым образом.

• Количественные исследования – методы, позволяющие измерить, что именно происходит и в каких объёмах.

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

Качественные исследования

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

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

Зачем это нужно? Чтобы перестать проектировать интерфейсы для «среднестатистического пользователя». Качественные исследования помогают понять реальные сценарии, реальные потребности и реальные проблемы людей. Только так можно создать продукт, который действительно отвечает ожиданиям аудитории.

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

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

1. Интервью с пользователями (User Interviews).

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

2. Фокус-группы (Focus Groups).

Группа из 5–8 человек обсуждает продукт или тему под руководством модератора. В ходе обсуждения рождаются идеи, звучат критические замечания и неожиданные точки зрения. Это хороший способ получить сразу несколько разных мнений и увидеть, как люди формируют своё мнение в группе.

3. Дневниковые исследования (Diary Studies).

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

4. Контекстное наблюдение (Contextual Inquiry).

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

5. Этнографические исследования (Ethnographic Studies).

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

Эти методы объединяет главное: они направлены на понимание человека, а не на подсчёт его действий. И именно это делает их незаменимыми при проектировании удобных и понятных продуктов. Именно поэтому их и называют качественными.

Количественные исследования

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

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

Количественные исследования отвечают на вопросы:

• Сколько пользователей действуют определённым образом?

• Какой процент людей завершает целевое действие?

• Сколько времени требуется на выполнение задачи?

• Где пользователи чаще всего совершают ошибки?

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

Количественные исследования важны, когда нужно:

• проверить гипотезу на больших объёмах данных;

• измерить эффект изменений;

• найти слабые места в воронке;

• получить факты и цифры для принятия решений.

В отличие от качественных исследований, которые объясняют почему, количественные исследования показывают, что происходит и в каком объёме. Это взгляд на продукт через объектив статистики – строгий, точный, масштабный.

Также рассмотрим несколько самых популярных количественных методов:

1. Опросы и анкеты (Surveys and Questionnaires).

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

2. A/B-тестирование (A/B Testing).

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

3. Веб-аналитика (Web Analytics).

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

4. Тепловые карты (Heatmaps).

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

5. Когортный анализ (Cohort Analysis).

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

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

Как ещё классифицируют UX-исследования

Теперь, когда мы разобрались с основными группами – качественными и количественными методами, – важно понять: мир UX-исследований не ограничивается только этим делением.

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

Исследования обычно делят по трём осям:

1. По цели: генеративные и оценочные исследования.

• Генеративные исследования (Generative research).

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

• Оценочные исследования (Evaluative research).

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

2. По подходу: качественные и количественные методы.

Это основное деление, о котором мы уже подробно говорили:

• качественные методы объясняют почему;

• количественные методы показывают, что и в каких объёмах.

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

3. По фокусу: поведенческие или аттитюдные исследования.

• Фокус на поведении (Behavioral research).

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

• Фокус на установках (Attitudinal research).

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

Почему важно понимать эти классификации?

Когда вы планируете исследование, важно осознанно выбирать метод, понимая:

• для чего он нужен (цель);

• какие данные он даст (подход);

• на что будет направлен фокус – на поведение или на восприятие.

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

Глава 10
Цели UX-исследований

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

• Цель – что именно мы хотим понять о продукте (итоговое знание для решения).

• Вопросы – на какие конкретные вещи ищем ответы, чтобы цель закрыть.

• Задачи – что будем делать на практике: методы, объём, сроки, артефакты.

Короткий пример:

• Цель – понять, почему пользователи бросают оформление заказа на мобильном.

• Вопросы – какое поле вызывает сомнения? Где пользователи останавливаются? Чего не хватает на экране?

• Задачи – собрать метрики по шагам, провести 8 сессий юзабилити, подготовить рекомендации.

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

Цели UX-исследования

Цель исследования – это чётко сформулированное знание, которое команда хочет получить, чтобы принять продуктовые решения. Не «сделать интервью» и не «поднять конверсию», а понять / оценить / выявить что-то конкретное в поведении и восприятии пользователей.

Пример: «Выявить 3–5 ключевых барьеров на шаге подтверждения email в мобильной регистрации».

Обычно у исследования одна главная цель, также помните, что цель исследования ≠ цель бизнеса. Бизнес-цели – это итоговые результаты компании: выручка, конверсия (CR), удержание, LTV и т. п.

Цели исследования – это знания, которые нужно получить, чтобы принять решения, влияющие на эти результаты. Исследование само по себе KPI не меняет – оно уменьшает неопределённость и подсказывает, что именно менять.

Как это работает на практике

Пример:

• Бизнес-цель. Повысить конверсию регистрации с 38% до 45%.

• Продуктовый вопрос. Почему люди «срываются» на шаге подтверждения email на мобильных?

• Цель исследования. Понять, что именно мешает завершать регистрацию на этом шаге.

Наши действия:

• Проводим исследование. Например, юзабилити-тестирование (наблюдаем, как люди проходят шаг) – и анализируем данные.

• Готовим рекомендации. Переписываем непонятные тексты интерфейса, делаем заметнее основную кнопку призыва к действию (CTA, Call to Action – «Зарегистрироваться», «Продолжить» и т. п.).

• Проверяем изменения экспериментом. Запускаем A/B-тест – показываем часть трафика старой версии (A), часть – новой (B) и сравниваем результаты.

• Измеряем результат. Смотрим на коэффициент конверсии (CR, Conversion Rate – доля пользователей, выполнивших целевое действие).

Частая ошибка и как её избежать

Неверно поставленная цель

• Неверно: «Цель исследования – увеличить конверсию на 10%» (это бизнес-цель).

• Верно: «Оценить, что непонятно на шаге оплаты, и выявить 3–5 ключевых барьеров».

Как избежать: быстрый чек-лист перед стартом

• Цель сформулирована без решения и без KPI («повысить», «переработать» – мимо).

• Понятно, какое решение вы сможете принять по итогу.

• Есть критерии успеха исследования (пример: «понимание тарифа ≥ 80%», «ошибок ≤ 1»).

* Подсказка по типам целей:

• Генеративные исследования (на старте): понять контекст, потребности, язык пользователя. Формулировки: понять, выявить, описать, смоделировать.

• Оценочные исследования (когда есть прототип / функция): проверить понятность и эффективность. Формулировки: оценить, проверить, сравнить, подтвердить / опровергнуть.

И заранее решите: каким путём вы идёте – качественным (почему / как именно) или количественным (сколько / как часто / в каком объёме).

Глава 11
Вопросы исследования

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

Вопросы исследования помогают фокусироваться на конкретных аспектах пользовательского опыта, которые требуют более глубокого понимания. Если цель говорит: «Что хотим понять», то вопрос уточняет: «О чём именно спросим мир / пользователей / данные».

Общий паттерн: более философские вопросы (как воспринимают? Что мешает? Насколько хорошо / плохо и так далее).

Зачем нужны вопросы?

• дают фокус: что именно изучаем, а что – нет;

• помогают выбрать метод (интервью, юзабилити-тест, аналитика, опрос);

• делают отчёт структурным: один вопрос → один блок ответа.

Какими должны быть исследовательские вопросы:

• Открытыми. На них нельзя ответить «да / нет».

Пример: «Какие шаги в регистрации пользователя кажутся лишними?»

• Направляющими. Они задают каркас всему проекту.

Пример: «Что мешает завершать оплату на мобильном?»

• Сфокусированными на проблеме. Без расплывчатого «всё и сразу».

Неверно: «Почему у нас низкая конверсия?»

Верно: «Какие элементы на шаге адреса вызывают ошибки?»

• Опирающимися на данные и наблюдения.

Вопросы возникают из аналитики, поддержки, прошлых тестов.

Пример: «Аналитика показывает рост отказов на шаге „Оплата“. Что именно там непонятно?»

• Многоуровневыми. Можно иметь один общий вопрос и несколько уточняющих.

Общий: «Как люди выбирают тариф?»

Частные: «Какие формулировки они цитируют?», «Где ищут, что входит в тариф?»

Как сформулировать вопросы: короткий алгоритм

1. Оттолкнитесь от цели.

Пример цели: «Понять, почему бросают оформление на мобильной оплате».

2. Сузьте область.

Пример: «Именно экран оплаты, именно новые пользователи».

3. Сделайте вопросы открытыми и нейтральными.

Не подсказывайте ответом.

4. Проверьте «исследуемость».

На вопрос должен ответить конкретный метод (наблюдение, метрики, интервью).

Примеры хороших исследовательских вопросов

1. Предпочтения и потребности

• Какие элементы тарифной страницы люди считают самыми важными и почему?

• Какие данные им нужны, чтобы принять решение «Покупаю»?

2. Поведение

• Как пользователи переходят от главной до оформления заказа на телефоне?

• На каких шагах регистрации они чаще всего останавливаются и почему?

3. Восприятие

• Насколько понятно различие между «Базовым» и «Средним» тарифами?

• Как люди объясняют смысл основного призыва к действию («Оформить»)?

4. Удовлетворённость

• Как пользователи оценивают скорость и стабильность страницы оплаты?

• Что они называют «лишним» шагом в процессе?

Чего избегать при формулировании вопросов?

• Не задавайте оценочных вопросов: не «Почему наш интерфейс плохой?», а «Какие задачи не удаётся выполнить и где именно?»

• Не смешивайте в одном вопросе две темы (например, «про тарифы и про доставку»).

• Не задавайте то, на что нет метода (если ответ может дать только платный отчёт, а доступа нет).

Глава 12
Задачи в UX-исследованиях

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

Что такое задача и чем она отличается от цели

Задача – это конкретный шаг, который мы реально выполним, чтобы ответить на исследовательские вопросы и достичь цели. Если цель – это то, «что мы хотим понять» (например, проблемы пользователей), то задача – это то, «что именно сделаем для этого» (например, провести тесты и собрать данные).

Разница проста, но важна:

• Цель фокусируется на знаниях: «Понять, что мешает оформить заказ на мобильном устройстве».

• Задача – на действиях: «Провести 8 сессий юзабилити-теста, собрать клипы с проблемами и подготовить рекомендации».

Цели дают направление, задачи – план реализации. Без задач цели остаются на бумаге, а исследования – в теории.

Как формулировать задачу

Формулировка задачи должна быть чёткой и практически применимой, чтобы любой член команды понимал, что делать. Используйте шаблон: глагол действия + объект + метод/инструмент + объём + артефакт + срок/владелец.

Примеры задач в этом шаблоне:

• «Собрать и сравнить 7 тарифных страниц конкурентов; свести таблицу цен/опций; вывести 3–5 паттернов – до 20 числа, владелец задачи: Илья».

• «Запустить короткий опрос (≈ 200 ответов) на тарифной странице; измерить понимание преимуществ; подготовить 1-страничный отчёт – в понедельник, владелец задачи: Мария».

• «Проанализировать воронку за 30 дней в GA4; найти шаги с наибольшими потерями; оформить диаграмму + комментарии – к завтрашней встрече, владелец задачи: Олег».

Этот шаблон делает задачи измеримыми и реалистичными, помогая избежать расплывчатости.

Как задачи подчиняются цели

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

Цель: определить барьеры пользователя при покупке товара (мобильная версия).

Задачи:

• Разобрать текущий процесс оформления (скринкасты + карта шагов).

• Провести 8 сессий юзабилити-теста по сценарию «из карточки товара до оплаты».

• Отметить места, где люди останавливаются: непонятный текст, скрытые комиссии, ошибки полей.

• Подготовить рекомендации с приоритетом (метод MoSCoW – Must/Should/Could/Won't) и клипы-доказательства.

Цель: выявить проблемы и ожидания в новой функции «Списки желаний».

Задачи:

• Провести 6 глубинных интервью (по подходу JTBD – Jobs To Be Done, то есть анализ, какую работу пытается выполнить пользователь), раскодировать ответы.

• Оценить восприятие прототипа: найти, что непонятно и чего не хватает.

• Собрать короткий опрос внутри продукта (до 5 вопросов) для количественной проверки тезисов.

• Сформировать бэклог улучшений и план валидации (A/B-тесты – сравнение двух версий на разных группах людей, сроки).

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

• JTBD – это подход «какую работу пытается выполнить пользователь»;

• MoSCoW – способ приоритизации (Must/Should/Could/Won't);

• A/B-тест – сравнение двух версий на разных группах людей.

Что должно быть у каждой задачи

Чтобы задача была полной и выполнимой, включите в неё ключевые элементы:

• Метод и инструмент: чем именно делаем (например, юзабилити-тест в Lookback).

• Объём/выборка: сколько пользователей, страниц или дней (например, 8 сессий или 200 ответов).

• Критерий готовности (Definition of Done): что считаем «сделано» (например, собраны клипы и отчёт).

• Артефакт на выходе: что получим в итоге (таблица, график, клипы, отчёт).

• Срок и владелец: когда и кто отвечает.

Мини-шаблон для строки: действие + объект, метод/инструмент, объём → артефакт – дедлайн.

Примеры в мини-шаблоне:

• Провести интервью с пользователями, Zoom, 8 человек </strong>→<strong> расшифровки и 1-страничная сводка – до 20.09.

• Проанализировать воронку, GA4, последние 30 дней → диаграмма + комментарии – до 12.09.

• Запустить короткий опрос на тарифной странице, Typeform, ≈ 200 ответов → таблица CSV и графики – до 16.09.

• Собрать страницы конкурентов, ручной сбор + скриншоты, 7 сайтов → сводная таблица цен/опций и выводы – до 18.09.

Частые ошибки при формулировке задач

Даже опытные исследователи иногда допускают промахи, которые тормозят процесс. Вот самые распространённые:

• Формулируют метод вместо задачи: «Сделать интервью» – без указания объёма, срока или артефакта, что делает план расплывчатым.

• Пишут слишком размыто: «Разобраться с оплатой» – неясно, чем именно заниматься и к какому сроку завершить.

• Нет владельца: задача без ответственного часто остаётся «ничьей» и не выполняется вовремя.

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

Сравнение задач и целей в таблице

Для наглядности составлена таблица, показывающая разницу между целями и задачами на примерах:

Эта таблица поможет быстро различать уровни планирования.

Задачи – это мостик от абстрактных целей к реальным результатам в UX-исследованиях. Формулируя их по шаблонам, с учётом методов, объёма и сроков, вы делаете процесс управляемым и эффективным. Избегайте ошибок, всегда привязывайте задачи к целям и не забывайте о владельцах – это гарантирует, что исследование перейдёт от слов к делу.

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

Глава 13
Гипотезы в UX-исследованиях

Гипотеза – это наша, как исследователя, чёткая и проверяемая догадка о поведении или восприятии пользователей и о том, как изменение в продукте может это поведение улучшить.

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

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

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

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

У гипотезы есть простой «скелет»:

Если мы сделаем вот такое изменение для таких пользователей / в таком контексте, то такая метрика изменится на столько-то, потому что вот почему это должно помочь.

Успех – порог, после которого признаём: да, сработало.

Важно понимать, какой это тип гипотезы:

• Первая – про проблему. Она помогает точнее увидеть, что именно мешает людям.

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

• Вторая – про решение. Она проверяет, поможет ли конкретная правка.

Например: если добавить подсказку «Индекс – 6 цифр», доля ошибок на шаге адреса снизится с 22% до ≤ 10%, потому что формат станет понятным с первого взгляда. Успех – ≤ 10%, по данным аналитики за неделю эксперимента.

Метрика

Одна гипотеза – одна мысль; всегда есть метрика и понятный способ проверки. Тогда путь от «нам кажется» к «мы знаем» становится коротким и предсказуемым. Гипотеза всегда про конкретного пользователя, в конкретном контексте, с конкретной метрикой.

1. Примеры диагностических гипотез (чтобы найти проблему):

• При заполнении формы заказа люди часто бросают процесс на шаге адреса, потому что не понимают формат индекса. Проверим на юзабилити-сессиях и по событиям «ошибка валидации».

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

• Отчёт «История» кажется неполезным: пользователи не находят нужные периоды. Посмотрим клики и попросим людей найти отчёт за прошлый месяц на тесте.

2. Примеры каузальных гипотез (чтобы решить проблему: предполагаем эффект от изменения):

• Если увеличим кнопку «Купить» и сделаем её основным призывом к действию, CTR (доля кликов) вырастет на 8%, потому что её начнут быстрее замечать. Успех – ≥ +5% в A/B-тесте.

• Если добавим подсказку к полю «Телефон», ошибок ввода станет меньше на 30%. Успех – доля ошибок ≤ 10%.

• Если ускорим загрузку страницы до ≤ 2 сек., отказы снизятся на 15%. Успех – показатель отказов –10% и выше.

Глава 14
Что такое артефакты в UX-исследованиях

В любом исследовании остаются следы – файлы, данные и документы. Мы создаём их по ходу работы и отдаём команде на выходе. Это и есть артефакты. Они фиксируют знания так, чтобы к ним можно было вернуться через неделю или через год и ничего не потерять. Благодаря артефактам можно проверить, откуда взялись выводы, быстрее внедрить изменения и помнить, что уже пробовали и почему.

Какие бывают артефакты:

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

• Дизайнерские – материалы, которые связывают находки с будущими решениями. Прототипы и макеты, пользовательские потоки, карта пути клиента (CJM), схема сервиса (service blueprint), структура контента и навигации, результаты карточной сортировки, карта эмпатии. Это визуальные «мостики» между фактами и изменениями в интерфейсе.

• Данные – сырьё и его обработка. Расшифровки интервью, таблица кодов, выгрузки из аналитики (CSV), когортные отчёты, тепловые карты, клики и скроллы, дашборды в аналитических инструментах. Именно здесь лежат доказательства: что и как мы увидели.

• Конечные артефакты – то, что получает команда ради действий. Короткий отчёт с главными выводами (one-pager), презентация для демо, список рекомендаций с приоритетом, бэклог экспериментов, подборка видеоклипов на 30–90 секунд, диаграммы и таблицы сравнения, план валидации (что и какой метрикой будем проверять). Это «упаковка», с которой удобно заходить к разработке и менеджменту.

• Есть и негативные артефакты – следы методических ошибок: наводящие вопросы в гайде, криво настроенные события аналитики, смещённый скринер. Их важно честно помечать и не использовать как основу решений.

Как сделать артефакты по-настоящему полезными

• Пишите понятно: понятные заголовки, подписи к графикам, кто этот респондент и к какому сегменту он относится.

• Делайте выводы проверяемыми: давайте ссылки на сырые данные – запись, тайм-код, таблицу.

• Настройте права чтения и храните файлы в доступном месте (Notion, Confluence, общий Диск, Figma)

• Держите два уровня детализации: короткая страница для руководителей и полный пакет – для команды.

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

Небольшой пример.

Мы изучаем тарифную страницу на мобильных. В «процессе» у нас остаются: бриф, скринер «новые пользователи 20–45», сценарий «выбор тарифа → оформление», лист наблюдателя, восемь записей с тайм-кодами.

В «данных»: таблица ошибок ввода, тепловая карта кликов, показатель CTR по кнопке «Оформить» (доля кликов), ответы на контрольный вопрос «в чём разница тарифов».

А «на выходе» команда получает: one-pager «5 барьеров и 7 быстрых правок», восемь коротких клипов, бэклог из трёх экспериментов, диаграмму воронки.

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

Где их хранить, как называть и чего стоит избежать

Лучше завести единое Research-хранилище с разделами: проекты, сырые данные, отчёты, клипы, гайды. Названия файлов делайте однотипными: ГГГ-ММ_Проект_Тип_Версия – например, 2025–08_Tariffs_Usability_v1. Связывайте материалы ссылками: отчёт ведёт к клипам и таблицам, клипы – к тайм-кодам и сценарию.

Чего избегать:

• Громоздкие отчёты без решений.

• Выводы без ссылок на источники.

• Видео «посмотрите где-то в середине».

• Личные папки вместо общего доступа.

• Использование «грязных» артефактов (наводящих вопросов, кривой аналитики) как будто это надёжные данные.

Глава 15
Итоги планирования UX-исследований: от целей к артефактам

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

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

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

Цели UX-исследований – это фундамент, где мы фиксируем, что именно хотим понять о продукте. Они включают три уровня: понимание проблемы, оценку решений и выявление возможностей. Цели отличаются от бизнес-метрик: они фокусируются на знаниях, а не на KPI. Например, вместо «повысить конверсию» – «понять барьеры в регистрации». Частая ошибка – путать цели с методами; правильный подход – начинать с данных и заканчивать рекомендациями. Цели бывают генеративными (для открытия нужд) и оценочными (для проверки прототипов), всегда с критериями успеха.

Вопросы исследования уточняют цели, направляя фокус на конкретные аспекты пользовательского опыта. Они должны быть открытыми, направляющими и основанными на данных: «Что мешает завершать оплату?» вместо «Почему конверсия низкая?». Вопросы помогают выбрать метод (интервью для «почему», аналитика для «сколько») и структурировать отчёт. Они многоуровневые: общий вопрос плюс уточняющие. Ошибки – закрытые формулировки или отсутствие связи с данными; хорошие вопросы всегда исследуемы и нейтральны.

Задачи в UX-исследованиях – это шаги для реализации целей и ответов на вопросы. Они отличаются от целей фокусом на действиях: «Провести 8 сессий юзабилити-теста» вместо «Понять барьеры».

Шаблон: глагол + объект + метод + объём + артефакт + срок/владелец.

Задачи подчиняются целям, как в примерах с барьерами покупки или новой функцией. Обязательные элементы: метод, объём, критерий готовности, артефакт и срок. Ошибки – размытость или отсутствие владельца; правильные задачи делают процесс управляемым.

Гипотезы в UX-исследованиях превращают догадки («кажется, проблема в интерфейсе») в проверяемые утверждения. Структура: «Если изменить X для Y-пользователей, то метрика Z вырастет на N %, потому что…». Гипотезы бывают диагностическими (для выявления проблемы) и каузальными (для проверки решения), всегда с метрикой и способом верификации. Они рождаются из данных и помогают избежать споров на ощущениях. Примеры: «Добавим подсказку – ошибки снизятся на 30%». Гипотезы конкретны и testable, фокусируясь на пользователе и контексте.

Артефакты в UX-исследованиях – это «следы» исследования: документы, файлы и материалы, фиксирующие процесс и результаты. Типы: процессные (брифы, гайды), дизайнерские (прототипы, карты пути), данные (расшифровки, таблицы) и конечные (отчёты, рекомендации). Они делают знания доступными и проверяемыми. Полезные артефакты понятны, с ссылками на источники и в общем хранилище. Избегайте ошибок, таких как громоздкие отчёты без решений или использование «грязных» данных. Пример: для тарифной страницы – бриф, записи, таблица и one-pager с правками.

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

• Цели задают рамки: «Что понять?»

• Вопросы уточняют: «О чём спросить?»

• Задачи реализуют: «Что сделать?»

• Гипотезы проверяют: «Что предположить и верифицировать?»

• Артефакты фиксируют: «Что оставить для команды?»

Например, цель «Понять барьеры в регистрации» рождает вопросы «Что мешает на шаге email?», задачи «Провести 8 тестов», гипотезу «Если добавить подсказку, ошибки снизятся» и артефакты «Отчёт с клипами». Такая связь обеспечивает, что исследования не «ради исследований», а для решений: от данных к инсайтам, от инсайтов к изменениям.

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

Эта цепочка минимизирует риски и ускоряет процесс. Давайте теперь посмотрим пример интеграции на практике:

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

• Цель: понять, почему пользователи не понимают разницу между тарифами.

• Вопросы: какие элементы страницы кажутся важными? Что мешает принять решение? Насколько понятны формулировки?

• Задачи: собрать 7 страниц конкурентов (таблица опций – до 15.09); провести 6 интервью (расшифровки – до 20.09); запустить опрос (200 ответов – до 25.09).

• Гипотезы: если упростим тексты, понимание вырастет на 15% (проверка в юзабилити-тесте); если выделим ключевые функции, клики на «Оформить» увеличатся (A/B-тест).

• Артефакты: бриф с целями, таблица сравнения, записи интервью, отчёт с рекомендациями и диаграммами.

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

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

Глава 16
Когда нужно и не нужно проводить исследования

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

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

• пользовательский опыт ухудшается;

• продукт не решает нужных задач;

• команда теряет время и бюджет;

• принимаются решения «на глазок».

Чтобы избежать этих ошибок, важно понимать не только ценность исследований, но и момент, когда они действительно уместны.

Когда исследования нужны:

• Исследования особенно полезны в ситуациях неопределённости, риска или потенциальных изменений:

• До начала разработки нового продукта.

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

• При редизайне.

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

• Перед запуском новой фичи.

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

• При снижении ключевых метрик.

Если падает конверсия, удержание или NPS – нужно искать причину. Исследования помогут понять, что происходит на пользовательской стороне, а не только в цифрах.

• При выборе между несколькими концепциями.

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

• Если есть гипотеза, но нет уверенности.

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

Когда исследования не нужны:

• Когда нет времени на реализацию результатов.

• Если продукт уже уходит в разработку или изменения невозможны, исследование не даст пользы, даже если выявит проблемы.

• Когда есть точные количественные данные.

Если, например, A/B-тест уже показал, что один вариант работает лучше, проводить дополнительные качественные исследования, чтобы «понять почему», может быть избыточно на текущем этапе.

• Когда цель исследования – просто «что-то исследовать».

Без ясной цели и конкретного вопроса исследование может превратиться в пустую активность без пользы. Оно не даст применимого результата.

• Когда создаётся MVP (Minimum Viable Product).

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

• Когда результат уже известен и решение принято.

Например, когда команда уверена в решении, дизайн согласован, всё внедрено и нет готовности ничего менять – тогда и исследовать нечего.

Исследования – не самоцель. Это инструмент принятия решений. Используйте их тогда, когда:

• есть неопределённость или спор в команде;

• вы ищете причину проблемы, а не только фиксируете факт;

• вам нужно оправдать выбор перед заказчиком или бизнесом;

• стоит задача проверить идею до запуска.

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

Глава 17
Когда нужны исследования для нового продукта

Разработка нового продукта – это путь, полный неопределённостей: от первоначальной идеи до запуска и дальнейшего роста. UX-исследования помогают минимизировать риски, понимая нужды пользователей, рынок и конкурентов на каждом этапе. Они не нужны «постоянно», но в ключевых моментах дают максимальную пользу, позволяя корректировать курс до того, как ошибки станут затратными.

В этой главе мы разберём пять ситуаций, когда исследования особенно ценны для нового продукта – от идеи до зрелого этапа. Для каждой опишем цели, вопросы, методы и выходные материалы. Мы также добавим быстрые ориентиры по выбору усилий и мини-чек-лист для старта. Это поможет вам интегрировать исследования в продуктовый цикл, опираясь на предыдущие главы о целях, задачах и методах. Помните: своевременные исследования экономят ресурсы и повышают шансы на успех.

Есть идея – исследуйте рынок и аудиторию

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

• Цель: понять потребности и проблемы целевой аудитории, оценить рынок и сформировать гипотезы продукта.

• Ключевые вопросы: какие задачи и боли у пользователей? Существует ли спрос и как люди закрывают потребность сейчас? Чем мы можем быть лучше альтернатив?

• Методы: кабинетные исследования (анализ источников), глубинные интервью (6–12), скрининговые опросы, анализ конкурентов и заменителей.

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

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

Перед запуском разработки – проверьте черновик

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

• Цель: подтвердить или скорректировать ключевые гипотезы перед тратой на разработку.

• Ключевые вопросы: понимают ли пользователи ценность и сценарии? Где барьеры в первом опыте? Что войдёт в минимально жизнеспособный продукт, а что – позже?

• Методы: прототипирование (низкой или средней детализации), модераторские юзабилити-тесты (5–8 сессий на сценарий), концепт-тесты, fake-door (симуляция функции), A/B-тесты на прототипах или лендингах, фокус-группы (при необходимости).

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

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

На этапе разработки – проверяйте бета-версию

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

• Цель: убедиться, что движемся в верном направлении, и исправить критичные UX-риски до релиза.

• Ключевые вопросы: рабочие сценарии проходят без подсказок? Какие дефекты или заторы тормозят конверсию? Что нужно оптимизировать до запуска?

• Методы: юзабилити-тесты на ранних сборках, тестирование прототипов или кликабельных версий, «собачья еда» (тестирование внутри команды), веб-аналитика и записи сессий (если доступно тестовое окружение).

• Выходные материалы: список UX-исправлений по приоритетам, список дефектов, метрики пилота, чек-лист готовности к релизу (решение о запуске или задержке).

Примечание: термины «альфа» и «бета» трактуются по-разному; здесь «бета» – предрелизная проверка на ограниченной аудитории. Например, сессии покажут, что кнопка оплаты скрыта – исправьте до финальной версии.

После запуска первой версии – проверяйте ранний продукт

После релиза фокус на реальных данных: как продукт работает в жизни.

• Цель: получить поведенческие данные от реальных пользователей и понять, насколько продукт решает задачу.

• Ключевые вопросы: как проходят ключевые воронки (активация, конверсия, удержание)? Что мешает повторному использованию? Какие функции давать следующими?

• Методы: продуктовая аналитика (воронки, когорты), NPS/CES/CSAT (опросы удовлетворённости), интервью или опросы активных и ушедших пользователей, карты кликов и тепловые карты, A/B-тестирование.

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

Например, аналитика покажет отток на втором дне – интервью раскроют «почему» и приведут к быстрому фиксу.

Этап развития и улучшения – непрерывное совершенствование

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

• Цель: адаптировать продукт к меняющимся нуждам и рынку, принимать решения об обновлениях.

• Ключевые вопросы: где узкие места и точки роста? Какие тренды появляются? Что обновлять, удалять или исследовать глубже?

• Методы: регулярные юзабилити-тесты новых функций, отслеживание метрик, кабинетные исследования трендов, интервью или дневниковые исследования, продуктовые опросы.

• Выходные материалы: квартальная карта возможностей (дерево решений или план), гипотезы с приоритетами (методы вроде ICE или RISE), решения по жизненному циклу функций.

Например, тренды покажут рост AI – исследуйте, как интегрировать в ваш продукт.

Быстрые ориентиры по выбору усилий

Выбор объёма исследований зависит от неопределённости и стоимости реализации. Вот простая матрица:

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

Мини-чек-лист перед стартом любого исследования

Перед запуском всегда проверьте:

• Какая управленческая цель и какое решение примем по итогам?

• Какие критерии подтверждения или опровержения гипотез?

• Какой минимальный метод даст ответ в срок (интервью, прототип, аналитика)?

• Кто и когда внедрит выводы?

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

Глава 18
Когда нужны исследования для работающего продукта

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

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

«Мне так кажется» – экспертиза без фактов

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

Цель: заменить предположения проверенными знаниями, прежде чем принимать значимые решения.

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

• Методы: быстрые проблемные интервью (5–8) и короткие тесты сценариев; перехваты в продукте (всплывающие вопросы с 1–2 пунктами); анализ конкурентов и заменителей для понимания ожиданий.

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

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

«Держать пульс» – регулярное обновление знаний

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

• Цель: не допускать устаревания понимания пользователя и контекста использования.

• Триггеры: команда заметно обновилась (новые продакт-менеджеры, дизайнеры, разработчики); последнее полевое исследование было шесть месяцев назад или больше.

• Методы и минимальная «гигиена»: ежемесячно 3–5 коротких интервью для открытия; ежеквартально – полевое наблюдение или просмотр сессий (тенинг или записи экрана); регулярный разбор обратной связи из поддержки и отзывов; базовая витрина метрик (воронки, удержание, принятие новых функций).

• Выходные материалы: живой репозиторий инсайтов, карта возможностей и рисков, обновлённые персоны и анализ «какую работу выполняет пользователь».

Это как регулярный check-up: помогает своевременно корректировать продукт под изменения в поведении аудитории.

Изменили или добавили функциональность – проверьте

Введение изменений – рискованный момент; исследования подтверждают, что новинка работает как надо.

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

• Триггеры: запускается крупная или сложная функция; меняется поведение существующей функции.

• Методы: юзабилити-тестирование на бета-версиях или под флагами функций; A/B-тесты (если есть трафик) и анализ воронок по новой функции; поведенческие записи (воспроизведение сессий), тестирование внутри команды; опрос после использования (короткие оценки удовлетворённости).

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

• Выходные материалы: список улучшений по приоритетам, чек-лист готовности к полному запуску (решение о продолжении или паузе).

Например, после добавления поиска тестирование покажет, если он интуитивен, – исправьте до массового использования.

Просели ключевые метрики – найдите причины

Падение показателей – сигнал тревоги; исследования помогают диагностировать и исправить.

• Цель: найти причины падения и пути восстановления показателей.

• Триггеры: снижение конверсии, вовлечённости, удержания или оценок удовлетворённости.

• Методы: аналитика для локализации (сегменты, когорты, пути пользователя); интервью или опросы ушедших или «остывших» пользователей; анализ тикетов поддержки, отзывов и низких оценок; просмотры сессий на проблемных шагах.

• Выходные материалы: карта причин и следствий проблем, гипотезы с приоритетами (методы вроде ICE или RISE), план экспериментов и сроки.

Например, если удержание упало, интервью раскроют, что новая функция запутала пользователей, – это даст план фикса.

Цикл исследований для работающего продукта

Для зрелого продукта исследования – часть цикла «построить – измерять – узнать». Ввели изменение – проверили – решили (масштабировать, исправить или откатить). Это непрерывный процесс: мониторьте метрики, реагируйте на триггеры и интегрируйте инсайты в разработку.

Мини-чек-лист перед стартом исследования

Перед любым исследованием проверьте:

• Какое управленческое решение примем по итогам?

• Какие критерии подтверждения или опровержения гипотез?

• Какой минимальный метод даст ответ в нужный срок?

• Кто внедрит выводы и когда?

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

Глава 19
Принципы проведения исследований: исследуйте с холодной головой

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

В этой главе мы разберём десять принципов, которые обеспечивают точность, эффективность и практическую пользу исследований. Каждый принцип включает объяснение «зачем», рекомендации по применению, примеры и антишаблоны (что не делать). Мы также добавим мини-шаблоны и чек-листы для удобства. Это продолжение идей из предыдущих глав о целях, задачах и методах, но с фокусом на этике и практике. Принципы помогут вам проводить исследования, которые не просто собирают данные, а приводят к обоснованным решениям. В конце главы подведём итог и покажем, как всё связывается.

Принцип 1: Исследования – инструмент, а не самоцель

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

Как применять: ставьте управленческий вопрос: «Какое решение примем по итогам?» (например, «Запускаем ли быстрый ввод в продукт в таком виде?»). Определяйте критерии успеха или провала заранее (метрики, поведенческие сигналы). Выбирайте минимальный метод, который даст ответ в срок. Фиксируйте решения в журнале решений: «что сделали – на каких данных – почему».

Антишаблоны: «Проведём опросы, потому что давно не проводили». «Нужно 100 респондентов, чтобы выглядело солидно» (объём не равен качеству).

Этот принцип обеспечивает, что исследования служат продукту, а не наоборот.

Принцип 2: Идём от проблемы, а не от решения

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

Как применять: сформулируйте проблему в терминах пользователя: «Пользователь не может/сложно/дорого сделать X в ситуации Y, потому что Z». Сбор данных – о проблеме, а не о «понравится ли наша функция». Генерируйте несколько гипотез решений и не привязывайтесь к первой. Используйте дерево возможностей и решений: «возможности – решения – эксперименты».

Мини-шаблон формулировки проблемы: для [сегмент/контекст] проблема в том, что [X], потому что [Y]. Это приводит к [бизнес-эффект]. Мы проверим [гипотеза] через [метод/метрика].

Принцип 3: Исследователь оперирует фактами, а не домыслами

Факты обеспечивают точность выводов, прозрачность и доверие команды. Без них исследования теряют ценность.

Как применять: триангулируйте источники: поведение (логи/видео), слова (интервью/опросы), результаты (метрики/A/B-тесты). Избегайте наводящих вопросов и «подталкивающих» формулировок. Документируйте источники: скриншоты, цитаты, отметки времени. Маркируйте уровень доказательности находки: анекдотический (единичный случай) – качественный (из опросов) – количественный (из аналитики).

Формулировка находки: «По результатам 7/8 сессий пользователи не замечают переключатель „Самовывоз/Доставка“; записи сессий и карта кликов подтверждают низкую видимость».

Принцип 4: Исследователь проверяет, а не подтверждает гипотезы

Подтверждающее смещение искажает результаты; проверка на опровержение даёт честную оценку рисков.

Как применять: заранее пропишите условия опровержения («функция провалилась, если…»). Планируйте тесты на поиск проблем, а не только на успех. Анализируйте негативные случаи не менее тщательно. При опровержении адаптируйте гипотезу или отклоняйте её, не «подгоняя» критерии.

Мини-чек-лист эксперимента:

• Цель и управленческое решение.

• Метрика результата + пороги «проходит/не проходит».

• Контрольные метрики (не навредили ли).

• План сбора и даты «заморозки» данных.

• Что делаем по каждому исходу.

Принцип 5: Метод зависит от задачи

Правильный метод экономит время и бюджет, давая именно те данные, которые нужны для решения.

Быстрый подбор «вопрос – метод»:

• «Почему не находят кнопку?» – модераторский юзабилити-тест, просмотр сессий.

• «Как часто используют?» – продуктовая аналитика, воронки.

• «Какая концепция понятнее?» – сравнительное тестирование прототипов.

• «Есть ли потребность?» – проблемные интервью, дневниковые исследования, симуляция функции.

• «Какой текст лучше?» – A/B-тест или тест сообщений с измерением времени чтения.

Ориентиры по масштабу (примерно):

• Юзабилити: 5–8 сессий на сценарий.

• Проблемные интервью: 8–15 до насыщения.

• Опросы: ≥ 100 валидных ответов на сегмент.

• A/B-тесты: статистическая мощность > 80% (рассчитайте заранее).

Принцип 6: Делаем продукт для пользователя, а не наоборот (эмпатия)

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

Как применять: создавайте карты эмпатии или проводите интервью о контексте: как люди живут с задачей. Учитывайте доступность по умолчанию (контраст, шрифты, фокус, озвучка). На тестах не обвиняйте людей; валидируйте прототип и тексты. Сегментируйте сценарии: новичок/возвращенец/эксперт; мобильный/десктоп/медленный интернет.

Правило языка: «Пользователь не смог выполнить задачу», а не «пользователь не понял».

Принцип 7: Проявляйте искренний интерес: спрашивайте «как делали», а не «что сделали бы если»

Прошлое поведение предсказывает будущее лучше, чем гипотетические сценарии.

Как применять: задавайте поведенческие вопросы: «Расскажите про последний раз, когда…», «Что пытались сделать? Что помешало? Что сделали дальше?». Просите показать артефакты: историю заказов, письма, скриншоты. Уточняйте контекст: место, время, устройство, помехи. Избегайте условностей: «Купили бы? Поставили бы 5 из 5?» – низкая надёжность.

Техника углубления: «И что было дальше?», «Почему именно так?», «Как приняли решение?» (осторожно с «5 почему» – не превращайте в допрос).

Принцип 8: Практики «холодной головы» в процессе

Чтобы сохранить объективность, следуйте практикам на каждом этапе.

До исследования: одностраничный бриф: цель – вопросы – решения/метрики – метод – сроки – риски – команда. Предварительная фиксация критериев (в Notion или аналогах). Скрипт с нейтральной лексикой, пробный запуск на 1–2 людях. Отбор респондентов: кого берём/исключаем (избегайте «друзей продукта»).

Во время: двое на сессии: ведущий + наблюдатель (для заметок и времени). Запись экрана/камеры/логов; отметки времени. Нейтральность: не спорить, не объяснять, не подсказывать. Сохраняйте паузы: люди думают медленнее, чем кажется.

После: кодовая таблица и метки находок; согласованность между экспертами (2 кодировщика). Синтез в материалы: карта проблем, последовательность сценариев, приоритизация (воздействие/усилия). Одностраничный отчёт и короткая демонстрация для команды. Запись находок – в репозиторий, решений – в журнал.

Принцип 9: Частые ловушки и как их избегать

• Ведущие вопросы – перепишите на нейтральные («Расскажите…» вместо «Удобно ли вам…»).

• Смещение в отборе (только «фанаты») – нормируйте доли сегментов.

• Смещение ведущего – чёткий скрипт, внешние ведущие на спорных темах.

• Подгонка порогов после факта – фиксируйте заранее.

• Отчёт без действий – завершайте планом изменений с владельцами и сроками.

Принцип 10: Короткие чек-листы

Перед стартом: какое управленческое решение? Что подтвердит/опровергнет (метрики, пороги)? Какой минимальный метод и объём? Кого и как отбираем? Как фиксируем данные и защищаем приватность?

Во время: соблюдаем скрипт и нейтральность. Фиксируем факты (цитаты, отметки времени, материалы). Проводим мини-анализ после 2–3 сессий: что поправить.

После: синтез не позже 48 часов. Выводы связаны с данными (ссылки/файлы). План внедрения + владельцы + сроки + метрики эффекта.

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

Глава 20
Шаги проведения любого исследования

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

Этап 1: Подготовка

Подготовка – основа успеха: здесь мы определяем, зачем исследование, что именно изучим и как. Это предотвращает ненужные траты времени и ресурсов.

1.1. Разобраться с бизнес-контекстом

• Какой сигнал мы видим (метрика, жалобы, предположение)?

• Какое управленческое решение нужно принять по итогам?

• Есть ли возможность для внедрения (время, бюджет, ресурсы)?

• Стоит ли вообще проводить исследование сейчас (рентабельность)?

Материал: краткий одностраничный обзор (цель – решение – метрики – сроки – команда – риски).

1.2. Сформулировать цель и задачи исследования

• Цель: что хотим понять или решить.

• Задачи: на какие вопросы ответим, чтобы достичь цели.

• Критерии успеха или провала: что подтвердит или опровергнет предположения.

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

1.3. Выписать предположения и ключевые вопросы

• П1, П2…: чёткие, проверяемые, с ожидаемым эффектом.

• Ключевые вопросы: «где проблемы», «почему», «что мешает или помогает».

Пример предположения: П1: «Низкая видимость способа оплаты X снижает конверсию не менее чем на 5%».

1.4. Выбрать метод под задачу

• «Почему не находят?» – модераторский юзабилити-тест, просмотр сессий.

• «Сколько раз используют?» – аналитика событий или воронок.

• «Какая концепция понятнее?» – сравнительное тестирование прототипов.

• «Есть ли потребность?» – проблемные интервью или симуляция функции.

Правило: минимальный метод, который даст ответ в срок.

1.5. Найти респондентов

• Профиль целевой аудитории, квоты по сегментам (новички/опытные, устройства и т. п.).

• Отбор: кого берём или исключаем.

• Вознаграждение, согласия на обработку данных и запись.

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

Этап 2: Проведение исследования

На этом этапе переходим к действию: собираем данные в контролируемой среде.

2.1. Пригласить пользователей

• Каналы: база данных, панели для набора, всплывающие вопросы в продукте, email.

• Расписание: подтверждения, напоминания, инструкции.

2.2. Провести и зафиксировать результаты

Пилот 1–2 сессии, затем основная серия.

На сессии: ведущий + наблюдатель; запись экрана или видео, отметки времени, заметки.

Нейтральность: не подсказывать, не оправдываться за продукт.

Для опросов: валидность вопросов, логика ветвлений, проверка на «скоростных» респондентов.

Для аналитики: корректность событий, тестовые пользователи, метки экспериментов.

Материалы: сырые записи и логи, заметки по шаблону, скриншоты или артефакты, таблица наблюдений (радужная таблица или кодовая книга).

Этап 3: Работа с результатами

Здесь данные превращаются в знания и действия: анализируем, презентуем и внедряем.

3.1. Проанализировать и сделать выводы

• Очистка и кодирование данных; группировка проблем и паттернов.

• Триангуляция: слова (интервью) ' поведение (записи) ' цифры (метрики).

• Оценить серьёзность проблем и влияние на метрики.

• Сформировать рекомендации с ожидаемым эффектом.

Формат находки: «7/8 не замечают переключатель „Самовывоз/Доставку“ – +12 сек на задачу; карты кликов подтверждают низкую видимость. Рекомендуем поднять в первый экран, изменить стиль контроля».

3.2. Презентовать заинтересованным сторонам

• Структура: сигнал – данные – находка – рекомендация – эффект/риски.

• Демонстрационные видео или скринкасты с отметками времени.

• Одностраничное резюме для быстрых решений.

3.3. Применить (внедрение)

• Решения фиксируем в журнале решений: что, зачем, на каких данных.

• Владелец задачи, срок, ресурс.

• Если нужны эксперименты – план A/B-теста с порогами и контрольными метриками.

• После выката – измерять эффект, закрыть петлю обратной связи.

Материалы: отчёт или презентация, список изменений с приоритетами, план экспериментов, обновлённые метрики.

Чек-листы

Перед стартом:

• Есть управленческая цель и возможность для внедрения.

• Предположения и критерии подтверждения или опровержения зафиксированы.

• Метод минимален и соотнесён со сроками.

• Форма отбора, гид, согласия готовы.

Во время:

• Проведён пилот; сценарий откорректирован.

• Все сессии записаны, заметки стандартизированы.

• Нейтральная модерация, без подсказок.

После:

• Находки опираются на факты (цитаты/отметки времени/даты выгрузок).

• Рекомендации приоритизированы (воздействие ' усилия).

• Владелец внедрения и срок согласованы.

• Назначена дата пост-измерения эффекта.

Пример

Сигнал: падение конверсии оплаты на мобильном.

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

1. Подготовка

Сначала определяем цель: понять, почему падает конверсия оплаты на мобильных, чтобы выбрать изменения в интерфейсе или текстах перед следующим обновлением. Формулируем основное предположение (П1): «Невидимый способ оплаты X (например, через определённый банк) снижает конверсию не менее чем на 5%». Выбираем метод: 6 модераторских сессий юзабилити-теста (где ведущий наблюдает за действиями пользователей) плюс просмотр 50 записей сессий из аналитики. Сегменты аудитории – по устройствам: половина на iOS, половина на Android, чтобы учесть различия платформ. Готовим одностраничный обзор с целью, предположениями, сценарием теста и формой согласия на запись.

2. Проведение

Приглашаем пользователей через базу данных или панели набора, объясняем задачу: «Оформите заказ на мобильном, как будто покупаете товар». Начинаем с пилотных 2 сессий, чтобы откорректировать сценарий (например, если вопросы неудобны). Затем проводим основные 6 сессий: пользователи выполняют задачу, а мы фиксируем отметки времени на ошибках (где они запнулись или вернулись назад). Параллельно анализируем тепловые карты (где кликают чаще всего) из инструментов аналитики, чтобы увидеть общие паттерны. Всё записываем: экран, голос и заметки наблюдателя.

3. Анализ и внедрение

В данных видим находку: в 5 из 6 сессий пользователи не замечают переключатель способов оплаты, из-за чего тратят лишнее время или уходят. Рекомендация: поднять этот переключатель в первый экран страницы и изменить тексты для ясности (например, добавить «Выберите удобный способ»). Чтобы проверить, запускаем A/B-тест: половина пользователей видит старую версию, половина – новую; целевой прирост конверсии +3–5%. Контрольные метрики – количество возвратов на предыдущий шаг и ошибок платежей, чтобы убедиться, что не навредили. По итогам – план внедрения со сроками и ответственными.

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