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

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

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

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

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

Создавая макет, вы очевидно понимали в каком сценарии он используется, поэтому демонстрируя человеку прототип, можно задать минимум три типа вопросов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Polar

Источник ^[3]