Пользователь открывает новый экран, видит несколько кнопок и за пару секунд решает, что делать дальше. Если решение совпадает с тем, которое предполагала продуктовая команда, интерфейс справляется со своей задачей. Если человек останавливается, выбирает не тот элемент или начинает искать нужную функцию в другом месте, проблема уже существует — даже если сам дизайн выглядит аккуратно и логично.
Когда мы говорим о понятном интерфейсе, я имею в виду не интерфейс, который нравится пользователю визуально. Понятность проявляется в поведении: человек правильно интерпретирует элементы экрана, понимает доступные ему действия, может предположить результат нажатия и выполнить задачу без дополнительных инструкций. Причем желательно проверить это не после релиза, а тогда, когда изменение интерфейса еще обходится в несколько правок прототипа.
В работе с исследованиями я регулярно сталкиваюсь с одной особенностью продуктовых команд: чем дольше специалисты работают над интерфейсом, тем сложнее им оценивать его глазами нового пользователя. Дизайнер знает, почему кнопка находится именно здесь. Продакт понимает внутреннюю логику разделов. Разработчик знаком со всеми состояниями системы. Даже используемые в интерфейсе термины постепенно начинают казаться команде естественными. У пользователя этого контекста нет.
Поэтому обсуждение макета внутри команды не заменяет проверку на реальных представителях аудитории. Фраза «здесь и так всё понятно» — это гипотеза, а не результат исследования.
Для такой проверки необязательно ждать готового продукта. Интерактивный прототип позволяет увидеть, замечает ли пользователь нужную функцию, куда пытается нажать в первую очередь, правильно ли понимает навигацию, может ли выполнить основной сценарий и в каких местах начинает сомневаться. Одновременно можно проверить формулировки, названия разделов, последовательность шагов и ожидания от действий.
Прототип особенно полезен тем, что позволяет исследовать не только мнение, но и поведение. Вопрос «Насколько понятным вам кажется этот экран?» дает субъективную оценку. Задание «Представьте, что вам нужно изменить способ оплаты. Покажите, как бы вы это сделали» дает возможность увидеть, действительно ли человек способен разобраться в интерфейсе. А последующие вопросы помогают понять причины его действий.
В этой статье я разберу, как организовать такую проверку до начала полноценной разработки: какой прототип подготовить, как выбрать пользовательские сценарии, сформулировать задания и вопросы, провести тестирование и интерпретировать полученные данные. Отдельно остановлюсь на ошибке, которую важно учитывать при анализе: пользователь может сказать, что интерфейс ему понятен, и при этом не справиться с поставленной задачей.
Материал будет полезен UX/UI-дизайнерам, UX-исследователям, продакт-менеджерам и другим участникам продуктовых команд, которым нужно принимать решения об интерфейсе на основании пользовательских данных. Покажу подход с точки зрения исследовательской методологии: не просто «спросить мнение о дизайне», а построить проверку так, чтобы результаты помогли понять, где именно возникает проблема, насколько она существенна и что стоит изменить до передачи интерфейса в разработку.
Перед тестированием полезно определить, что именно мы хотим узнать. Формулировка «проверить, понятен ли интерфейс» слишком широкая. Один участник может легко разобраться в навигации, но неправильно понять назначение кнопки. Другой — знать значение всех элементов, но не найти нужный раздел. Если собрать эти ситуации в общую оценку понятности, мы потеряем значительную часть полезной информации.
В работе с клиентами я обычно предлагаю начинать с конкретных исследовательских вопросов. Например: сможет ли новый пользователь найти функцию экспорта? Поймет ли он разницу между «Сохранить» и «Опубликовать»? Догадается ли, где изменить настройки проекта? Что, по его мнению, произойдет после нажатия определенной кнопки? Такие вопросы гораздо проще превратить в сценарии тестирования и затем связать с наблюдаемым поведением.
Проверяем структуру и навигацию
Первый уровень — способен ли человек определить, где искать нужную функцию. Для этого не требуется проверять каждую страницу прототипа. Гораздо полезнее дать участнику реалистичную задачу и посмотреть, какой путь он выберет самостоятельно.
Представим новый личный кабинет сервиса. Пользователю нужно найти результаты завершенного исследования. Если большинство участников сразу открывают раздел «Результаты», логика навигации, скорее всего, соответствует их ожиданиям. Если они сначала идут в «Мои проекты», затем в «Историю», возвращаются назад и только после нескольких попыток находят нужный экран, стоит исследовать причину.
Важно фиксировать не только конечный результат. Ошибочные переходы, возвраты и длительные паузы иногда рассказывают о понятности структуры больше, чем сам факт успешного выполнения задания.
Проверяем названия и элементы управления
Следующий уровень — интерпретация отдельных элементов. Пользователь может видеть кнопку, вкладку или иконку, но понимать ее иначе, чем предполагала команда.
Особенно внимательно я бы проверял элементы, смысл которых невозможно однозначно определить без знания продукта: профессиональные термины, внутренние названия функций, сокращения, нестандартные иконки.
Простой способ проверки — показать элемент до взаимодействия с ним и спросить, что, по мнению участника, произойдет после нажатия. После этого дать возможность выполнить действие и сравнить ожидание с фактическим результатом прототипа.
Здесь появляется важное различие между видимостью элемента и пониманием его назначения. Если участник не замечает нужную кнопку — это одна проблема. Если замечает, но ожидает от нее другого действия — уже другая. Исправления в этих случаях тоже потребуются разные.
Проверяем, понимает ли пользователь следующий шаг
Хороший интерфейс не должен постоянно заставлять человека останавливаться и разгадывать намерение дизайнера. На основных этапах сценария пользователь должен понимать, что можно сделать сейчас и куда это его приведет.
Поэтому при тестировании я обращаю внимание на моменты неопределенности. Участник может в итоге выполнить задачу правильно, но перед каждым действием долго изучать экран. Формально сценарий завершен успешно, однако говорить о полной понятности такого интерфейса рано.
Можно дополнить наблюдение вопросами: «Что бы вы сделали дальше?» или «Какого результата вы ожидаете после этого действия?». Они позволяют проверить логику интерфейса, не подсказывая правильного решения.
Не смешиваем понятность и визуальную привлекательность
Одна из распространенных методологических ошибок — одновременно спрашивать, насколько интерфейс красивый, современный, удобный и понятный, а затем делать общий вывод о качестве решения.
Это разные характеристики.
Человеку может нравиться дизайн, хотя он не способен найти нужную функцию. Возможна и обратная ситуация: интерфейс кажется ему визуально устаревшим, но основные задачи выполняются без затруднений.
Если цель исследования — проверить понятность, я рекомендую строить основную часть проверки вокруг выполнения задач и только затем собирать субъективные оценки. Для последующего опроса можно использовать Тестограф: например, попросить участников оценить понятность отдельных этапов и объяснить возникшие затруднения в открытых вопросах.
Но оценка «9 из 10» сама по себе не должна становиться доказательством того, что решение работает. Ее необходимо сопоставить с тем, что человек действительно делал в прототипе.
Формулируем исследовательские вопросы заранее
До встречи с участниками стоит зафиксировать несколько вопросов, на которые исследование должно дать ответ. Обычно я стараюсь формулировать их так, чтобы результат можно было связать с наблюдаемым действием или конкретным ответом пользователя.
Например:
Такой подход защищает исследование от ситуации, когда команда провела несколько интервью, получила десятки комментариев, но после этого не может решить, какие выводы действительно относятся к проверяемой гипотезе.
В результате вместо абстрактной задачи «проверить новый дизайн» у нас появляется набор проверяемых предположений. Именно от них уже стоит переходить к выбору прототипа: определять необходимую степень его детализации и решать, какие экраны и переходы действительно понадобятся участникам.
Для исследования понятности не нужен прототип, в котором проработаны все экраны, состояния и возможные действия. Его детализация должна зависеть от исследовательского вопроса. Если мы хотим проверить структуру разделов, один уровень проработки будет достаточным. Если проверяем, понимает ли пользователь конкретную форму или новый сценарий оформления заказа, понадобится другой.
На практике стремление сначала «довести прототип до идеала», а уже потом показать его пользователям часто только увеличивает стоимость изменений. Команда вкладывает время в детали решения, жизнеспособность которого еще не подтверждена.
Начинайте с минимально достаточной детализации
Прототип должен позволять участнику выполнить сценарий настолько естественно, чтобы мы могли наблюдать его решения. Всё остальное на этом этапе вторично.
Например, если проверяется новая навигация личного кабинета, необязательно проектировать содержимое каждого раздела. Важнее сделать кликабельными основные пункты и предусмотреть экраны, которые пользователь увидит на пути к цели.
Если же исследовательский вопрос звучит как «Поймет ли пользователь, как настроить параметры отчета?», потребуется более подробный прототип: с полями, переключателями, названиями параметров и реакциями интерфейса на действия.
Я использую простой критерий: если отсутствие элемента мешает участнику принять решение, связанное с исследовательским вопросом, элемент нужен. Если не мешает — его можно пока не прорабатывать.
Высокая визуальная точность нужна не всегда
Прототип с реалистичным контентом и почти финальным дизайном выглядит убедительнее, но высокая детализация не делает исследование автоматически качественнее.
На ранней стадии она иногда даже мешает. Участники начинают обсуждать цвет кнопки, размер шрифта или иллюстрации, хотя команда пытается понять, находят ли они нужную функцию.
Для проверки общей структуры могут подойти сравнительно простые экраны. Когда же исследуются конкретные тексты, расположение элементов или сложный многошаговый процесс, прототип разумно приблизить к будущему интерфейсу.
Есть и еще одна причина не делать ранний прототип слишком «готовым». Чем больше ресурсов уже вложено в конкретное решение, тем психологически сложнее команде отказаться от него после исследования. Тестирование превращается из проверки гипотезы в поиск подтверждений того, что выбранный вариант хороший.
Сначала определите критические сценарии
Не стоит пытаться воспроизвести в прототипе весь продукт. Выберите действия, ошибки в которых действительно будут иметь значение.
Допустим, команда перерабатывает интерфейс сервиса для проведения исследований. В новом варианте пользователь должен создать опрос, настроить его, запустить сбор ответов и перейти к результатам. Для первой проверки необязательно моделировать десятки дополнительных функций. Гораздо важнее убедиться, что человек понимает основную последовательность и может пройти ее самостоятельно.
Обычно я предлагаю задать команде вопрос: какое действие пользователь обязательно должен уметь выполнить после запуска нового интерфейса? Ответ помогает отделить критический сценарий от второстепенных возможностей.
После этого сценарий можно разбить на точки принятия решений. Где пользователь должен выбрать раздел? Где понять значение кнопки? Где решить, что делать дальше? Именно эти места особенно интересны для исследования.
Не делайте правильный путь единственным доступным
У прототипов есть методологическая ловушка. Иногда дизайнер делает кликабельными только те элементы, которые ведут по запланированному сценарию. В результате участник нажимает на неправильный пункт, ничего не происходит, и сразу понимает, что исследователь ожидал другого действия.
Получается скрытая подсказка.
Если для исследования важно узнать, какой путь выберет человек, желательно предусмотреть хотя бы основные альтернативы. Необязательно полностью проектировать каждую ошибочную ветку. Иногда достаточно показать соответствующий экран или состояние, чтобы участник мог понять результат своего решения и продолжить взаимодействие.
То же относится к текстам-заглушкам. Названия вроде «Раздел 1», «Проект А» или бессмысленный lorem ipsum допустимы только тогда, когда содержание действительно не влияет на решение. Если пользователь должен выбрать вариант на основании текста, контент становится частью интерфейса и должен выглядеть реалистично.
Прототип должен проверять гипотезу, а не демонстрировать дизайн
Перед исследованием я советую пройти весь сценарий самостоятельно и для каждого экрана задать три вопроса: что здесь должен понять пользователь, какое действие мы от него ожидаем и что мы будем считать признаком проблемы?
Предположим, на экране есть новая кнопка «Сформировать представление». Команда понимает этот термин, потому что обсуждала функцию несколько недель. Для пользователя он может ничего не означать. Тогда исследовательская задача состоит не в том, чтобы показать красивую кнопку, а в том, чтобы выяснить, какое действие человек связывает с этой формулировкой.
Именно поэтому хороший исследовательский прототип иногда выглядит менее завершенным, чем презентационный макет. Его задача — создать ситуацию выбора и позволить увидеть реальное поведение.
Когда прототип подготовлен таким образом, можно переходить к следующему этапу — сценариям и заданиям для участников. И здесь особенно важно не превратить тестирование в экскурсию по интерфейсу: формулировка задания должна давать человеку цель, но не подсказывать способ ее достижения.
Даже хорошо собранный прототип можно проверить неудачно, если дать участнику слишком очевидные инструкции. В исследованиях интерфейсов формулировка задания напрямую влияет на поведение человека. Одно лишнее слово способно подсказать название раздела, нужную кнопку или правильную последовательность действий.
Поэтому сценарий тестирования я стараюсь строить не вокруг элементов интерфейса, а вокруг цели пользователя. Нам важно увидеть, сможет ли человек самостоятельно определить путь к результату.
Описывайте ситуацию, а не правильное действие
Предположим, мы хотим проверить новую функцию сохранения отчета в PDF. Неудачное задание может звучать так:
Так мы практически полностью объяснили участнику интерфейс. Даже если он успешно выполнит задание, мы не узнаем, смог бы он найти эту возможность самостоятельно.
Гораздо полезнее сформулировать задачу через ситуацию:
Теперь участнику приходится самому определить, где искать нужную функцию и какое действие выбрать. Именно это поведение нам и нужно наблюдать.
При этом сценарий не должен превращаться в загадку. Если в реальной ситуации пользователь точно знает, что ему нужен PDF, это можно указать. Искусственно скрывать важную информацию ради усложнения теста тоже неправильно.
Не используйте терминологию интерфейса в задании
Особенно внимательно стоит относиться к словам, которые повторяют названия элементов прототипа.
Допустим, команда хочет проверить, понятно ли название функции «Архивировать проект». Если исследователь говорит участнику: «Найдите, как архивировать проект», часть проверки уже потеряна. Человек начинает искать слово «архивировать», а не функцию с определенным смыслом.
Лучше описать намерение: «Этот проект завершен, и вы больше не хотите видеть его среди активных, но удалять его не нужно. Что бы вы сделали?»
Так можно проверить сразу несколько вещей: где человек ищет нужное действие, какое название ожидает увидеть и правильно ли интерпретирует предложенную терминологию.
Выберите несколько критических задач
Пытаться проверить весь интерфейс за одну сессию обычно не стоит. Чем больше заданий, тем сильнее участник знакомится с логикой продукта и тем меньше его поведение напоминает первое взаимодействие.
Я предпочитаю выбирать несколько сценариев, связанных с наиболее важными гипотезами. Это могут быть создание нового объекта, поиск функции, изменение настроек, выполнение основного рабочего действия или получение результата.
При выборе полезно учитывать частоту и последствия ошибки. Если функция используется редко и неправильный выбор легко исправить, ее проверка может подождать. Если же непонимание блокирует основной сценарий или приводит к потере данных, такую задачу стоит поставить выше.
Порядок заданий тоже имеет значение. Первые сценарии дают наиболее чистое представление о том, как человек воспринимает продукт без предварительного обучения. После нескольких задач участник уже знает, где находятся разделы и как устроена навигация.
Заранее определите, что будете считать успехом
Формулировка задания — только половина подготовки. До исследования необходимо договориться, какое поведение будет считаться успешным.
Например, участник может выполнить задачу, но перед этим открыть четыре неподходящих раздела. Можно ли считать такой сценарий успешным? Формально — да: конечная цель достигнута. С точки зрения понятности интерфейса результат уже неоднозначный.
Поэтому до тестирования стоит определить признаки, которые мы будем наблюдать: достиг ли человек цели, потребовалась ли подсказка, выбирал ли ошибочные пути, возвращался ли назад, правильно ли понимал результат своих действий.
Такой подход помогает не менять критерии после исследования под уже полученные результаты.
Не помогайте слишком рано
Во время модерируемого тестирования возникает естественное желание помочь участнику, который долго не может найти нужное действие. Для исследования именно этот момент может оказаться самым ценным.
Если человек спрашивает: «Куда здесь нужно нажать?», я не спешу давать инструкцию. Можно ответить нейтрально: «А где вы ожидали бы найти эту функцию?» или попросить рассказать, что он сейчас ищет.
При этом не нужно заставлять участника бесконечно бороться с интерфейсом. Если стало понятно, что сценарий заблокирован, исследователь может помочь перейти дальше, зафиксировав, что для выполнения задачи потребовалась подсказка.
Так мы сохраняем возможность проверить следующие части прототипа, но не записываем прохождение как самостоятельное.
Хорошо подготовленные задания превращают демонстрацию прототипа в исследование. Мы не ведем человека по заранее известному маршруту, а создаем условия, в которых он принимает собственные решения. Следующий этап — правильно провести саму сессию и дополнить наблюдение вопросами так, чтобы получить не только последовательность действий, но и объяснение причин пользовательского поведения.
Когда прототип и задания готовы, нужно выбрать формат исследования. Здесь нет универсально лучшего варианта: способ тестирования зависит от того, насколько сложный сценарий мы проверяем, нужны ли уточняющие вопросы и насколько важно увидеть ход рассуждений участника.
На практике я чаще разделяю тестирование на два формата: модерируемое, когда исследователь присутствует на сессии, и немодерируемое, когда человек самостоятельно работает с прототипом и отвечает на подготовленные вопросы.
Когда лучше модерируемое тестирование
Модерируемый формат особенно полезен на ранних итерациях. Исследователь видит, где человек остановился, что пытается найти, почему возвращается на предыдущий экран. В нужный момент можно задать уточняющий вопрос и получить информацию, которую сложно собрать автоматически.
Но присутствие исследователя одновременно создает риск. Участник понимает, что за ним наблюдают, и может стараться выполнить задание «правильно». Даже интонация, реакция на ошибочный клик или фраза «посмотрите еще раз» способны стать подсказкой.
Поэтому я стараюсь занимать нейтральную позицию. Если участник выбирает неожиданный путь, не стоит сразу его исправлять. Лучше попросить объяснить, чего он ожидает от выбранного действия.
При этом метод think aloud — просьба проговаривать мысли во время выполнения задачи — полезен не всегда. Постоянное комментирование может сделать поведение менее естественным и замедлить работу. Часто достаточно попросить участника озвучивать моменты сомнения, а подробные вопросы задавать после завершения отдельного сценария.
Когда подойдет немодерируемый формат
Немодерируемое тестирование удобно, когда сценарий относительно простой и его можно пройти без объяснений исследователя. Такой подход позволяет привлечь больше участников и быстрее собрать сопоставимые результаты.
Здесь особенно важны формулировки. Если человек неправильно понял задание, исследователь уже не сможет уточнить его в процессе. Поэтому перед запуском я рекомендую провести несколько пробных прохождений и убедиться, что инструкция понятна сама по себе.
После каждого сценария можно предложить участнику небольшой блок вопросов. Например, оценить сложность выполнения задачи, указать место, которое вызвало затруднение, и своими словами объяснить, чего он ожидал от определенного элемента.
Для сбора таких ответов можно подготовить онлайн-опрос в Тестографе. Это особенно удобно, если нужно получить ответы от нескольких групп пользователей в единой структуре и затем сопоставить их с результатами прохождения прототипа.
Сначала наблюдаем, потом спрашиваем
Один из принципов, которого я придерживаюсь при проверке интерфейсов: поведение и мнение пользователя нужно анализировать отдельно, а затем сопоставлять.
Представим, что участник дважды открыл неправильный раздел, вернулся назад, нашел нужную функцию с третьей попытки, а после задания поставил понятности интерфейса 9 баллов из 10. Если смотреть только на оценку, проблема останется незамеченной.
Обратная ситуация тоже возможна. Человек выполняет сценарий быстро и без ошибок, но ставит 6 из 10, потому что ему не нравится формулировка или внешний вид экрана.
Поэтому сначала фиксируем, что произошло, а затем выясняем, как пользователь это воспринимает и почему.
Не спрашивайте «Вам всё понятно?»
Это один из самых слабых вопросов для проверки понятности. На него легко ответить «да», даже если человек интерпретировал интерфейс совершенно иначе, чем предполагала команда.
Вместо вопроса «Понятно ли, что делает эта кнопка?» полезнее спросить: «Что, по вашему мнению, произойдет после нажатия?» Вместо «Удобно ли расположено меню?» — дать задачу и посмотреть, где пользователь начнет искать нужный раздел.
То же относится к общей формулировке «Насколько интерфейс удобный?». Ответ может быть полезен как субъективная метрика, но он почти ничего не объясняет без контекста поведения.
Фиксируйте проблемы сразу в контексте сценария
Во время сессии полезно записывать не просто комментарии участника, а ситуацию целиком: какое задание он выполнял, на каком экране возникло затруднение, что сделал, чего ожидал и чем закончилась попытка.
Например, запись «непонятна кнопка» слишком абстрактна. Гораздо информативнее: «При попытке поделиться результатами участник не выбрал кнопку “Публикация”, потому что ожидал, что она сделает отчет общедоступным».
Во втором случае уже видна потенциальная причина проблемы — расхождение между терминологией интерфейса и ожиданием пользователя.
Если исследование включает анкету после работы с прототипом, заранее задайте одинаковую структуру вопросов для всех участников. Это упростит дальнейший анализ и позволит сравнивать ответы между сценариями.
Главное на этом этапе — не превращать исследование в презентацию продукта. Чем меньше мы объясняем интерфейс до выполнения задания, тем больше можем узнать о его реальной понятности. А после прохождения сценария уже можно переходить к более подробным вопросам: выяснять ожидания пользователя, причины ошибок и субъективную сложность отдельных действий.
После прохождения сценария у исследователя появляется возможность выяснить, почему пользователь действовал именно так. На этом этапе вопросы дополняют наблюдение: мы уже видели, что произошло, и теперь можем проверить свои предположения о причинах.
Я не рекомендую откладывать все вопросы до конца тестирования. Если участник прошел пять или шесть экранов, ему будет сложнее вспомнить, что именно вызвало сомнение в начале. Кроме того, последующие действия могут изменить его первоначальное представление об интерфейсе.
Лучше задавать короткий блок вопросов сразу после важного сценария или действия, а общую оценку оставлять на завершение исследования.
Проверяйте понимание своими словами
Если нужно выяснить, правильно ли пользователь понял функцию, не стоит сразу предлагать ему готовые варианты ответа. Попросите объяснить назначение элемента самостоятельно.
Например: «Для чего, по вашему мнению, нужен этот раздел?» или «Что произойдет, если выбрать этот пункт?»
Такие вопросы позволяют обнаружить расхождение между логикой команды и пользовательской интерпретацией. Особенно это полезно при проверке новых терминов, названий тарифов, статусов, фильтров и действий, значение которых нельзя однозначно определить по привычным паттернам.
Важно задавать вопрос до того, как исследователь объяснит правильное значение. Иначе мы будем проверять не первоначальное понимание интерфейса, а способность участника запомнить подсказку.
Спрашивайте о конкретном действии
Вместо общего «Что было сложно?» я предпочитаю привязывать вопрос к только что произошедшей ситуации.
Если участник долго искал настройку, можно спросить: «Где вы ожидали ее найти?» Если нажал не на тот элемент: «Что вы ожидали увидеть после этого действия?» Если несколько раз возвращался назад: «В какой момент вы поняли, что выбрали не тот путь?»
Такие вопросы помогают отделить симптом от причины. Сам по себе ошибочный клик еще не объясняет проблему. Возможно, пользователь неправильно понял название. Возможно, нужный элемент был визуально незаметен. А возможно, структура продукта не совпала с его представлением о том, где должна находиться функция.
Сочетайте открытые вопросы и оценки
Количественная оценка удобна для сравнения участников и разных версий прототипа. Например, после сценария можно попросить оценить сложность выполнения задачи по шкале.
Но шкала показывает интенсивность оценки, а не ее причину. Поэтому после особенно низкой или высокой оценки полезен открытый вопрос: «Что больше всего повлияло на вашу оценку?»
В Тестографе такой блок можно собрать в одной анкете: сначала получить оценку, затем уточнить ее открытым вопросом. Если участников достаточно много, структурированные ответы помогут увидеть распределение оценок, а комментарии — разобраться, что за ним стоит.
При этом я бы не перегружал исследование шкалами после каждого клика. Чем чаще человека просят оценивать интерфейс, тем сильнее тестирование начинает отличаться от естественного использования продукта.
Проверяйте терминологию через ожидания
Названия элементов заслуживают отдельного внимания. Команда может месяцами использовать определенный термин, поэтому он воспринимается как очевидный. Для нового пользователя это слово может иметь совершенно другое значение.
Предположим, в интерфейсе появляется раздел «Распространение». Вместо вопроса «Понятно ли вам слово “Распространение”?» лучше спросить: «Что вы ожидаете найти в этом разделе?»
Если ответы участников заметно расходятся с его реальным содержанием, проблема становится гораздо конкретнее. Мы видим не просто низкую субъективную оценку понятности, а неправильное ожидание, созданное самим названием.
Дополнительно можно попросить участника предложить собственное название. Но такие ответы я воспринимаю скорее как источник гипотез, а не готовое решение. Пользователь хорошо описывает собственные ожидания и затруднения, но проектирование интерфейса остается задачей продуктовой команды.
Не превращайте интервью в защиту решения
Иногда после неожиданной реакции пользователя возникает желание объяснить: «На самом деле эта кнопка означает другое» или «Мы расположили ее здесь, потому что…». Для исследования такое объяснение почти ничего не дает.
Если человек понял элемент неправильно, этот факт уже представляет ценность. Лучше выяснить, что привело его к такой интерпретации.
Полезно разделять три уровня данных: что пользователь сделал, что он сказал и как исследователь объясняет произошедшее. Например, участник открыл неправильный раздел — это наблюдение. Он сказал, что ожидал найти там настройки, — это его объяснение. Вывод о том, что название другого раздела недостаточно точно передает содержание, — уже исследовательская интерпретация.
Такое разделение пригодится на следующем этапе. Когда тестирование завершено, отдельные клики, оценки и комментарии нужно собрать в общую картину и определить, какие проблемы действительно повторяются, какие мешают выполнению основных сценариев и какие изменения интерфейса стоит проверять в следующей итерации.
После тестирования прототипа легко получить десятки наблюдений: кто-то долго искал кнопку, кто-то выбрал неправильный раздел, несколько участников пожаловались на название функции, а средняя оценка понятности составила, например, 8,2 из 10. Главная задача на этом этапе — не свести всё исследование к одной цифре.
При анализе понятности интерфейса я в первую очередь смотрю на то, смог ли пользователь выполнить задачу и каким путем он пришел к результату. Оценки и комментарии помогают объяснить поведение, но не должны его заменять.
Начните с успешности сценариев
Для каждого задания стоит определить результат прохождения. Пользователь мог выполнить задачу самостоятельно, выполнить ее после нескольких ошибок, справиться только с подсказкой или вообще не найти решение.
Такое разделение информативнее простой отметки «выполнено / не выполнено».
Представим, что пять участников в итоге нашли функцию настройки уведомлений. На первый взгляд успешность составляет 100%. Но если трое сначала открывали другие разделы, а одному потребовалась помощь исследователя, вывод о понятности интерфейса будет совсем другим.
Особенно внимательно стоит смотреть на критические сценарии. Ошибка в редко используемой дополнительной функции и невозможность завершить регистрацию — проблемы разного масштаба, даже если встретились у одинакового количества участников.
Анализируйте ошибочные пути и паузы
Ошибочный клик сам по себе не всегда говорит о серьезной проблеме. Человек мог случайно нажать не туда и сразу исправиться. Гораздо интереснее повторяющиеся паттерны.
Если несколько участников независимо друг от друга открывают один и тот же неправильный раздел, это уже сигнал о расхождении между структурой интерфейса и ожиданиями аудитории. Если пользователи останавливаются на одном экране и долго сравнивают два действия, возможно, между ними недостаточно понятная разница.
Я также фиксирую возвраты. Когда человек переходит на экран, изучает его и возвращается назад, это часто означает, что первоначальное ожидание не подтвердилось. Полезно сопоставить такое поведение с ответом на вопрос «Что вы ожидали здесь увидеть?».
В результате вместо абстрактного вывода «навигация вызывает трудности» можно получить гораздо более полезный: «Пользователи ищут управление доступом в настройках проекта, тогда как функция находится в разделе публикации».
Не считайте любую ошибку проблемой интерфейса
Один участник может неправильно прочитать задание, отвлечься или случайно нажать на соседнюю кнопку. Поэтому единичное наблюдение не стоит автоматически превращать в требование к редизайну.
Я смотрю на совокупность признаков: повторяется ли ситуация, блокирует ли она сценарий, насколько сложно пользователю самостоятельно восстановиться после ошибки и совпадает ли наблюдаемое поведение с комментариями других участников.
При небольшой качественной выборке количество повторений не следует воспринимать как точную статистику. Формулировка «три из пяти участников столкнулись с проблемой» описывает результаты этих пяти сессий, но сама по себе не означает, что с той же проблемой столкнутся 60% всей аудитории.
Это важное ограничение исследования прототипов. Качественное тестирование хорошо обнаруживает и объясняет проблемы, но для оценки их распространенности в большой аудитории может потребоваться отдельная количественная проверка.
Сопоставляйте поведение с субъективными оценками
После теста можно собрать оценки понятности отдельных сценариев и интерфейса в целом. В Тестографе удобно объединить шкальные и открытые вопросы, а затем посмотреть ответы участников в общей структуре.
Но среднее значение стоит интерпретировать осторожно.
Допустим, один вариант интерфейса получил среднюю оценку 8,4, а другой — 8,7. Без достаточной выборки и корректного дизайна исследования такая разница практически ничего не говорит о превосходстве одного решения. Тем более она не объясняет, какие элементы интерфейса работают лучше.
Гораздо полезнее сопоставить оценки с прохождением. Если пользователь ставит высокую оценку, но допускает несколько существенных ошибок, это отдельное наблюдение. Если низко оценивает сценарий, хотя выполняет его быстро, нужно выяснить причину: возможно, проблема связана не с понятностью, а с количеством действий или субъективным отношением к дизайну.
Открытые ответы ищут причины, а не победителя
Комментарии участников удобно группировать по смысловым темам: терминология, навигация, ожидания от действий, недостаток информации, визуальная заметность элементов. Но частота упоминания — не единственный критерий значимости.
Пользователь не всегда способен самостоятельно назвать причину затруднения. Он может сказать «что-то непонятно», хотя наблюдение показывает вполне конкретную проблему: два элемента воспринимаются как выполняющие одинаковую функцию.
Поэтому я не рекомендую анализировать открытые ответы отдельно от записей прохождения сценария.
В финале для каждой существенной проблемы желательно получить короткое описание: где она возникает, что делает пользователь, чего он ожидает, что происходит фактически и насколько это мешает достижению цели.
Так результаты исследования становятся материалом для следующей итерации, а не набором разрозненных мнений. Остается еще один важный вопрос: сколько участников достаточно для такой проверки и в какой момент повторяющуюся трудность действительно можно считать подтвержденным сигналом.
Вопрос о количестве участников возникает почти в каждом исследовании интерфейса. Часто команда хочет получить конкретную цифру: протестировать прототип на пяти, десяти или двадцати пользователях и считать результат надежным. Но универсального числа здесь нет. Необходимый объем выборки зависит прежде всего от того, какой вывод мы хотим сделать на основании исследования.
Если задача — найти основные препятствия в новом сценарии, можно начинать с небольшой группы и проводить тестирование итерациями. Если же команда хочет оценить долю пользователей, способных выполнить задачу, сравнить две версии интерфейса количественно или сделать вывод обо всей аудитории, требования к выборке будут другими.
Для поиска проблем и измерения нужны разные выборки
На раннем этапе прототипирования исследование обычно носит диагностический характер. Нам важно обнаружить места, где пользователи неправильно понимают интерфейс, и разобраться в причинах.
В таком исследовании небольшая выборка может дать много полезного материала. Если первые участники независимо друг от друга пытаются найти одну и ту же функцию не там, где ее разместила команда, нет необходимости ждать большой выборки, чтобы хотя бы сформулировать гипотезу о проблеме.
Но из этого нельзя делать количественный вывод. Если трое из пяти участников ошиблись, некорректно утверждать, что 60% всех будущих пользователей столкнутся с той же трудностью. Для оценки распространенности проблемы потребуется отдельное исследование с выборкой, рассчитанной под нужную точность результата.
Поэтому еще до набора участников стоит решить, что нам нужно: обнаружить проблему или измерить ее масштаб.
Повторяемость — важный, но не единственный сигнал
Если несколько пользователей независимо сталкиваются с одной трудностью, к ней стоит присмотреться. Однако я бы не устанавливал правило вроде «проблема считается подтвержденной после трех повторений».
Значимость зависит не только от частоты.
Представим, что один участник не смог понять предупреждение перед удалением данных и совершил необратимое действие. Другой пример — несколько человек на секунду задержались перед второстепенной кнопкой, но затем без ошибок продолжили работу. Первая проблема встретилась реже, однако ее последствия потенциально намного серьезнее.
При расстановке приоритетов я обычно учитываю сочетание трех факторов: насколько часто наблюдается затруднение, насколько сильно оно мешает завершить сценарий и насколько серьезны последствия ошибки.
Учитывайте различия между пользователями
Еще одна причина осторожно относиться к фиксированному количеству участников — неоднородность аудитории.
Интерфейс может быть совершенно понятным опытным пользователям и вызывать затруднения у новичков. Администратор продукта и рядовой сотрудник могут использовать одни и те же экраны с разными задачами. Даже терминология, привычная специалисту, способна оказаться непонятной человеку, который сталкивается с продуктом впервые.
Поэтому пять участников из одного сегмента не заменяют проверку другого сегмента, если их опыт и сценарии существенно различаются.
Перед рекрутингом стоит определить характеристики, которые действительно способны повлиять на прохождение прототипа: опыт работы с продуктом, профессиональная роль, частота выполнения конкретной задачи или знакомство с аналогичными сервисами.
При этом не нужно дробить аудиторию по десяткам формальных признаков. Сегментация полезна только тогда, когда у нас есть основания предполагать различия в поведении.
Проверяйте интерфейс итерациями
Для ранних прототипов мне ближе итерационный подход. Провести несколько сессий, разобрать повторяющиеся проблемы, изменить решение и протестировать обновленную версию часто полезнее, чем сразу показать один вариант большой группе.
Предположим, первые участники не понимают название раздела и систематически выбирают неправильный путь. Команда меняет структуру или формулировку, после чего проводит следующую серию тестов. Теперь исследование отвечает уже на новый вопрос: исчезла ли проблема или изменение лишь переместило ее в другое место.
Так прототип становится рабочим инструментом проверки гипотез, а не макетом, который команда пытается один раз «утвердить пользователями».
Когда нужна количественная проверка
Если после качественных сессий необходимо понять, насколько проблема распространена, можно перейти к количественному этапу. Например, показать интерфейс более широкой аудитории, дать одинаковое задание и зафиксировать выбор пользователей.
Для этого можно подготовить отдельный опрос в Тестографе, особенно если требуется собрать структурированные ответы по нескольким сегментам аудитории. Но дизайн такого исследования уже должен учитывать размер выборки, способ набора респондентов и то, какие различия команда планирует интерпретировать.
Самое важное — не придавать небольшой выборке статистический смысл, которого у нее нет. Пять или семь качественных интервью могут дать достаточно информации, чтобы обнаружить серьезную проблему и понять ее механизм. Но они не позволяют надежно определить процент пользователей, которые столкнутся с ней после релиза.
В результате решение об изменении прототипа лучше принимать не по одному числу участников, а по совокупности данных: повторяемости поведения, серьезности препятствия, контексту сценария и последствиям ошибки. После этого найденные проблемы можно превратить в конкретные изменения и проверить уже в следующей версии прототипа.
Тестирование прототипа заканчивается не в момент последнего интервью и не после выгрузки ответов. Ценность исследования появляется тогда, когда наблюдения превращаются в решения: команда понимает, что именно мешает пользователям, какие проблемы нужно исправить в первую очередь и что проверить повторно.
На этом этапе особенно важно не переходить слишком быстро от пользовательской реакции к конкретному редизайну. Фраза участника «я бы перенес эту кнопку наверх» еще не означает, что именно такое изменение решит проблему. Сначала нужно понять, почему человек вообще захотел ее перенести.
Разделяйте наблюдение, причину и решение
При разборе результатов я стараюсь не смешивать три уровня.
Такое разделение важно, потому что одно наблюдение может иметь несколько объяснений, а одна проблема — несколько вариантов решения. Исследование помогает определить, что не работает и почему это может происходить, но не всегда автоматически указывает единственный правильный вариант исправления.
Расставляйте приоритеты по влиянию на сценарий
После нескольких сессий обычно находится больше недостатков, чем команда может исправить за одну итерацию. Не все они одинаково важны.
В первую очередь я бы работал с проблемами, которые блокируют выполнение основной задачи, приводят к неправильному результату или заставляют пользователя существенно отклоняться от ожидаемого сценария. Затем — с повторяющимися затруднениями, которые не блокируют задачу, но делают взаимодействие менее понятным.
Наконец, остаются локальные замечания: отдельная формулировка показалась одному человеку непривычной, кому-то не понравилось расположение элемента или участник предложил альтернативный вариант. Такие наблюдения не нужно игнорировать, но и превращать каждое из них в задачу для разработки не стоит.
Хороший результат анализа — не длинный перечень пользовательских комментариев, а несколько приоритетных проблем с понятным контекстом возникновения.
Проверяйте исправление, а не просто вносите его
Одна из распространенных ошибок — обнаружить проблему в первом тестировании, изменить макет и считать вопрос закрытым.
Например, пользователи не замечали функцию, поэтому команда сделала кнопку крупнее. Но причина могла заключаться не в визуальной заметности: участники вообще не ожидали увидеть эту функцию на данном экране. В таком случае увеличенная кнопка не обязательно решит исходную проблему.
Поэтому существенные изменения желательно проверять повторно. Причем исследовательский вопрос во второй итерации должен быть связан с первоначальной трудностью: находят ли теперь пользователи функцию самостоятельно, правильно ли понимают новое название, сократилось ли количество ошибочных переходов.
Повторная проверка защищает от ситуации, когда исправление одной проблемы создает другую.
Не пытайтесь доказать, что новая версия «лучше» любой ценой
После нескольких итераций возникает соблазн сравнить средние оценки и выбрать вариант с более высоким баллом. Но если тестирование проводилось на небольшой качественной выборке, разница между условными 8,1 и 8,6 не должна становиться главным аргументом.
Гораздо содержательнее сравнить поведение: какие затруднения исчезли, какие сохранились, появились ли новые ошибочные пути и насколько самостоятельно пользователи выполняют критические задачи.
Если требуется полноценное количественное сравнение вариантов, его лучше проектировать как отдельное исследование с подходящей выборкой и заранее определенными метриками.
Встройте проверку понятности в процесс разработки
Самый полезный сценарий — когда тестирование прототипов перестает быть разовым мероприятием перед большим редизайном. Проверять можно отдельный новый сценарий, изменение навигации, форму, терминологию или функцию еще до того, как решение станет дорогим в реализации.
Рабочий цикл выглядит достаточно просто:
Опросы в этом процессе дополняют наблюдение за поведением. С помощью Тестографа можно собирать оценки после прохождения сценариев, открытые комментарии, проверять понимание терминологии или проводить более масштабный количественный этап после качественного исследования.
При этом сам по себе опрос не заменяет тестирование взаимодействия. Если мы проверяем понятность интерфейса, важно увидеть не только то, что человек о нем говорит, но и то, что он действительно делает.
В этом и состоит основное преимущество проверки через прототип. Команда получает возможность обнаружить неверные ожидания, неоднозначные названия и проблемные пользовательские пути еще до того, как они превратятся в готовый функционал. Исправить несколько экранов прототипа значительно проще, чем после релиза объяснять пользователям интерфейс, который должен был быть понятен без объяснений.
И если после исследования приходится заметно переделывать первоначальный вариант, это не признак неудачного тестирования. Наоборот, прототип выполнил свою задачу: помог найти проблему в тот момент, когда решение еще можно сравнительно быстро изменить.