Откуда взялись часто задаваемые вопросы в совершенноновой книге?
Хороший вопрос. Дело в том, что обо всем этом меня спрашивают участники семинаров. Я смело предположил, что читатели захотят уточнить те же моменты.
Обнаружение проблем с юзабилити
Глава 1
Слонов-то не видать
Что такое самостоятельное тестирование юзабилити, почему оно всегда срабатывает и почему его так редко проводят
– Для чего ты вертишь курицу у себя над головой?
– Так я отгоняю слонов.
– И что, помогает?
– Ну, слонов-то не видать!
ОЧЕНЬ СТАРАЯ ШУТКА
Итак, прежде чем мы займемся «самостоятельным тестированием юзабилити», разберемся, что же такое «тестирование юзабилити».
Это очень просто:
Тестирование юзабилити – это наблюдение за людьми, которые используют то, что вы создаете/проектируете/строите (или то, что вы уже создали/спроектировали/построили), с целью а) упростить их работу или б) доказать, что все и так просто.
Существует масса видов и сортов тестирования юзабилити, но все их объединяет то, что они предполагают наблюдение за людьми, в самом деле использующими данную вещь.
Этот элемент достоверного использования как раз то, что принципиально отличает тестирование юзабилити от опросов, интервью, работы с фокус-группами, где интересуются мнением людей о тех или иных вещах или предыдущим опытом их использования.
Хороший способ разобраться во всех имеющихся методах – разделить их на количественные и качественные.
Количественный тест нужен для того, чтобы нечто проверить («В самом ли деле последняя версия лучше, чем предыдущая?»; «Работает ли наш сайт так же хорошо, как сайты наших конкурентов?»); осуществляется он путем сравнения таких показателей, как процент успешных попыток (сколько людей смогут выполнить те задания, которые вы им дали) и время, которое на это потребуется.
Поскольку задача количественных тестов – нечто проверить, то они оказываются очень похожи на научные эксперименты: они должны быть точными, иначе результаты их не будут надежными. Это значит, что вы должны создать протокол тестирования и следовать ему неукоснительно с каждым из участников[8]. Информация должна собираться очень тщательно. Вы должны собрать достаточно много участников, чтобы полученные вами результаты были статистически значимы; кроме того, эти участники должны быть типичными представителями вашей целевой аудитории, чтобы вы имели возможность экстраполировать полученный результат на всех остальных. Все это значит, что вы должны понимать, что вы делаете, и делать это аккуратно.
В количественных тестах обычно стараются минимизировать общение с участником, чтобы избежать возможного искажения результатов. Крайняя форма («Голос свыше») выглядит так: участник сидит в комнате один, ведущий дает ему указания по рации, а наблюдатель следит за происходящим сквозь полупрозрачное стекло и фиксирует результаты.
Так что же такое «самостоятельное тестирование юзабилити»?
Как вы уже могли догадаться, тот тип тестирования, который я вам намереваюсь рекомендовать, находится на противоположном конце этой количественно-качественной шкалы.
«Самостоятельное» тестирование юзабилити – качественное тестирование. Целью его не является проверить что бы то ни было; цель его – раскрыть сознание, достичь откровения, позволяющего улучшить то, что вы делаете.
Как следствие, «самостоятельное» тестирование может быть куда более неформальным и ненаучным. Это значит, что можно тестировать меньшее количество пользователей (в поиске откровения), вы даже можете менять протокол прямо в процессе тестирования. Например, если первый участник оказывается не в состоянии выполнить задание и причина этого очевидна, то, перейдя к следующему участнику, вы можете изменить это задание (или даже пропустить его). Это невозможно при количественном тестировании, поскольку сделает недействительными его результаты.
Обычно ведущий сидит в той же комнате, что и участник, дает ему задания и предлагает думать вслух в ходе их выполнения.
Никакого сбора данных. Вместо этого члены команды разработчиков, заказчики и любые другие заинтересованные лица наблюдают за происходящим из соседней комнаты, используя дублирующий монитор. По окончании тестирования наблюдавшие собираются вместе, чтобы сравнить то, что ими замечено, и обсудить, какие проблемы нужно решить и как их следует решать.
Вот, пожалуй, и все.
Вы будете смеяться, но оно работает!
Свои мастер-классы я всегда начинаю с того, что провожу живое тестирование – «живое» в том смысле, что оно никоим образом не отрепетировано. Единственное, что я делаю заранее, так это выбираю сайт одного из участников мастер-класса, на его примере мы выполняем задание, максимально естественное для гипотетического посетителя этого сайта. (Допустим, если это медицинский сайт, я могу предложить задание, связанное с записью на прием к врачу.)
Я вызываю волонтера на роль участника тестирования, и за 15 минут мы проводим сокращенную версию теста. (Настоящий тест обычно длится около часа, хотя может быть пятиминутным, а может занять весь день.)
Результаты почти всегда одни и те же.
• Участник тестирования хорошо проводит время и в итоге срывает бурю аплодисментов за храбрость.
• «Хозяин» сайта все 15 минут яростно записывает, какие проблемы нужно решить, и спрашивает, нельзя ли получить запись всего происходившего, чтобы показать своей команде и боссу[9].
• Остальные приходят к мысли: «Хе-хе. И это всё? Так и я могу».
• По окончании тестирования я спрашиваю: «Как, на ваш взгляд, это стоящий способ провести 15 минут?» – и все согласно кивают головами.
Такое демо-тестирование нужно для того, чтобы показать людям, что а) это очень просто и б) это всегда работает. Многие из участников подозревают, что мне удается создать иллюзию легкости просто потому, что я уже много раз это делал. Но к концу дня, после того как каждый попробовал сам провести тестирование, все, кажется, понимают, что тут нет никакого волшебства и что все так же просто, как выглядит со стороны.
Нужно признать, что я немножко волновался, первые несколько раз проводя демо-тестирования перед публикой. Но на настоящий момент я проделал их уже штук пятьдесят – и всякий раз все получалось, вне зависимости от того, что это был за сайт и кто участвовал в тестировании.
Дело в том, что оно все-таки работает. Спросите любого человека, поднаторевшего в тестировании юзабилити, и вам ответят: «Да, оно почти всегда работает». Если вы посадите кого-нибудь – кого угодно – и попросите поработать с тем, что вы создали, он неизбежно столкнется с теми проблемами, с которыми столкнется большинство ваших пользователей.
Но почему же оно работает?
Может казаться непонятным, каким образом такая простая вещь (просто предложить человеку что-то сделать и посмотреть, как он это делает) помогает столь уверенно решать серьезные проблемы с юзабилити. Но если подумать об этом немножко (или, напротив, в течение нескольких лет, как, например, я), то обнаружатся причины для того, чтобы оно работало.
• Оно работает, потому что нет сайтов без недостатков. Мы все это знаем по собственному опыту. Часто ли вам случалось пользоваться сайтом и не нарваться на какую-нибудь проблему с юзабилити? И нередко это значительные проблемы, они вас фрустрируют, а порой даже мешают сделать то, что вы намеревались.
У некоторых, неновых, сайтов проблем меньше, особенно если они прошли уже несколько раундов тестирования юзабилити, но не обманывайте себя: у вашего сайта есть проблемы с юзабилити. Черт, даже у моего сайта есть проблемы с юзабилити, что, скажем прямо, довольно-таки стыдно. Да даже у Amazon.com есть проблемы с юзабилити, а всем известно, какого я высокого мнения об Amazon.com[10].