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