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

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

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

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

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

Кого приглашать и почему коллег недостаточно

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

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

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

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

Как написать задание без подсказки ответа

Задание описывает цель человека, но не маршрут по интерфейсу. «Откройте раздел “Услуги” и нажмите “Заказать аудит”» проверит выполнение инструкции. «Вам нужно понять, почему сайт медленно работает; найдите подходящую помощь и выясните, что потребуется для обращения» покажет, насколько сайт поддерживает реальный выбор.

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

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

Для каждого задания заранее запишите признак завершения. Например, человек правильно объяснил, что входит в услугу, нашёл ограничения и определил следующий шаг. Сам переход на нужную страницу не всегда означает, что содержание понятно. Попросите пересказать решение своими словами, не подменяя вопросом «вам всё понятно?» проверку понимания.

Практический разбор

Два варианта задания для одной страницы

  1. Подсказывает интерфейс

    «В верхнем меню выберите “Услуги”, откройте аудит и найдите блок с этапами». Участнику уже сообщили, где искать.

  2. Проверяет задачу

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

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

Как подготовить короткую сессию

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

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

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

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

Как вести беседу и не помогать слишком рано

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

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

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

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

Что записывать, чтобы выводы можно было проверить

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

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

Поле протоколаУсловный примерЗачем нужно
ЗадачаВыбрать помощь с медленным сайтомСвязывает наблюдение с целью
ДействиеОткрыл разработку вместо аудитаПоказывает фактический путь
ОбъяснениеНе понял, что аудит можно заказать отдельноУточняет значение выбора
ПомощьВедущий указал на соседнюю услугуНе даёт считать результат самостоятельным
Вопрос к правкеКак показать границы услуги до переходаНаправляет последующее решение

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

Практический разбор

Как превратить наблюдение в задачу команде

  1. Наблюдение

    Участник выбрал неподходящую услугу и объяснил, как понял её название.

  2. Проблема

    Названия не помогают различить разовую проверку и разработку сайта.

  3. Изменение

    Предложить более понятные названия и короткое описание границ.

  4. Повторная проверка

    Новые участники выполняют ту же задачу без подсказки ведущего.

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

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

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

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

В материале GOV.UK о качественном тестировании описан метод оценки удобства продукта через наблюдение. Небольшое исследование помогает понять характер затруднений, но не устанавливает точную долю всех посетителей, которые столкнутся с ними. В отчёте пишите число наблюдений и состав участников, а не обобщение «80% аудитории» по четырём людям из пяти.

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

Как провести следующий раунд и оценить пользу

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

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

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

Для первого исследования подготовьте один вопрос, несколько подходящих участников, нейтральные задания и таблицу наблюдений. Если нужна помощь с разбором интерфейса и постановкой правок, можно обсудить сайт со ШТАБ ИТ. Отдельно проверьте адаптивность: беседы о понятности и техническая проверка отображения дополняют друг друга.

Источники и полезные ссылки

  1. GOV.UK: модерируемое тестирование удобства ↗
  2. GOV.UK: качественное тестирование удобства ↗
  3. GOV.UK: удалённое исследование по видеосвязи ↗

Интерфейсы и возможности сервисов могут меняться. Перед настройкой сверяйтесь с актуальной документацией.

Игорь Крещенко

Руководитель ШТАБ ИТ. Занимается управлением проектами, веб-разработкой, рекламой и PR. Подробнее об авторе →