Исследование прототипа часто воспринимают как момент истины: мы показываем пользователям интерфейс, даём несколько заданий, наблюдаем за действиями и собираем обратную связь. После пяти, десяти или двадцати сессий у команды появляется внушительный список замечаний — непонятная кнопка, неочевидная навигация, спорная формулировка, лишний шаг. Кажется, что основная работа уже выполнена и остаётся перенести найденные проблемы в бэклог.
На практике именно здесь начинается наиболее сложная часть исследования — анализ результатов прототипа.
Само тестирование даёт нам материал для выводов, но не готовые выводы. Пользователь может сказать, что экран ему понятен, и через минуту не найти нужную функцию. Может предложить добавить кнопку, хотя настоящая причина затруднения находится совсем в другой части сценария. А проблема, встретившаяся только у одного участника, иногда оказывается значительно серьёзнее замечания, которое повторили пятеро.
Поэтому количество собранных комментариев само по себе мало говорит о качестве исследования. Важно понять, что именно произошло, почему это произошло, насколько наблюдение устойчиво и какое значение оно имеет для продукта.
Исследование прототипа позволяет проверить, понимают ли пользователи структуру и логику интерфейса, могут ли выполнить предполагаемые сценарии, где совершают ошибки и насколько интерфейс соответствует их ожиданиям. Оно помогает обнаруживать проблемы до того, как команда потратит ресурсы на полноценную разработку.
Но у метода есть границы. Результаты тестирования прототипа нельзя автоматически переносить на всю пользовательскую аудиторию, особенно при небольшой выборке. Прототип не всегда воспроизводит скорость, технические ограничения и контекст реального продукта. Наконец, исследование показывает, как пользователи взаимодействовали с конкретной версией решения в заданных условиях, а не даёт универсального ответа на вопрос, каким должен быть продукт.
В работе с исследованиями клиентов Тестографа я придерживаюсь простого разделения: наблюдение → интерпретация → продуктовое решение.
Например, «четыре участника после оформления заказа пытались нажать на его номер» — это наблюдение. «Пользователи воспринимают номер заказа как интерактивный элемент» — уже интерпретация. А «сделать номер заказа ссылкой» — продуктовое решение. Последнее не следует автоматически из первых двух: возможно, правильнее изменить визуальное оформление, добавить отдельную кнопку или пересмотреть весь следующий шаг сценария.
Смешение этих уровней — одна из самых частых причин слабых исследовательских отчётов. Команда слишком быстро переходит от поведения отдельного респондента к конкретному изменению интерфейса и теряет возможность разобраться в причине проблемы.
В этой статье разберём другой подход: как превратить результаты исследования прототипа в систему доказательств. Посмотрим, как анализировать выполнение заданий, оценки и открытые ответы, работать с небольшими выборками, объединять количественные и качественные данные, определять серьёзность UX-проблем и формулировать выводы так, чтобы продуктовая команда понимала не только что изменить, но и почему это изменение действительно обосновано.
Материал будет полезен UX/UI-дизайнерам, продуктовым менеджерам, UX-исследователям, аналитикам и разработчикам — всем, кому приходится принимать решения на основании пользовательских исследований. Причём основное внимание мы уделим не проведению теста как такового, а тому этапу, на котором результаты исследования превращаются в решения о следующей итерации продукта.
После завершения исследования у нас обычно остаются данные нескольких типов: результаты выполнения заданий, ответы на вопросы, комментарии участников и заметки исследователя. Иногда к ним добавляются записи интервью, время прохождения сценариев, клики и другие поведенческие показатели.
Первая ошибка, которую здесь легко допустить, — объединить всё это в одну категорию «обратная связь пользователей». С точки зрения анализа это разные источники данных, и доказательная ценность у них тоже разная.
Поведение, ответы и комментарии — не одно и то же
Представим, что мы тестируем прототип личного кабинета. Участнику нужно найти выставленный счёт, скачать его и вернуться к списку документов.
Во время выполнения задания он сначала открывает раздел «Финансы», возвращается назад, переходит в «Документы», несколько секунд просматривает страницу и только после этого находит нужный счёт.
После задания мы спрашиваем:
Пользователь ставит 5 из 5 и говорит: «В целом всё понятно».
Если посмотреть только на ответ, можно решить, что сценарий работает хорошо. Если посмотреть на поведение, картина становится сложнее: пользователь первоначально выбрал неправильный раздел и потратил время на поиск.
Поэтому я обычно разделяю результаты исследования как минимум на три уровня:
Эти данные не обязаны совпадать. Более того, именно расхождения между ними часто оказываются наиболее интересной частью исследования.
Пользователь может успешно выполнить задание, но поставить низкую оценку удобству. Или, наоборот, совершить несколько ошибок и после этого сказать, что интерфейс простой. Задача исследователя — не выбрать «правильный» источник, а разобраться, почему возникло такое расхождение.
Количественные и качественные данные
Следующее полезное разделение — на количественные и качественные данные.
К количественным можно отнести:
Такие показатели помогают увидеть масштаб и сравнивать результаты. Например, мы можем обнаружить, что задание № 1 успешно выполнили 9 из 10 участников, а задание № 3 — только 5 из 10.
Но сам по себе показатель 5 из 10 ещё не объясняет, почему возникла проблема.
Здесь становятся важны качественные данные: комментарии участников, наблюдения исследователя, объяснения действий, ответы на открытые вопросы. Они помогают восстановить контекст и сформулировать гипотезу о причине затруднения.
Например, пять участников не смогли найти функцию экспорта. Из комментариев и наблюдений выясняется, что четверо искали её внутри меню «Отчёты», тогда как в прототипе экспорт расположен в настройках проекта.
Теперь у нас появляется гораздо более содержательный результат, чем просто «50% участников не нашли экспорт». Мы видим возможный конфликт между пользовательской ментальной моделью и архитектурой интерфейса.
Какие события стоит фиксировать
Успех или неуспех задания — слишком грубое разделение, если использовать его отдельно. Между этими состояниями может происходить множество событий, которые помогают понять качество сценария.
При анализе прототипов я обращаю внимание на несколько типов поведения.
Каждое такое событие — ещё не UX-проблема. Это наблюдение, которое требует контекста.
Если участник один раз вернулся на предыдущий экран, это может быть нормальной частью изучения интерфейса. Если семь из восьми участников в одном месте делают одинаковый неверный переход, перед нами уже устойчивый паттерн, который стоит изучить отдельно.
Не пытайтесь сразу объяснять увиденное
На этом этапе особенно полезно соблюдать принцип, о котором я говорил во введении: сначала фиксировать наблюдение и только потом переходить к интерпретации.
Сравним две записи исследователя:
И:
Первая запись уже содержит интерпретацию. Мы решили за пользователя, что причиной поведения было непонимание навигации.
Вторая фиксирует последовательность действий. Позже её можно сопоставить с поведением остальных участников, ответами на вопросы и комментариями самого пользователя.
Такой подход снижает риск подтверждать собственные ожидания. Если дизайнер заранее считает навигацию слабым местом прототипа, любое неправильное действие легко принять за доказательство этой гипотезы. Но причина может находиться в терминологии, визуальной иерархии, формулировке задания или даже в ограничениях самого прототипа.
Что делать, если слова и действия противоречат друг другу
В исследованиях прототипов регулярно возникает ситуация: участник испытывает заметные трудности, но после задания оценивает интерфейс положительно.
Это не означает, что пользователь «ответил неправильно». Его оценка отражает субъективное восприятие опыта, а наблюдение — фактическое поведение в конкретном сценарии. Нам нужны оба источника.
Например:
Вывод «пользователи не понимают интерфейс» здесь был бы слишком сильным. Но и вывод «проблемы нет, потому что оценка 4,6» тоже преждевременный.
Более аккуратная интерпретация: при первом прохождении сценария расположение функции не всегда соответствует ожиданиям пользователей, однако большинство участников быстро восстанавливаются после первоначальной ошибки.
Это уже значительно полезнее для продуктовой команды. Мы понимаем не только наличие затруднения, но и его характер.
Именно поэтому анализ исследования прототипа стоит начинать не с составления списка пожеланий пользователей, а с систематизации разных типов данных. Нам нужно отдельно увидеть, что произошло, насколько часто это происходило, что об этом говорили участники и какие последствия это имело для выполнения сценария.
На следующем этапе можно переходить к вопросу, который на первый взгляд относится к подготовке исследования, но напрямую определяет качество анализа: какие гипотезы, критерии успешности и показатели нужно сформулировать ещё до того, как первый участник увидит прототип.
Качество анализа во многом определяется ещё до того, как первый участник увидит прототип. Если команда заранее не договорилась, что именно хочет проверить, после исследования легко получить десятки наблюдений, комментариев и оценок, которые сложно связать с конкретными продуктовыми вопросами.
Поэтому подготовку к анализу я начинаю с исследовательских вопросов. Не с анкеты и не со списка заданий, а с того, какую неопределённость мы хотим уменьшить.
Например, вопрос «Удобен ли новый личный кабинет?» слишком широкий. Что именно считать удобством? Возможность быстро найти нужный раздел? Понимание терминов? Успешное выполнение ключевых сценариев? Субъективную оценку?
Гораздо полезнее сформулировать несколько проверяемых вопросов:
Теперь для каждого вопроса можно определить, какие данные будут доказательством.
Связка «гипотеза → задание → наблюдение → вопрос → показатель»
В проектах, связанных с исследованиями клиентов Тестографа, я стараюсь выстраивать анализ по одной цепочке:
Допустим, команда переработала страницу управления подпиской.
Показатели: успешность выполнения, количество неверных переходов, необходимость помощи и субъективная оценка сложности.
В результате одна гипотеза проверяется сразу несколькими типами данных. Если участник успешно выполнил задачу, но долго искал нужный раздел и низко оценил понятность сценария, мы не теряем эту информацию за бинарным показателем «задание выполнено».
Определите критерии успешности заранее
Одна из наиболее полезных практик — ещё до исследования записать, что будет считаться успешным выполнением каждого задания.
Это кажется очевидным, пока сценарий не допускает несколько вариантов прохождения.
Например, пользователь должен найти документ. Один участник открывает нужный раздел сразу. Второй сначала переходит в другой раздел, возвращается и затем находит документ. Третий достигает цели только после подсказки модератора.
Если критериев нет, после исследования команда может записать всех троих как успешно выполнивших задание. Формально это правда: каждый в итоге дошёл до результата. Но с исследовательской точки зрения их опыт различается.
Поэтому полезно заранее определить несколько состояний:
Отдельно можно отмечать выполнение с помощью модератора. Если подсказка фактически сообщает пользователю следующий шаг, такой результат не стоит приравнивать к самостоятельному успеху.
Не подменяйте исследовательский вопрос метрикой
Есть и обратная проблема: команда заранее выбирает показатели, но не определяет, зачем они нужны.
Например, решает измерять время выполнения каждого задания. После исследования появляется таблица: 42 секунды, 55 секунд, 38 секунд, 71 секунда.
Что означает 55 секунд? Это хорошо или плохо?
Без контекста ответить невозможно.
Время становится полезной метрикой, если связано с исследовательским вопросом или сравнением. Например, мы проверяем, сокращает ли новая версия прототипа количество действий в регулярном рабочем сценарии. Тогда время прохождения может быть важным дополнительным сигналом.
Но если пользователь впервые знакомится со сложным интерфейсом и внимательно читает информацию, более длительное выполнение само по себе не свидетельствует о UX-проблеме.
Поэтому я стараюсь задавать простой вопрос для каждого собираемого показателя:
Какое решение мы сможем принять, когда получим это значение?
Если убедительного ответа нет, возможно, показатель вообще не нужен.
Заранее определите, что будет опровергать гипотезу
Исследования особенно подвержены подтверждающему смещению. Команда уже вложилась в новый прототип, поэтому естественно искать признаки того, что решение работает.
Снизить этот риск помогает заранее сформулированный критерий опровержения.
Допустим, гипотеза звучит так:
До исследования можно определить признаки, которые заставят нас усомниться в гипотезе: участники систематически ищут отчёты в другом разделе, не могут объяснить назначение «Аналитики» или интерпретируют название иначе, чем предполагала команда.
Это дисциплинирует последующий анализ. Мы не выбираем из результатов только удобные подтверждения, а проверяем данные относительно заранее определённых ожиданий.
Не превращайте исследование в проверку всего прототипа
Ещё одна распространённая ситуация — желание использовать каждую сессию максимально эффективно. Если участник уже пришёл, хочется показать ему десять экранов, проверить пятнадцать функций и задать несколько десятков вопросов.
В итоге исследование расширяется настолько, что его результаты становится трудно анализировать.
Для прототипа полезнее определить ограниченный набор критических сценариев и исследовательских вопросов. Особенно если команда находится на ранней стадии проектирования.
Если главный вопрос звучит как «понимает ли пользователь новую модель создания проекта?», не обязательно одновременно подробно оценивать тексты подсказок, расположение второстепенных настроек и внешний вид страницы профиля.
Чем точнее исследовательский фокус, тем проще отличить значимые результаты от случайных комментариев.
Сначала вопрос — потом данные
Самая сложная ситуация для аналитика возникает не тогда, когда данных мало, а когда их много, но непонятно, зачем они были собраны.
Десятки оценок, сотни комментариев и подробные записи поведения могут создать ощущение основательного исследования. Однако без исходных вопросов команда рискует анализировать то, что сильнее всего бросается в глаза, а не то, что действительно важно для продукта.
Поэтому анализ результатов прототипа фактически начинается ещё на этапе проектирования исследования. Мы заранее определяем, какие гипотезы проверяем, какое поведение считаем значимым, какие вопросы задаём и по каким признакам будем судить о результате.
Когда эта структура есть, следующий этап становится гораздо проще: результаты отдельных участников можно привести к единому формату и подготовить данные к системному анализу.
После проведения последних сессий возникает соблазн сразу перейти к выводам. Особенно если некоторые проблемы повторялись настолько явно, что команда заметила их ещё во время тестирования. Но я стараюсь не начинать анализ с формулировки инсайтов. Сначала результаты нужно привести к единой структуре.
Это важный промежуточный этап. Без него исследователь невольно начинает придавать больше значения самым ярким участникам, необычным комментариям или последним проведённым сессиям. Хорошо подготовленные данные позволяют посмотреть на исследование целиком.
Соберите данные по каждому участнику
Для каждого респондента полезно сохранить одинаковый набор информации: какие задания он выполнял, достиг ли цели, где ошибался, какие действия совершал, что говорил во время прохождения и как отвечал на вопросы после задания.
Допустим, мы проверяем сценарий создания нового проекта. Один участник сразу выбирает нужную кнопку, второй сначала открывает существующий проект, третий ищет создание проекта в меню профиля, а четвёртый находит правильный путь только после подсказки.
Если заметки исследователя сделаны в свободной форме, сравнить эти случаи будет трудно. Поэтому после исследования я привожу записи к единой логике: результат задания, последовательность значимых действий, ошибки, помощь модератора, комментарии и ответы на вопросы.
При этом не нужно записывать каждый клик. Цель подготовки данных — не создать стенограмму взаимодействия, а сохранить события, которые помогают ответить на исследовательские вопросы.
Разделите успешное, частично успешное и неуспешное выполнение
Бинарная схема «выполнил / не выполнил» часто скрывает существенную часть пользовательского опыта.
Представим двух участников. Первый сразу находит кнопку «Создать проект» и завершает сценарий. Второй открывает три неправильных раздела, несколько раз возвращается назад и только через две минуты самостоятельно находит нужную кнопку.
Оба формально выполнили задание. Но делать из этого вывод, что сценарий одинаково понятен обоим, нельзя.
Поэтому я обычно отдельно отмечаю полный успех и частичный успех. К последнему можно относить ситуации, когда человек достиг цели, но столкнулся с существенными затруднениями.
Важно определить такие правила одинаково для всех участников. Нельзя считать три неверных перехода допустимыми для одного респондента и критическими для другого только потому, что второй показался исследователю менее уверенным.
Отдельно отмечайте помощь модератора
Подсказки во время исследования заслуживают особого внимания.
Иногда модератор задаёт нейтральный вопрос: «Что бы вы сделали дальше?» Такая реплика помогает участнику продолжить рассуждение, но практически не раскрывает правильный путь.
Совсем другая ситуация — подсказка вроде: «А вы смотрели в разделе настроек?» После неё пользователь действительно может завершить сценарий, однако считать это самостоятельным выполнением уже нельзя.
Если такие эпизоды не отмечать отдельно, результаты окажутся искусственно лучше. В отчёте появится высокий процент успешных выполнений, хотя часть участников достигла цели только благодаря вмешательству исследователя.
Кроме того, сама необходимость подсказки является данными. Если модератору регулярно приходится вмешиваться в одном и том же месте, это может указывать на серьёзное препятствие в сценарии.
Не удаляйте ошибки после успешного выполнения
Ещё одна распространённая потеря данных происходит, когда исследователь фиксирует только конечный результат.
Пользователь нашёл функцию — значит, задание выполнено. Но перед этим он мог открыть несколько разделов, попытаться нажать на неинтерактивный элемент или неверно понять термин.
Эти действия особенно важны при тестировании прототипа. Они показывают ожидания пользователя.
Если несколько участников нажимают на название карточки, хотя дизайнер предполагал переход только через кнопку внутри неё, проблема может быть не в самих пользователях и даже не обязательно в кнопке. Возможно, внешний вид карточки создаёт ожидание, что вся область интерактивна.
Поэтому при подготовке результатов стоит сохранять не только финальный статус задания, но и путь к нему.
Работайте с пропусками отдельно от отрицательных результатов
Не каждый отсутствующий ответ означает неуспех.
Участник мог не выполнить задание из-за технической ошибки прототипа. Исследование могло закончиться раньше времени. Какой-то вопрос могли случайно пропустить. Иногда определённый сценарий вообще не применим к конкретному сегменту аудитории.
Такие случаи нельзя автоматически записывать в категорию «не справился».
Если восемь человек выполнили задание, один не выполнил, а у одного прототип перестал работать, база для анализа — девять валидных наблюдений, а не десять.
Это особенно важно при небольших выборках, где один участник способен заметно изменить итоговое соотношение результатов.
Сохраняйте контекст возникновения проблемы
Комментарий «непонятно» почти бесполезен без контекста.
Что именно было непонятно? Название кнопки? Результат действия? Следующий шаг? Разница между двумя вариантами? Или пользователь вообще говорил о содержании страницы, а не об интерфейсе?
Поэтому при обработке открытых ответов и заметок я стараюсь связывать каждый значимый комментарий с конкретным сценарием и моментом взаимодействия.
Вместо записи:
Гораздо полезнее сохранить:
Во втором случае команда получает наблюдение, которое можно проверить на других участниках и связать с конкретным элементом прототипа.
Отделяйте слова пользователя от заметок исследователя
Во время сессии мы постоянно интерпретируем происходящее. Это нормально, но в исходных данных важно понимать, где заканчиваются слова участника и начинается наша трактовка.
Например:
Разница кажется небольшой, но при последующем анализе она принципиальна. Если несколько интерпретаций начинают восприниматься как прямые цитаты или факты, вывод постепенно становится убедительнее, чем позволяют исходные данные.
По этой же причине я не рекомендую слишком рано переписывать сырые наблюдения красивым языком отчёта. На этапе подготовки важнее точность, чем презентабельность.
Не очищайте данные от противоречий
При обработке результатов иногда хочется привести их к аккуратной истории. Например, большинство участников успешно выполняют сценарий, но один опытный пользователь неожиданно совершает серьёзную ошибку. Такой случай легко списать на случайность.
Противоречия часто помогают обнаружить границы нашего объяснения. Возможно, проблема характерна только для определённого сегмента. Возможно, опытные пользователи переносят в новый интерфейс привычки из другого продукта. А возможно, этот участник действительно оказался исключением.
На этапе подготовки данных нам ещё не обязательно знать ответ. Достаточно сохранить наблюдение и не исключать его только потому, что оно портит красивую закономерность.
Что должно получиться перед началом анализа
После подготовки результатов у исследователя должна появиться возможность восстановить опыт каждого участника и одновременно сравнить его с остальными.
Для каждого ключевого сценария мы должны понимать: достиг ли пользователь цели, сделал ли это самостоятельно, какие препятствия встретил, где отклонялся от предполагаемого пути, что говорил во время взаимодействия и как оценил опыт после выполнения.
Только после этого имеет смысл переходить к подсчётам и поиску закономерностей.
Хорошая подготовка данных может показаться технической работой, но именно она защищает анализ от впечатлений в духе «кажется, почти все справились» или «многим не понравилась эта кнопка». Вместо воспоминаний о сессиях у нас появляется структурированный материал, на основании которого можно проверить каждое утверждение.
Следующий шаг — анализ выполнения пользовательских сценариев: как оценивать успешность заданий, ошибки, время выполнения и отказы так, чтобы количественные показатели помогали разобраться в поведении пользователей, а не создавали ложное ощущение точности.
Когда результаты приведены к единой структуре, можно переходить к анализу пользовательских сценариев. На этом этапе нас интересует не только финальный ответ «справился или не справился», но и то, каким способом участник пришёл к результату.
Один пользователь выполняет задание за несколько очевидных действий. Другой достигает той же цели после нескольких ошибок. Третий останавливается в середине сценария. Если учитывать только конечный результат, первый и второй участники окажутся в одной категории, хотя с точки зрения качества интерфейса их опыт существенно различается.
Task Success Rate как базовая метрика
Один из наиболее понятных показателей при исследовании прототипа — доля успешно выполненных заданий, или Task Success Rate.
Если восемь из десяти участников самостоятельно выполнили сценарий, показатель успешности составит 80%. Такая метрика удобна для быстрого сравнения нескольких заданий или разных вариантов прототипа.
Но здесь есть важное условие: критерий успеха должен быть определён заранее.
Допустим, участнику предлагают изменить способ получения уведомлений. Он самостоятельно находит настройки, выбирает нужный вариант, но не замечает кнопку сохранения и выходит со страницы.
Считать ли задание выполненным?
Ответ зависит от того, какую гипотезу мы проверяем. Если нас интересует обнаружение настроек, пользователь справился. Если проверяем полный сценарий изменения параметров, задача не завершена.
Поэтому Task Success Rate полезен не сам по себе, а только вместе с точным определением того, что считается достижением цели.
Полный и частичный успех
В реальных исследованиях я предпочитаю не ограничиваться двумя состояниями. Между успехом и неуспехом часто существует промежуточная зона.
Частичным успехом можно считать ситуацию, когда пользователь достиг цели, но столкнулся с заметными препятствиями: сделал несколько неверных переходов, долго искал элемент, неправильно понял промежуточный экран или нуждался в небольшой подсказке.
Представим, что девять из десяти участников в итоге нашли функцию экспорта. На первый взгляд результат отличный.
Однако при более подробном анализе оказывается, что только пятеро нашли её сразу, трое сначала искали в другом разделе, а одному потребовалась помощь модератора.
Фраза «90% пользователей успешно нашли экспорт» скрывает существенную часть результатов. Намного полезнее показать, что самостоятельный прямой путь оказался очевиден только для части участников.
Ошибки нужно анализировать по типу, а не только считать
Количество ошибок — ещё один показатель, который легко использовать механически.
Если один сценарий вызывает в среднем больше ошибочных действий, чем другой, это повод обратить на него внимание. Но само число ошибок мало объясняет продуктовой команде.
Гораздо важнее понять, какие именно ошибки повторяются.
Например, пользователи могут систематически:
Если одинаковая ошибка появляется у нескольких участников независимо друг от друга, мы получаем гораздо более сильный сигнал, чем просто повышенное среднее количество ошибочных действий.
Обращайте внимание на восстановление после ошибки
Не каждая ошибка одинаково серьёзна.
Представим два варианта прототипа. В первом пользователь выбирает неправильный раздел, сразу замечает это и возвращается назад. Во втором он совершает неправильное действие, не понимает, что произошло, и оказывается в состоянии, из которого не может продолжить сценарий.
Формально в обоих случаях совершена одна ошибка. Но последствия совершенно разные.
Поэтому я отдельно смотрю на восстанавливаемость: способен ли пользователь самостоятельно понять, что произошло, и продолжить выполнение задания.
Интерфейс не обязан полностью исключать ошибки. Для многих продуктов это практически невозможно. Но он должен помогать пользователю заметить ошибку, понять её последствия и восстановиться.
Время выполнения: полезная, но опасная метрика
Время прохождения задания выглядит объективным показателем, поэтому команды нередко придают ему слишком большое значение.
Допустим, один участник справился за 40 секунд, другой — за 70. Можно ли заключить, что первому интерфейс был понятнее?
Не обязательно.
Второй пользователь мог внимательнее читать текст. Мог рассуждать вслух по просьбе модератора. Мог впервые сталкиваться с подобным продуктом. Наконец, задержка могла быть связана с самим интерактивным прототипом.
Поэтому время особенно полезно в сравнительном анализе: например, когда две версии одного сценария тестируются в сопоставимых условиях или когда для продукта действительно критична скорость выполнения регулярной операции.
При небольшом качественном исследовании я бы не использовал несколько дополнительных секунд как самостоятельное доказательство UX-проблемы.
Гораздо интереснее посмотреть, где именно пользователь теряет время.
Если пять участников задерживаются на одном экране, перечитывают подписи и пробуют несколько вариантов, это уже содержательное наблюдение.
Возвраты и неверные переходы показывают ожидания
Ошибочный переход часто воспринимается исключительно как негативный результат. Но для исследователя он ещё и показывает ментальную модель пользователя.
Допустим, функция управления доступом находится в разделе «Настройки проекта». Большинство участников сначала открывают «Команду».
Можно сделать поверхностный вывод: пользователи выбирают неправильный раздел.
Но более интересный вопрос звучит иначе: почему раздел «Команда» кажется им правильным местом?
Возможно, управление доступом концептуально связано для пользователей не с настройками проекта, а с людьми. Тогда повторяющийся неправильный переход становится источником информации об их ожиданиях.
Именно поэтому я стараюсь не рассматривать отклонение от предполагаемого дизайнером пути как ошибку автоматически. Иногда пользовательский путь вполне логичен, а проблема находится в архитектуре продукта.
Отказ от задания — особенно сильный сигнал
Если участник прекращает выполнение сценария и говорит, что не знает, что делать дальше, такой случай стоит анализировать отдельно.
Важно установить точку отказа.
Пользователь не нашёл нужную функцию? Не понял термин? Побоялся нажать кнопку из-за возможных последствий? Решил, что нужной возможности вообще нет?
Например, два участника могут отказаться от одного задания по совершенно разным причинам. Первый не замечает нужный элемент. Второй замечает его, но считает, что действие удалит данные.
В отчёте оба случая могут получить статус «неуспех», однако продуктовые проблемы здесь разные: в одном случае речь может идти о заметности элемента, в другом — о понимании последствий действия.
Не ищите идеальный пользовательский путь
При анализе прототипа легко начать сравнивать поведение участников с маршрутом, который команда считает правильным.
Пользователь должен открыть раздел A, выбрать пункт B и нажать кнопку C. Любое отклонение начинает восприниматься как проблема.
Но задача исследования не в том, чтобы проверить, насколько точно люди повторяют задуманный дизайнером сценарий. Нас интересует, могут ли они понятным для себя способом достичь цели.
Если пользователь выбирает другой путь, но этот путь логичен, короток и приводит к правильному результату, возможно, мы обнаружили не UX-проблему, а альтернативный сценарий, который стоит поддержать.
Анализируйте сценарий как последовательность сигналов
В своей практике я стараюсь смотреть на выполнение задания сразу через несколько признаков: достигнута ли цель, потребовалась ли помощь, возникали ли ошибки, насколько быстро пользователь восстанавливался, были ли характерные паузы и что происходило перед отказом.
Например, результат исследования может выглядеть так: большинство участников достигли цели, но несколько человек сначала выбрали один и тот же неправильный раздел. Все они самостоятельно исправили ошибку, а после первого прохождения повторный сценарий выполняли без затруднений.
Это уже позволяет сформулировать гораздо более точную гипотезу: проблема, вероятно, связана не с общей сложностью функции, а с её обнаружением при первом знакомстве.
Такой вывод намного полезнее утверждения «у пользователей возникают проблемы с навигацией».
Задача анализа пользовательских сценариев — не собрать как можно больше метрик. Нам нужно восстановить структуру взаимодействия: где пользователь ожидал увидеть нужное действие, где отклонился от сценария, смог ли заметить ошибку и что помогло или помешало ему достичь цели.
После анализа поведения стоит сопоставить эти результаты с тем, как сами участники оценивали свой опыт. Для этого перейдём к закрытым вопросам и разберём, как интерпретировать шкалы, средние значения и распределения ответов, не приписывая цифрам больше точности, чем позволяет исследование.
Закрытые вопросы дают исследованию прототипа данные, которые легко сравнивать между участниками и сценариями. После выполнения задания можно попросить пользователя оценить его сложность, понятность интерфейса, уверенность в результате или согласие с определённым утверждением.
Такие ответы удобно превращаются в цифры. Именно поэтому с ними возникает отдельный риск: числовой результат выглядит объективнее, чем он есть на самом деле.
Оценка 4,3 из 5 производит впечатление точного измерения. Но прежде чем делать вывод, нужно понять, как распределились ответы, сколько человек участвовало в исследовании, одинаково ли они интерпретировали вопрос и соответствует ли субъективная оценка их реальному поведению.
Начинайте с распределения ответов
Представим, что после задания мы спрашиваем:
Ответ предлагается дать по шкале от 1 до 5, где 1 означает «очень сложно», а 5 — «очень легко».
Среднее значение получилось 4,0. Можно написать в отчёте: «Пользователи высоко оценили простоту сценария».
Но среднее скрывает структуру данных.
Оценка 4,0 может получиться, если почти все участники выбрали 4. А может — если половина поставила 5, а другая часть значительно более низкие оценки. В первом случае мы видим относительно согласованное восприятие. Во втором — потенциально важное различие пользовательского опыта.
Поэтому я сначала смотрю на сами ответы и только после этого — на итоговый показатель.
Среднее значение не всегда лучший ориентир
Среднее удобно для сравнения, особенно если участников достаточно много. Однако при небольшом исследовании один необычный ответ способен заметно изменить результат.
Предположим, оценки пяти участников выглядят так:
Среднее будет равно 4. Формально показатель достаточно высокий. Но значительно интереснее вопрос: почему один участник оценил сценарий настолько иначе?
В исследовании прототипа этот единичный результат нельзя автоматически считать статистическим шумом. Возможно, участник относится к отдельному сегменту, столкнулся с уникальной проблемой или использовал сценарий иначе.
Поэтому вместе со средним полезно учитывать медиану и разброс ответов. Но даже эти показатели не заменяют анализа контекста.
Не превращайте шкалу в школьные оценки
Ещё одна ошибка — интерпретировать ответы слишком буквально.
Если пользователь поставил 4 из 5, это не обязательно означает, что интерфейс «хороший, но есть небольшие недочёты». Участники по-разному используют шкалы. Кто-то почти никогда не ставит максимальный балл. Другой выбирает только крайние значения. Третий воспринимает 3 как нормальную положительную оценку.
Поэтому отдельная цифра одного респондента редко представляет большой интерес. Значительно полезнее смотреть на общую картину и сопоставлять оценки с поведением.
Если участник поставил простоте сценария 5, но совершил четыре неверных перехода, это не делает его ответ бесполезным. Наоборот, перед нами интересное расхождение, которое требует объяснения.
Top-2 Box и Bottom-2 Box
При работе со шкалами иногда удобнее анализировать не среднее значение, а долю положительных и отрицательных ответов.
Для пятибалльной шкалы оценки 4 и 5 можно объединить в Top-2 Box, а 1 и 2 — в Bottom-2 Box.
Такой подход особенно удобен, когда команде нужно быстро понять баланс положительных и отрицательных оценок без излишней привязки к небольшим изменениям среднего.
Но здесь действует то же ограничение: на маленькой выборке проценты легко создают ложное ощущение статистической надёжности.
Если в исследовании участвовало пять человек и трое выбрали оценки 4 или 5, фраза «60% пользователей положительно оценили сценарий» звучит гораздо убедительнее, чем позволяют данные.
В таком случае я предпочитаю писать прямо: «3 из 5 участников выбрали оценки 4 или 5».
Читатель сразу видит реальный масштаб наблюдения.
Сравнивайте сценарии только там, где сравнение имеет смысл
Закрытые вопросы особенно полезны, когда одинаковая шкала используется после нескольких сопоставимых заданий.
Допустим, участники оценивают простоту поиска документа, изменения настроек и приглашения коллеги. Если один сценарий стабильно получает более низкие оценки, это повод изучить его подробнее.
Однако нельзя автоматически заключить, что именно этот сценарий хуже спроектирован.
Задания могут объективно различаться по сложности. Изменение настроек может требовать больше размышлений, чем скачивание документа. Поэтому разница в оценках становится отправной точкой анализа, а не готовым UX-выводом.
То же относится к сравнению разных групп пользователей. Если опытные участники оценивают сценарий выше новичков, важно проверить, связано ли это действительно с интерфейсом или с различиями в знаниях и привычках.
Проверяйте формулировку вопроса
Иногда странные результаты возникают не из-за прототипа, а из-за самого вопроса.
Например:
На него трудно ответить однозначно. Экран может быть понятным, но неудобным. Или удобным после знакомства, но непонятным при первом использовании.
В результате разные участники фактически отвечают на разные вопросы.
Лучше разделить такие характеристики:
и отдельно:
Чем конкретнее вопрос связан с исследуемым опытом, тем проще интерпретировать результат.
Сопоставляйте оценки с поведением
Наиболее полезными закрытые вопросы становятся не сами по себе, а в сочетании с результатами выполнения заданий.
Я обычно обращаю внимание на четыре ситуации.
Именно последние два случая часто дают наиболее интересные исследовательские вопросы.
Не устанавливайте пороги после получения результатов
Допустим, средняя оценка сценария составила 3,8 из 5. Команда может решить: «В целом всё нормально, ведь это почти 4».
Но почему именно 4 считается хорошим результатом?
Если критерии появляются после просмотра данных, их легко подстроить под желаемый вывод.
Если для продукта действительно нужен целевой показатель, его лучше определить заранее и объяснить, почему выбран именно такой уровень. Ещё лучше — иметь данные предыдущей версии или сопоставимого сценария. Тогда результат можно оценивать относительно понятной точки сравнения.
Цифры отвечают на один вопрос, комментарии — на другой
Закрытый вопрос помогает увидеть направление оценки и сравнить результаты. Но он редко объясняет причину.
Оценка 2 из 5 говорит, что участник испытал трудности. Она не говорит, были ли эти трудности связаны с терминологией, навигацией, количеством действий или непониманием результата.
Поэтому после значимых закрытых вопросов полезно предусмотреть возможность объяснить оценку своими словами.
Именно сочетание этих данных делает результат содержательным. Мы можем увидеть, насколько распространена определённая оценка, а затем разобраться, какие причины за ней стоят.
На следующем этапе перейдём к этим причинам подробнее — разберём, как анализировать открытые ответы и комментарии пользователей, выделять повторяющиеся темы и не путать частоту упоминаний с реальной значимостью UX-проблемы.
Открытые ответы — одна из самых содержательных и одновременно сложных частей исследования прототипа. В закрытом вопросе мы заранее задаём структуру ответа. В открытом пользователь сам определяет, о чём говорить, какие детали считать важными и какими словами описывать свой опыт.
Именно поэтому такие ответы не стоит анализировать как набор готовых требований к продукту.
Если участник говорит: «Я бы добавил сюда большую зелёную кнопку», это ещё не означает, что команде действительно нужна большая зелёная кнопка. Сначала необходимо понять, какую проблему человек пытался таким образом решить. Возможно, он не заметил основное действие. Возможно, заметил, но не понял его назначения. А возможно, ожидал совершенно другой логики сценария.
Начинайте с первичного чтения без готовой классификации
После завершения исследования я сначала просматриваю открытые ответы и заметки целиком. На этом этапе полезно не пытаться немедленно разнести каждую реплику по заранее придуманным категориям.
Если начать с жёсткой структуры «навигация», «дизайн», «тексты», «функциональность», мы рискуем увидеть в данных только то, что уже ожидали найти.
Первое чтение нужно для знакомства с материалом. Какие темы повторяются? Какие формулировки неожиданны? В каких местах комментарии противоречат поведению? Какие проблемы возникают только в определённом сценарии?
После этого можно переходить к кодированию.
Выделяйте смысловые единицы
Один открытый ответ может содержать несколько разных наблюдений.
Например:
Здесь как минимум две потенциальные темы. Первая связана с заметностью интерактивного элемента. Вторая — с пониманием последствия действия.
Если присвоить всему ответу один код «непонятная кнопка», часть информации потеряется.
Поэтому длинные комментарии полезно разбивать на отдельные смысловые единицы и уже после этого классифицировать.
Создавайте коды на основании данных
Код — это короткое обозначение наблюдаемой темы. Например: «не замечает основное действие», «не понимает термин», «ищет функцию в другом разделе», «боится потерять данные», «не замечает подтверждение операции».
Коды должны быть достаточно конкретными, чтобы помогать анализу, но не настолько узкими, чтобы каждый комментарий получил уникальную категорию.
После первичного кодирования похожие коды можно объединять в более крупные темы: обнаруживаемость элементов, информационная архитектура, терминология, понимание последствий действий, обратная связь интерфейса.
Так из десятков отдельных реплик постепенно формируется структура проблем.
Частота — не то же самое, что важность
Повторяемость комментария действительно имеет значение. Если шесть участников независимо говорят об одной проблеме, это сильнее единичного упоминания.
Но частота не должна быть единственным критерием.
Представим, что пять участников замечают слишком мелкий текст в подсказке, но всё равно успешно выполняют сценарий. Один участник не понимает предупреждение перед необратимым удалением данных и подтверждает действие, ожидая совершенно другого результата.
Вторая проблема встретилась реже, но потенциальные последствия значительно серьёзнее.
Поэтому открытые ответы нужно связывать с поведением, критичностью сценария и последствиями ошибки.
Отличайте симптом от причины
Пользователь говорит:
Это описание результата, но ещё не объяснение причины.
Почему не нашёл? Кнопка визуально теряется? Находится не там, где пользователь ожидает? Называется непонятным словом? Появляется только после другого действия? Пользователь вообще не ожидал, что сценарий должен продолжаться?
Исследовательский анализ начинается именно с таких вопросов.
Хороший вывод не повторяет слова участника, а связывает несколько наблюдений и осторожно объясняет возможный механизм проблемы.
Одна из самых полезных особенностей исследования прототипа заключается в возможности сравнить то, что пользователь говорит, с тем, что он делает.
Эти два источника данных регулярно расходятся.
Участник может сказать: «Всё было очевидно», хотя перед этим долго искал нужную функцию. Может назвать интерфейс сложным, хотя выполнил задание быстро и без ошибок. Может заявить, что никогда не воспользовался бы функцией, а затем подробно объяснить сценарий, в котором она ему нужна.
Такие противоречия не следует воспринимать как плохие данные.
Поведение и мнение отвечают на разные вопросы
Если мы хотим понять, может ли пользователь выполнить конкретное действие в текущем прототипе, поведение обычно даёт более прямое доказательство.
Если хотим узнать, насколько комфортным, понятным или надёжным пользователь считает этот опыт, без субъективной оценки не обойтись.
Поэтому вопрос не должен звучать как «чему верить — словам или действиям?». Правильнее спросить: «Что каждый источник позволяет нам узнать?»
Например, участник успешно оформляет заявку, но говорит, что не уверен, отправлена ли она.
Функционально сценарий завершён. Но с точки зрения пользовательского опыта остаётся проблема обратной связи: интерфейс не создаёт достаточной уверенности в результате.
Не превращайте предложения пользователей непосредственно в требования
Фраза «добавьте кнопку назад» — не готовое продуктовое решение.
Сначала необходимо понять, почему человеку понадобилась такая кнопка. Возможно, существующий способ возврата незаметен. Возможно, пользователь боится потерять введённые данные. Возможно, структура сценария заставляет его слишком часто возвращаться.
Пользователи хорошо описывают собственные затруднения и ожидания, но не обязаны проектировать интерфейс.
Задача исследователя — сохранить проблему, стоящую за предложением, а выбор решения оставить этапу продуктовой проработки.
После нескольких сессий легко получить десятки отдельных замечаний. Но исследовательский отчёт не должен превращаться в длинный список всего, что кому-либо не понравилось.
Нам нужны UX-проблемы, подтверждённые наблюдениями.
Формулируйте проблему через контекст и последствия
Фраза «непонятная навигация» почти ничего не говорит продуктовой команде.
Более полезная формулировка выглядит так:
«При поиске истории платежей несколько участников сначала переходили в раздел “Документы”, поскольку связывали счета и платежи с документами. После перехода они возвращались назад и продолжали поиск, что увеличивало количество действий при первом прохождении сценария».
Здесь есть контекст, поведение и последствия.
Не объединяйте разные причины слишком рано
Если три участника не выполнили одно задание, это ещё не означает, что у всех возникла одна UX-проблема.
Один мог не заметить кнопку. Второй — неправильно понять её название. Третий — увидеть кнопку, но отказаться нажимать из-за страха потерять данные.
Финальный результат одинаковый, причины разные. Следовательно, и возможные продуктовые решения будут разными.
После систематизации результатов обычно оказывается, что проблем больше, чем команда может исправить в следующей итерации. Поэтому необходима приоритизация.
Я не рекомендую определять приоритет только количеством участников, столкнувшихся с проблемой.
Учитывайте частоту
Чем чаще проблема воспроизводится независимо у разных участников, тем сильнее основание считать её системной.
Но при небольшом исследовании частота остаётся сигналом, а не точной оценкой распространённости проблемы среди всей аудитории.
Оценивайте влияние на сценарий
Нужно посмотреть, что происходит после возникновения проблемы.
Пользователь замечает ошибку и сразу исправляется? Тратит дополнительную минуту? Требует помощи? Полностью прекращает сценарий? Совершает необратимое действие?
Чем сильнее последствия, тем выше потенциальная серьёзность.
Учитывайте возможность восстановления
Ошибки, из которых пользователь легко выходит самостоятельно, обычно менее критичны, чем ситуации, где человек не понимает, что произошло.
Особенно внимательно стоит относиться к сценариям, в которых ошибка приводит к потере данных, финансовым последствиям, неправильной публикации информации или другим существенным результатам.
Связывайте проблему со значимостью сценария
Даже частая проблема может иметь ограниченный приоритет, если касается редко используемой второстепенной функции.
И наоборот, небольшое затруднение в регистрации, оплате, создании основного объекта или другом критическом сценарии способно существенно повлиять на продукт.
Таким образом, приоритет формируется из сочетания частоты, последствий, восстанавливаемости и продуктовой значимости сценария.
Общий результат иногда скрывает важные различия между группами пользователей.
Представим, что из десяти участников восемь успешно выполнили задание. На первый взгляд сценарий работает достаточно хорошо.
Но если пять участников — опытные пользователи продукта и все они справились, а среди пяти новичков возникли два неуспеха и несколько серьёзных затруднений, интерпретация меняется.
Сегментируйте только там, где есть исследовательский смысл
Полезными основаниями могут быть опыт работы с продуктом, профессиональная роль, тип клиента, частота использования похожих инструментов или конкретный сценарий.
Не стоит разбивать небольшую выборку по каждому доступному признаку. Чем больше сегментов мы создаём, тем меньше наблюдений остаётся в каждом из них и тем выше риск принять случайность за закономерность.
Сегментация должна исходить из гипотезы.
Если мы предполагаем, что терминология будет понятнее специалистам, чем новичкам, сравнение этих групп оправданно. Если заранее никаких оснований для различия нет, к найденным постфактум закономерностям следует относиться осторожно.
Исследования прототипов часто проводятся на небольшом числе участников. Это не делает их бесполезными, но существенно влияет на язык выводов.
Главное — не смешивать две разные задачи: обнаружение проблемы и оценку её распространённости.
Небольшая выборка хорошо обнаруживает проблемы, но плохо оценивает их долю
Если несколько участников независимо не понимают один элемент интерфейса, у нас появляется основание изучить проблему.
Но утверждать на основании десяти человек, что ровно 40% всей аудитории столкнутся с ней, нельзя.
Именно поэтому при небольших выборках я предпочитаю абсолютные значения.
«4 из 7 участников искали функцию в другом разделе» обычно информативнее, чем «57% пользователей выбрали неправильный раздел».
Процент визуально создаёт ощущение точности, которой исследование не обеспечивает.
Не игнорируйте единичные критические случаи
Небольшая выборка не означает, что учитывать нужно только повторяющиеся наблюдения.
Если один участник совершает опасную или необратимую ошибку, это повод проверить сценарий отдельно. Особенно если проблема потенциально может привести к серьёзным последствиям.
Такой результат не доказывает распространённость проблемы, но создаёт новую гипотезу для проверки.
После первичного анализа полезно вернуться к гипотезам, сформулированным до исследования.
Для каждой из них я определяю один из нескольких результатов: данные поддерживают гипотезу, поддерживают частично, противоречат ей или не позволяют сделать вывод.
Последний вариант особенно важен.
«Недостаточно данных» — нормальный результат
Исследователю иногда кажется, что после проведённой работы обязательно нужно дать однозначный ответ.
Но если сценарий был проверен недостаточно хорошо или участники продемонстрировали противоречивое поведение, корректнее зафиксировать неопределённость.
Например, команда хотела проверить, понимают ли пользователи новую терминологию. Большинство выполнило задание, но в процессе модератор несколько раз непреднамеренно использовал слова, подсказывающие значение термина.
В таком случае результаты нельзя считать чистой проверкой гипотезы. Лучше провести дополнительное исследование, чем создавать уверенный вывод на слабом основании.
Опровержение гипотезы — тоже результат
Если команда ожидала, что новая структура будет понятнее, а данные этого не показывают, исследование выполнило свою функцию.
Ценность исследования не в подтверждении решения, а в уменьшении неопределённости до того, как стоимость ошибки станет выше.
Наиболее надёжные выводы обычно появляются там, где несколько независимых сигналов указывают на одну проблему.
Представим, что мы тестируем создание отчёта.
Несколько участников не сразу находят нужную функцию. Время выполнения этого задания выше, чем других сопоставимых сценариев. Оценка простоты ниже. В открытых ответах пользователи говорят, что ожидали увидеть создание отчёта в другом разделе.
Каждый сигнал по отдельности имеет ограничения. Вместе они дают гораздо более убедительную картину.
Это и есть практическая ценность триангуляции.
Не требуйте совпадения всех источников
Триангуляция не означает, что поведение, оценки и комментарии обязательно должны показывать одно и то же.
Иногда расхождение и становится главным результатом.
Например, участники успешно выполняют сценарий, но низко оценивают уверенность в результате. Это может означать, что проблема возникает не в выполнении действия, а в обратной связи после него.
Поэтому задача — не добиться одинаковых цифр, а объяснить отношения между разными данными.
Слово «инсайт» часто используется слишком свободно. В отчётах инсайтом называют практически любое замечание пользователя.
Я предпочитаю разделять четыре уровня: факт, наблюдение, интерпретацию и продуктовый вывод.
Переход между этими уровнями должен быть виден.
Хороший инсайт объясняет механизм
Сильный исследовательский вывод не просто сообщает, что пользователям что-то не нравится. Он помогает понять причину поведения.
Например:
«При выборе способа публикации участники ориентируются прежде всего на предполагаемую аудиторию результата, тогда как текущие названия вариантов описывают технический способ доступа. Из-за этого пользователям приходится дополнительно интерпретировать терминологию».
Такой вывод даёт дизайнеру пространство для решения. Можно изменить названия, структуру выбора, пояснения или саму модель настройки.
Исследовательский отчёт не должен создавать впечатление, что каждое обнаруженное затруднение требует немедленного редизайна.
После определения серьёзности проблемы нужно связать результаты с продуктовыми приоритетами.
В первую очередь я смотрю на проблемы, которые блокируют критические сценарии, приводят к серьёзным ошибкам или возникают у разных участников независимо.
Затем — на затруднения, которые не блокируют сценарий, но заметно увеличивают когнитивную нагрузку, количество действий или неуверенность.
Наконец, остаются косметические замечания и индивидуальные предпочтения. Они тоже могут быть полезны, но не должны конкурировать за приоритет с проблемами, мешающими достижению пользовательской цели.
Не решайте всё в рамках одного исследования
Часть результатов лучше превратить в гипотезы следующей итерации.
Если мы выяснили, что пользователи не понимают название раздела, исследование не обязательно говорит, какое название будет правильным. Команда может разработать несколько вариантов и проверить их отдельно.
Так исследования становятся циклом, а не одноразовой процедурой.
При исследовании прототипа важно собрать в одном процессе как структурированные оценки, так и объяснения пользователей. Для этой задачи можно использовать сервис онлайн-опросов Тестограф, дополняя наблюдение за прохождением сценариев анкетой до, во время или после тестирования.
Например, перед основной частью исследования можно собрать характеристики участников, необходимые для последующей сегментации. После каждого задания — попросить оценить его сложность или уверенность в результате. Затем добавить открытый вопрос, чтобы пользователь объяснил поставленную оценку.
Так мы получаем связку количественных и качественных данных.
Не превращайте анкету в отдельное большое исследование
При тестировании прототипа опрос должен поддерживать основной исследовательский сценарий, а не конкурировать с ним.
Если после каждого действия пользователь вынужден отвечать на десять вопросов, мы вмешиваемся в естественный процесс взаимодействия. Участник начинает анализировать интерфейс значительно внимательнее, чем делал бы это в реальной ситуации.
Поэтому я рекомендую задавать вопросы в тех точках, где они действительно нужны для проверки гипотезы.
Для создания исследования можно использовать конструктор опросов Тестографа, сочетая закрытые вопросы со шкалами и открытые поля для комментариев. Если разные ответы требуют разных следующих вопросов, пригодится логика переходов: например, участника, поставившего низкую оценку понятности сценария, можно попросить подробнее описать причину.
При этом важно не забывать методологический принцип: анкета фиксирует ответы участника, а не заменяет наблюдение за его поведением. Если исследование посвящено удобству прототипа, лучше анализировать оба источника вместе.
Хороший исследовательский отчёт должен помогать принимать решения, а не просто документировать проделанную работу.
Я начинаю с краткого резюме: какие исследовательские вопросы проверяли, какие наиболее значимые результаты получили и какие решения требуют внимания команды.
После этого описываю методологию: кто участвовал, какие сценарии выполнялись, в каких условиях проходило исследование и какие ограничения нужно учитывать при интерпретации.
Организуйте результаты вокруг вопросов, а не хронологии
Необязательно рассказывать исследование в том порядке, в котором участники проходили прототип.
Для продуктовой команды полезнее структура вокруг основных вопросов.
Например: могут ли пользователи создать проект; понимают ли настройки доступа; замечают ли предупреждение; понимают ли результат публикации.
Внутри каждого блока уже можно показывать наблюдения, показатели, комментарии и интерпретацию.
Обязательно указывайте ограничения
Ограничения не делают исследование слабым. Они показывают границы применимости выводов.
Даже хорошо проведённые сессии можно испортить неаккуратным анализом.
Одна из частых ошибок — делать вывод по самому яркому участнику. Эмоциональная критика запоминается лучше спокойного поведения остальных, поэтому отдельная сессия может получить непропорционально большой вес.
Другая ошибка — считать каждое замечание UX-проблемой. Пользователь может высказать личное предпочтение, которое никак не влияет на выполнение сценария.
Третья — смешивать наблюдение и интерпретацию. «Пользователь нажал на элемент три раза» — наблюдение. «Пользователь не понял интерфейс» — уже объяснение.
Не игнорируйте успешные сценарии
Исследователь естественным образом концентрируется на проблемах. Но важно понимать и то, что работает.
Если все участники быстро понимают новый элемент, это тоже результат. Он позволяет команде не переделывать удачное решение вместе с проблемными частями интерфейса.
Не выдавайте среднее значение за доказательство
Высокая средняя оценка не отменяет серьёзной проблемы, обнаруженной в поведении. Низкая оценка, в свою очередь, не всегда означает невозможность выполнить сценарий.
Метрики нужно интерпретировать вместе с контекстом.
Не превращайте пожелания в бэклог автоматически
Если трое пользователей попросили определённую функцию, это ещё не означает, что её нужно разрабатывать.
Сначала стоит понять задачу, которую они пытаются решить, и проверить, насколько она соответствует продуктовой стратегии и потребностям более широкой аудитории.
Представим, что команда проектирует новый сценарий приглашения коллег в рабочее пространство.
Гипотеза звучит так: пользователь сможет самостоятельно пригласить нового участника и правильно выбрать уровень доступа.
Во время исследования большинство участников находят кнопку приглашения. Однако несколько человек испытывают затруднение на следующем шаге: при выборе роли они не понимают разницу между двумя вариантами доступа.
При этом само приглашение в итоге отправляют почти все.
Если посмотреть только на Task Success Rate, сценарий можно признать успешным.
Но наблюдения показывают другую проблему: участники достигают технического результата, не будучи уверенными, какие права получит приглашённый человек.
В открытых комментариях повторяется похожая тема: названия ролей кажутся понятными, но их последствия неочевидны.
Теперь мы можем сформулировать проблему точнее:
«Пользователи способны завершить приглашение, однако текущий выбор ролей не позволяет части участников уверенно определить будущие права коллеги. В результате успешное выполнение сценария не гарантирует осознанного выбора уровня доступа».
Это существенно полезнее вывода «нужно улучшить экран ролей».
Следующая продуктовая гипотеза может заключаться в том, что описание конкретных разрешений рядом с каждой ролью повысит уверенность выбора. После изменения прототипа её можно проверить повторно.
После завершения анализа я рекомендую ещё раз пройти весь путь от исходных данных до продуктовых рекомендаций.
Наконец, отделите исследовательский вывод от продуктовой рекомендации. Команда должна понимать, какие данные подтверждают проблему, даже если позже выберет другой способ её решения.
Хороший анализ исследования прототипа не измеряется количеством найденных недостатков. Его задача — уменьшить неопределённость перед следующим продуктовым решением.
После исследования у нас остаются действия пользователей, ошибки, время выполнения, ответы на шкалы, комментарии и наблюдения. По отдельности эти данные легко интерпретировать неправильно. Повторяющийся комментарий можно принять за массовую потребность, высокую оценку — за доказательство удобства, успешное выполнение — за отсутствие UX-проблем.
Поэтому в работе с исследованиями я возвращаюсь к одному принципу: сначала наблюдение, затем интерпретация и только после этого продуктовое решение.
Мы фиксируем, что произошло. Проверяем, повторяется ли паттерн. Сопоставляем поведение со словами пользователя. Оцениваем последствия. И только когда доказательств достаточно, формулируем объяснение и обсуждаем изменения продукта.
Такой подход особенно важен при небольших выборках. Исследование прототипа может очень хорошо показать, где и каким образом ломается пользовательский сценарий, но гораздо хуже подходит для точной оценки того, какая доля всей аудитории столкнётся с проблемой. Границы метода нужно учитывать и при анализе, и при презентации результатов.
Не менее важно сохранять различие между проблемой и её решением. Если пользователь не замечает действие, это ещё не означает, что кнопку обязательно нужно увеличить. Если не понимает термин, недостаточно автоматически заменить его первым предложенным респондентом вариантом. Исследование должно объяснить механизм затруднения, а дизайн — найти наиболее подходящий способ его устранения.
Для сбора структурированной обратной связи в исследованиях можно использовать Тестограф: сочетать шкалы, закрытые вопросы и развернутые комментарии, а затем анализировать их вместе с наблюдаемым поведением участников. При необходимости результаты исследования можно дополнительно обрабатывать через возможности анализа результатов опросов в Тестографе. Конкретные адреса разделов сервиса перед публикацией статьи стоит проверить и заменить на наиболее релевантные страницы продукта.
В конечном счёте исследование прототипа — не экзамен, который интерфейс должен «сдать». Это инструмент последовательного снижения риска. Мы создаём решение, наблюдаем за его использованием, обнаруживаем расхождение между нашими предположениями и поведением аудитории, формулируем новую гипотезу и проверяем следующую версию.
Именно поэтому завершением исследования я считаю не презентацию отчёта, а момент, когда команда понимает, что она узнала, насколько уверенно это знает и что именно стоит проверить в следующей итерации.
Цикл продолжается: прототип → исследование → анализ → изменение → повторная проверка. Чем аккуратнее мы работаем с данными на этапе анализа, тем меньше решений приходится принимать на основании впечатлений и тем больше — на основании наблюдаемого пользовательского опыта.