Коридорное тестирование: получаем быстрый фидбек по макетам

  • Tutorial
Я как-то писал про частую ошибку проектировщиков, когда мы совсем забываем про пользователей, считая, что знаем как они думают и как им удобнее.
Понятно, что пользовательское тестирование сильно помогает при проектировании интерфейсов и целых продуктов, но чтобы что-то протестировать, нужен готовый продукт или как минимум прототип.
Создание прототипа хоть и сильно удешевляет тестирование, но тоже требует немалых сил и времени. Да и перед созданием прототипа часто возникают варианты концепции интерфейса, которые хорошо бы тоже протестировать, не затратив при этом больше получаса времени. В этом случае проектировщику может помочь так называемое «коридорное тестирование». На хабре этой теме было уделено не так много внимания, поэтому я решил поделиться несколькими приемами из своего опыта.

В чем смысл коридорного тестирования


Вы рисуете макет на бумаге или в любимой программе, выходите из своего кабинета, подходите к вашим коллегам в офисе и показываете им макет в распечатанном виде, либо на ноутбуке/планшете. Если по вашим макетам можно протестировать весь сценарий — отлично, залинкуйте их в каком-нибудь invisionapp.com и получите интерактивный прототип.
Коридорным тестирование названо из-за того, что позволяет очень быстро получить фидбек по вашему макету в любом месте, буквально в коридоре от проходящего мимо человека.

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


Создавая макет, вы очевидно понимали в каком сценарии он используется, поэтому демонстрируя человеку прототип, можно задать минимум три типа вопросов:
  1. Куда бы ты нажал, чтобы сделать/найти что-то
  2. Как ты думаешь, что произойдет при переходе/нажатии на эту ссылку или кнопку
  3. Как ты понимаешь эту фразу/название?

Куда бы ты нажал, чтобы сделать/найти что-то


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

Как ты думаешь, что произойдет при переходе/нажатии на эту ссылку


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

Как ты понимаешь эту фразу/название


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

5-секундный тест


Небольшое дополнение — пятисекундный тест макета. Вы показываете человеку макет на 5 секунд, затем убираете его и спрашиваете, что он увидел или запомнил в макете.
Возможно, это не лучший прием при тестировании интерфейсов, но он неплохо работает при тестировании промо-материалов, лендингов и баннеров. Например, так можно тестировать эффективность баннерных мест на портале или содержание самих баннеров, спросив после 5 секунд: «О чем был баннер на макете?».

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

Ноутбук или бумага


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

Плюсы и минусы коридорного тестирования


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

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

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

Комментарии 3

    0
    вы спрашивали не реальных пользователей, а тех, кто попался на глаза

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

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

      Самое читаемое