Я как-то писал про частую ошибку проектировщиков, когда мы совсем забываем про пользователей, считая, что знаем как они думают и как им удобнее.
Понятно, что пользовательское тестирование сильно помогает при проектировании интерфейсов и целых продуктов, но чтобы что-то протестировать, нужен готовый продукт или как минимум прототип.
Создание прототипа хоть и сильно удешевляет тестирование, но тоже требует немалых сил и времени. Да и перед созданием прототипа часто возникают варианты концепции интерфейса, которые хорошо бы тоже протестировать, не затратив при этом больше получаса времени. В этом случае проектировщику может помочь так называемое «коридорное тестирование». На хабре этой теме было уделено не так много внимания, поэтому я решил поделиться несколькими приемами из своего опыта.
В чем смысл коридорного тестирования
Вы рисуете макет на бумаге или в любимой программе, выходите из своего кабинета, подходите к вашим коллегам в офисе и показываете им макет в распечатанном виде, либо на ноутбуке/планшете. Если по вашим макетам можно протестировать весь сценарий — отлично, залинкуйте их в каком-нибудь invisionapp.com и получите интерактивный прототип.
Коридорным тестирование названо из-за того, что позволяет очень быстро получить фидбек по вашему макету в любом месте, буквально в коридоре от проходящего мимо человека.
Как проводить коридорное тестирование
Создавая макет, вы очевидно понимали в каком сценарии он используется, поэтому демонстрируя человеку прототип, можно задать минимум три типа вопросов:
- Куда бы ты нажал, чтобы сделать/найти что-то
- Как ты думаешь, что произойдет при переходе/нажатии на эту ссылку или кнопку
- Как ты понимаешь эту фразу/название?
Куда бы ты нажал, чтобы сделать/найти что-то
Этот вопрос задается при тестировании ожиданий пользователей от интерфейса. У ваших пользователей наверняка есть задачи, которые должны быть выполнены с помощью вашего продукта. Благодаря этому вопросу вы быстро сможете понять, найдет ли пользователь нужную функцию или информацию.
Как ты думаешь, что произойдет при переходе/нажатии на эту ссылку
Второй вопрос на тестирование ожиданий. С помощью него можно тестировать не только информационную архитектуру — так ли организована информация и названы ссылки, но и ожидания от поведения системы. Например, пользователь может вам ответить, что при нажатии на кнопку «купить» ожидал перехода к оформлению покупки, а вы спроектировали появление всплывающего окна с уведомлением о том, что товар в корзине.
Как ты понимаешь эту фразу/название
Третий вопрос помогает тестировать не только интерактивный интерфейс, т.е. кнопки и ссылки. Он помогает понять, насколько понятна информация, находящаяся на макете. Вопрос можно переформулировать: «Как думаешь, что этой фразой/графиком/картинкой тут хотят показать пользователю»?
Ответ может вас сильно удивить и вы поймете, что изначально закладываемая идея понимается людьми совсем по-другому.
5-секундный тест
Небольшое дополнение — пятисекундный тест макета. Вы показываете человеку макет на 5 секунд, затем убираете его и спрашиваете, что он увидел или запомнил в макете.
Возможно, это не лучший прием при тестировании интерфейсов, но он неплохо работает при тестировании промо-материалов, лендингов и баннеров. Например, так можно тестировать эффективность баннерных мест на портале или содержание самих баннеров, спросив после 5 секунд: «О чем был баннер на макете?».
Кстати, все перечисленные вопросы можно задавать и при проведении классического юзабилити-тестирования.
Ноутбук или бумага
Вы можете подходить к людям в коридоре с ноутбуком или планшетом, а можете с распечатанным на бумаке макетом. С одной стороны на экране макет смотреть привычнее для пользователя, с другой — на бумажном макете тестируемый сможет что-то нарисовать или изобразить свое видение. Мой выбор — и то и другое. Если есть возможность, подходите с планшетом, но держите на готове распечатанный вариант и, конечно, не забудьте взять с собой карандаш.
Плюсы и минусы коридорного тестирования
Коридорное тестирование помогает получить быстрый фидбек по вашим наброскам и идти дальше. С другой стороны, такой фидбек может быть не слишком репрезентативным, поскольку:
- вы спрашивали не реальных пользователей, а тех, кто попался на глаза
- люди находились не в тех условиях, где они обычно пользуются компьютером
- у людей не было достаточно времени, чтобы погрузиться в проблему.
Но коридорное тестирование и не рассчитано на тестирование больших сценариев, а так же не отменяет проведение полноценного юзабилити-тестирования.
При всех минусах я бы все же рекомендовал использовать этот прием. Он не поможет вам сделать продукт идеальным, но заставит задуматься над возможными проблемами проектирования, когда стоимость исправления ошибок ещё очень невелика.
Автор: Polar
