Usability.by » Blog Archive Подводные камни юзабилити тестирования | Usability.by
Улучшаем взаимодействие пользователей с вашим сервисом Повышаем конверсию
в продажи, заявки или
звонки
Проектируем
новые
продукты
Компания 1Point осуществляет весь спектр услуг в области юзабилити, дизайна, user experience
и веб-аналитики

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

Геннадий Драгун Геннадий Драгун, Lead Information Architect EPAM

Статья 2007 года с сайта www.ui.by с исправлениями 2009 года.

Насколько можно верить результатам юзабилити тестирования? Насколько они достоверны? Стоит ли проводить юзабилити тестирование вообще? Можно ли доверять проведение юзабилити тестирование новичкам, закончившим в лучшем случае недельные курсы, или этим должны заниматься только профессионалы?

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

Разные команды специалистов, используя разные методы исследования могут получить очень разные результаты, что и показали исследования Рольфа Молиха, который вместе с Якобом Нильсеном много лет назад изобрел метод эвристической оценки.

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

1. Отсутствие “Пилотного” теста

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

2. Однократное тестирование

Часто бывает, что систему протестировали на пользователях один раз, вроде бы исправили обнаруженные проблемы юзабилити, и система — готова. А действительно ли исправили проблемы? Систему нужно протестировать еще как минимум один раз, чтобы убедиться в исправлении проблем и в отсутствии появления новых, вызванных исправлениями. Похоже на Regression Testing в QA.

3. Тестирование “сырой” системы

Юзабилити тестирование способно наиболее ярко продемонстрировать свои возможности при тестировании “сырой” системы, той которую никто толком не проектировал, в которой полно очевидный проблем интерфейса. Но не похоже ли это на “стрельбу из пушки по воробьям”, если многие из этих проблем можно обнаружить используя более простые, быстрые и дешевые методы, такие как “Проверку по контрольным спискам” или “Инспекцию пользовательского интерфейса”?

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

4. “Слепое” доверие к пользователю

В UCD кругах достаточно популярна поговорка: “Пользователь всегда прав (’User is the king’)”. Так вот, нужно достаточно осторожно относиться к тому, что говорят, да и делают респонденты тестирования. Во-первых, респонденты — еще не пользователи, они находятся в искусственной обстановке и у них нету внутреннего стимула для использования системы. Если по каким-то причинам респонденты теста не попадают в целевую аудиторию системы, то к их поведению и высказываниям нужно относится особенно осторожно, система-то разрабатывалась совсем не для них.

Нужно быть осторожными и при малом числе респондентов. Если один из пяти респондентов высказал какое-то замечание к системе, то это — его личное замечание, а не замечание 20% пользователей. (Подробнее об этом смотри в следующем разделе.) Бывает, что на любые твои доводы ответом будет только: “Но ведь ПОЛЬЗОВАТЕЛЬ так сказал…” Ещё раз: “Респонденты — не пользователи”.

5. Страсть к статистике

Начинаем переходить к реальным вещам.

Встречается, что юзабилити специалисты пытаются придать дополнительный вес результатам своих исследований, используя различные статистические формулы и диаграммы. Этим числам нельзя верить на первый взгляд. Во-первых, сколько специалистов реально владеет статистическими методами, а не способно только запихнуть данные в SPSS и потом обыгрывать полученные результаты? Во-вторых, насколько часто проводятся исследования с числом респондентов, достаточным для того, чтобы претендовать на какую-то статистическую достоверность?

Причиной данной сложности является то, что очень многие начинающие, да и относительно опытные юзабилити тестировщики не знают или не обращают внимания на существование и различия между различными видами тестирования: текущим (formative), итоговым (summative), проверочным (validative) и сравнительным (comparative). Подробное описание различий можно прочитать в этой книге. (На русский не переведена.)

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

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

6. Субъективность юзабилити тестирования

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

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

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

7. Тестирование ради тестирования

Мы все знаем, что лучше «тестировать чаще, тестировать раньше», что «плохой тест лучше отсутствия теста вообще». Но в связи со сказанным в предыдущем пункте: «Не лучше ли хорошая экспертная оценка плохого тестирования?»

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

Иначе, получается бесцельное «тестирование ради тестирование», попытки нащупать что-нибудь вслепую. Как-то услышал жалобы одного «юзабилити менеджера»: «Ставлю перед подчиненным задачу провести юзабилити тестирование модулей приложении, а он никак не может завершить с планированием. Уж и не знаю, что мне с ним таким делать…» Задачи надо нормальные ставить.

Другой случай «тестирования ради тестирования», это тестирование на поздних стадиях, тестирование для галочки, когда целью является не поиск возможных дефектов, а сам факт того, что тестирование было проведено и об этом можно написать в пресс-релизе.

Twitter Facebook Google Buzz Вконтакте МойМир Google Bookmarks delicious Memori.ru БобрДобр.ru Mister Wong Technorati МоёМесто.ru I.ua


10 комментариев

  1. Интересно было почитать.. спасибо за дополнения. Хотя в принципе большинство из написанного для меня и раньше было очевидным.

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

  3. Геннадий Драгун:

    @roman
    Так и делают. Это я про кнопочку. Только иногда бывает уже поздно что-то менять, когда все уже сделано и запущено. Поэтому безопаснее собирать информацию до запуска. Чем раньше, тем лучше. Чем меньше сделано, тем меньше прийдется переделывать в случае ошибки. :)

  4. «Чем раньше, тем лучше. Чем меньше сделано, тем меньше прийдется переделывать в случае ошибки.» а как вы соберете информацию до запуска, опросите коллег по цеху ? имхо это не эффективно, а те 1000 посетителей на сайт и будут первыми бета тестерами вашего продукта.

  5. […] юзабилити-тестирования в статье Геннадия Драгуна “Подводные камни юзабилити тестирования“, является риск “слепого” доверия к мнению […]

  6. Ivan:

    Коллеги, сейчас появились веб-сервисы для удаленного юзабилити тестирования. В принципе, приемлимо и недорого. Для английских сайтов пользуемся http://www.usertesting.com, для русских — http://www.testuser.ru

    Но для мини a/b тестирования в принципе для начала подходит Google Analytics.

  7. .

    good info!…

  8. .

    thanks!…

Комментировать