скачать книгу бесплатно
Как следствие, «самостоятельное» тестирование может быть куда более неформальным и ненаучным. Это значит, что можно тестировать меньшее количество пользователей (в поиске откровения), вы даже можете менять протокол прямо в процессе тестирования. Например, если первый участник оказывается не в состоянии выполнить задание и причина этого очевидна, то, перейдя к следующему участнику, вы можете изменить это задание (или даже пропустить его). Это невозможно при количественном тестировании, поскольку сделает недействительными его результаты.
Обычно ведущий сидит в той же комнате, что и участник, дает ему задания и предлагает думать вслух в ходе их выполнения.
Никакого сбора данных. Вместо этого члены команды разработчиков, заказчики и любые другие заинтересованные лица наблюдают за происходящим из соседней комнаты, используя дублирующий монитор. По окончании тестирования наблюдавшие собираются вместе, чтобы сравнить то, что ими замечено, и обсудить, какие проблемы нужно решить и как их следует решать.
Вот, пожалуй, и все.
Вы будете смеяться, но оно работает!
Свои мастер-классы я всегда начинаю с того, что провожу живое тестирование – «живое» в том смысле, что оно никоим образом не отрепетировано. Единственное, что я делаю заранее, так это выбираю сайт одного из участников мастер-класса, на его примере мы выполняем задание, максимально естественное для гипотетического посетителя этого сайта. (Допустим, если это медицинский сайт, я могу предложить задание, связанное с записью на прием к врачу.)
Я вызываю волонтера на роль участника тестирования, и за 15 минут мы проводим сокращенную версию теста. (Настоящий тест обычно длится около часа, хотя может быть пятиминутным, а может занять весь день.)
Результаты почти всегда одни и те же.
• Участник тестирования хорошо проводит время и в итоге срывает бурю аплодисментов за храбрость.
• «Хозяин» сайта все 15 минут яростно записывает, какие проблемы нужно решить, и спрашивает, нельзя ли получить запись всего происходившего, чтобы показать своей команде и боссу[9 - Один из таких «хозяев» написал мне спустя несколько месяцев после мастер-класса, что его команда, посмотрев запись демо-теста сайта, тут же внесла небольшое изменение, которое, как они посчитали (основываясь на результатах за прошедшие несколько месяцев), должно сэкономить их компании $100 000 в год. (Изменение это касалось привлечения клиентов к регистрации в интернет-магазине.)].
• Остальные приходят к мысли: «Хе-хе. И это всё? Так и я могу».
• По окончании тестирования я спрашиваю: «Как, на ваш взгляд, это стоящий способ провести 15 минут?» – и все согласно кивают головами.
Такое демо-тестирование нужно для того, чтобы показать людям, что а) это очень просто и б) это всегда работает. Многие из участников подозревают, что мне удается создать иллюзию легкости просто потому, что я уже много раз это делал. Но к концу дня, после того как каждый попробовал сам провести тестирование, все, кажется, понимают, что тут нет никакого волшебства и что все так же просто, как выглядит со стороны.
Нужно признать, что я немножко волновался, первые несколько раз проводя демо-тестирования перед публикой. Но на настоящий момент я проделал их уже штук пятьдесят – и всякий раз все получалось, вне зависимости от того, что это был за сайт и кто участвовал в тестировании.
Дело в том, что оно все-таки работает. Спросите любого человека, поднаторевшего в тестировании юзабилити, и вам ответят: «Да, оно почти всегда работает». Если вы посадите кого-нибудь – кого угодно – и попросите поработать с тем, что вы создали, он неизбежно столкнется с теми проблемами, с которыми столкнется большинство ваших пользователей.
Но почему же оно работает?
Может казаться непонятным, каким образом такая простая вещь (просто предложить человеку что-то сделать и посмотреть, как он это делает) помогает столь уверенно решать серьезные проблемы с юзабилити. Но если подумать об этом немножко (или, напротив, в течение нескольких лет, как, например, я), то обнаружатся причины для того, чтобы оно работало.
• Оно работает, потому что нет сайтов без недостатков. Мы все это знаем по собственному опыту. Часто ли вам случалось пользоваться сайтом и не нарваться на какую-нибудь проблему с юзабилити? И нередко это значительные проблемы, они вас фрустрируют, а порой даже мешают сделать то, что вы намеревались.
У некоторых, неновых, сайтов проблем меньше, особенно если они прошли уже несколько раундов тестирования юзабилити, но не обманывайте себя: у вашего сайта есть проблемы с юзабилити. Черт, даже у моего сайта есть проблемы с юзабилити, что, скажем прямо, довольно-таки стыдно. Да даже у Amazon.com есть проблемы с юзабилити, а всем известно, какого я высокого мнения об Amazon.com[10 - Люди любят писать мне о тех проблемах, которые они обнаружили на Amazon.com, словно я как-то могу эти проблемы исправить. Да, у меня есть на этом сайте привилегированное членство (за $79 в год я получаю «бесплатную» доставку на второй день), но этим мое влияние ограничивается. Кроме того, Amazon проводит столько тестирований юзабилити, что если там в самом деле есть какие-то проблемы, то, я уверен, не потому, что о них не знают; возможно, они еще не придумали, как эти проблемы решить.].
• Оно работает, потому что большинство серьезных проблем легко выявить. Опять-таки подумайте о тех проблемах с юзабилити, которые вам приходилось встречать на чужих сайтах. Разве вы не думали всякий раз: «Как они умудряются не знать об этой проблеме?» Большинство наиболее серьезных проблем лежат на поверхности, и практически каждый на них натыкается. Но нам почему-то кажется, что на наших собственных сайтах такого рода проблемы выявить сложно. Это мне всегда напоминает мультфильм о Дунсбери, где Фред спрашивает куратора стертого с лица земли Камбоджийского музея, был ли он разрушен в ходе секретных бомбардировок.
Проблемы с юзабилити, возникающие на вашем собственном сайте, могут быть для вас неочевидны, поскольку вы знаете, как он работает (или как он должен работать). Большинство же ваших пользователей этого не знают, в этом вся разница.
Разумеется, существуют не менее серьезные, но получше спрятанные проблемы с юзабилити, такие, на которые наткнется меньшее количество людей. Но если вы не можете уделить тестированию юзабилити значительное количество усилий и времени (если это ваша основная работа – тогда другой разговор), то я настоятельно рекомендую вам начать с разрешения очевидных проблем. Для большинства сайтов это еще не пройденный этап.
И наконец:
• Это работает, потому что наблюдение за пользователями совершенствует вас как дизайнера. Хотя такие термины, как «ориентированный на пользователя дизайн» и «опыт взаимодействия», есть сейчас в лексиконе большинства людей, работающих над веб-сайтами, очень немногие дизайнеры, разработчики, супервайзеры, менеджеры и заказчики – все те, кто имеет право голоса в процессе создания сайта, – тратят время на то, чтобы понаблюдать за тем, как люди пользуются сайтами. В результате мы приходим к тому, что создаем сайт, исходя из абстрактной модели пользователя, ориентированной в первую очередь на нас самих.
Наблюдая за пользователями, вы все лучше понимаете, как люди используют вещи и как вещи должны быть сделаны, чтобы ими можно было пользоваться. Это расширяет наши познания о разработке и дизайне примерно так же, как путешествия умножают наш опыт.
Что мешает провести тестирование
Но если тестирование юзабилити так просто и так полезно, то почему же оно так редко становится обязательной частью интернет-проекта? Даже сегодня очень мало организаций проводят тестирование юзабилити своих сайтов, а если все-таки проводят, то только один раз, ближе к завершению проекта.
Я думаю, главная причина заключается в том, что большинство людей по-прежнему не имеют собственного опыта тестирования юзабилити, а потому и не знают, насколько оно полезно. Но даже если такого рода опыт имеется, то нет недостатка в благовидных предлогах для того, чтобы тестирование все-таки не проводить.
Нехватка времени, например. Тестирование представляется нам мероприятием, которое потребует массу сил и времени, а у нас у всех и так уже слишком много работы. Календарный план разработчика чаще всего настолько плотный, что обычным становится такое отношение: «Сейчас сплавим с рук, а настроим потом».
Наконец, существует вполне естественный (и почти универсальный) страх показывать кому бы то ни было незаконченную работу. Мы всегда знаем, что то, над чем мы работаем, имеет недостатки, так зачем же показывать это другим людям, тратить и их, и свое собственное время для того, чтобы они сказали нам то, что мы и так знаем? (Да и кому нравится демонстрировать на публике изъяны своей работы?)
Все это очень здраво, но, как вы скоро сами убедитесь, вовсе не обязательно справедливо.
ЧАВО
Вы говорите об очень скромной выборке. Нельзя ли получитьболее достоверные данные с помощью инструментов, собирающих данные о поведении людей? Я имею в видувеб-аналитику.
Да, веб-аналитика может предоставить вам точную картину того, что люди делают на вашем сайте («72 % посетителей покинули вашу домашнюю страницу меньше чем через 5 секунд»). Объем выборки действительно очень велик (в общем-то, все ваши пользователи), информация основана на реальном использовании вашего сайта, вы можете составить практически любой статистический запрос – и мгновенно получить ответ. А с пришествием Google Analytics это стало доступно всем и каждому благодаря весьма привлекательной цене (безвозмездно, то есть даром!).
Проблема, однако, заключается в том (и любой специалист по юзабилити вам это скажет), что хотя аналитики могут вам в подробностях рассказать, что люди делают на вашем сайте, они не смогут сказать, почему они всё это делают. Например, если пользователи проводят очень много времени на какой-то конкретной странице, статистика не разъяснит вам, происходит это потому, что они нашли там много полезного и заняты чтением, или потому, что там ничего непонятно и они пытаются разобраться.
Тестирование же юзабилити, напротив, призвано помочь вам понять, почему люди делают то, что они делают.
Если задача заключается в том, чтобы обнаружить и решить проблемы с юзабилити, то, выбирая между великими и ужасными аналитиками, способными точно сказать, что делают мои пользователи (но ничего не знающими о том, что пользователи думают, когда это делают), и возможностью в течение часа пообщаться с одним-единственным человеком, понимая, что он думает и задавая наводящие вопросы, я всегда выберу последнее.
Глава 2
А теперь я распилю мою [прекрасную] ассистентку пополам
На что похоже самостоятельное тестирование
И это всё, друг мой?
ПРИПЕВ ИЗ ПРОПИТАННОЙ ТОСКОЙ ПЕСНИ ПЕГГИ ЛИ «IS THAT ALL THERE IS?»
В предыдущей главе я описал примеры тестов, которые я предлагаю участникам мастер-классов. А сейчас вы сами попробуете пройти один из них.
Большинство действий, которые вам предстоит выполнить, вы будете выполнять и при тестировании собственного сайта/приложения/чего угодно. Единственный нюанс: при реальном тестировании этих действий будет больше, и на каждое из них вы будете тратить больше времени (в сумме на все про все вам понадобится около часа).
Зайдите на сайт нашего издательства по адресу www.piter.com (http://www.piter.com/), найдите там страницу, посвященную этой книге, и скачайте файл Steve_Krug_UsabilityDemo[11 - Предлагаемый файл представляет собой запись, сделанную на одном из семинаров Стива Круга. Даже если вы не в совершенстве владеете английским языком, рекомендуем посмотреть этот тест, чтобы почувствовать себя его участником. – Примеч. ред.].
1. (Может быть, вы сейчас летите в стареньком самолете, где нет доступа в Интернет по WiFi, и потому не можете скачать этот файл. Не расстраивайтесь. Переходите к следующей главе, но потом не забудьте все же скачать и посмотреть его.)
2. Имейте в виду, что в конце демо-теста я попрошу вас составить небольшой список. В него вам надо будет записать три проблемы с юзабилити, которые вы заметили и которые вам хотелось бы исправить, если бы это был ваш сайт.
И это всё?
В общем-то, да! Ловкость рук и никакого мошенничества! Как видите, для проведения тестирования не нужно быть волшебником, не нужно обладать никакими специальными навыками. Одни люди заметят и захотят исправить больше, другие – меньше, но в среднем каждый участник тестирования получит немало полезных сведений.
ЧАВО
Извините, но зачем вы посвятили этому целую главу?
Затем, что этот пример важен, и таким образом я хотел заставить вас обратить на него внимание.
Глава 3
Одно утро в месяц – мы не просим о большем
План, которому запросто можно следовать
Одна банка в неделю – мы не просим о большем!
НЕВЕРОЯТНО УДАЧНЫЙ РЕКЛАМНЫЙ СЛОГАН КОМПАНИИ BLUE DIAMOND GROWERS, ПРИМЕРНО 1990 ГОД
Как я уже говорил в главе 1, у людей находится масса уважительных причин для того, чтобы не проводить тестирование юзабилити. Но главная причина, по которой большинство его не проводит, – убежденность в том, что это очень трудоемкая работа (такой вариант я называю Большим Навороченным тестированием).
В ходе моих мастер-классов я выработал, с моей точки зрения, максимально рациональный план, которым может воспользоваться всякий (вне зависимости от того, проводите вы тестирование для себя или для большой организации) и который позволит вам в ходе проекта протестировать то, что вы делаете, несколько раз.
Эта методика легко осуществима и приносит результаты. Она обнаруживает ровно столько проблем, сколько вы можете решить. Кроме того, она работает по принципу: самые существенные проблемы решаются первыми.
Сформулируем мой генеральный план так:
Одно утро в месяц – мы не просим о большем
В общем, от вас потребуется раз в месяц проводить раунд тестирования с тремя пользователями.
В день тестирования вы с утра что вам нужно исправить, проводите три теста, а за обедом обсуждаете их результаты. Ко второй половине дня тестирование юзабилити на данный месяц объявляется завершенным и вы знаете, прежде чем приступить к следующему его уровню[12 - Если вы занимаетесь гибким программированием, не волнуйтесь. Загляните в раздел ЧАВО на с. 40.].
Тут есть два ключевых слова, на которых следует сосредоточить внимание.
• Утро. Сокращение времени тестирования до половины дня (а это значит привлечение не более трех участников) облегчает процесс подбора пользователей и позволяет большему числу заинтересованных лиц прийти и понаблюдать за тестированием.
• Месяц. Раз в месяц – оптимальный интервал. С одной стороны, проводить тестирование чаще мало кто готов, с другой же – одно тестирование выявляет достаточно проблем, чтобы вам было чем заняться в течение следующего месяца.
Если вы объявите, что каждый третий четверг месяца вы намереваетесь проводить тестирование, вы таким образом донесете до ваших сотрудников мысль о том, что вы рассчитываете на их присутствие на тестировании, а до разработчиков – что к этому времени у них что-то должно быть готово.
Сделав тестирование регулярным этапом работы, вы избавитесь от необходимости решать, когда проводить тестирование; вы просто будете тестировать то, что окажется готово ко дню тестирования. (Если приходится думать, когда проводить тестирование, то все обычно кончается тем, что оно не проводится никогда.)
Самостоятельное тестирование против Большого Навороченного тестирования
Говоря «одно утро в месяц», я имею в виду не только расписание; это, кроме того, еще и формула, указывающая на то, что этот тест должен быть предельно простым, чтобы вы могли проводить его часто.
«Самостоятельному тестированию» доступно не все, что доступно Большому Навороченному тестированию, но оно достигает результатов, которые вам нужны, за ту цену, которую вы можете себе позволить. Перед вами сводная таблица различий, существующих между двумя этими типами тестирования (все элементы этой таблицы будут подробно прокомментированы в следующих главах):
ЧАВО
А что, действительно достаточно заниматься этим один разв месяц?
Ну, не совсем. Речь идет о том, что тестирование и обсуждение его результатов можно провести за одно утро. И для большинства членов команды на этом тестирование до следующего месяца закончится.
Но как человек, организующий этот процесс, вы перед каждым раундом тестирования должны будете проделать кое-какую подготовительную работу: решить, что именно тестировать, выбрать задания, написать сценарии, набрать участников и пригласить всех заинтересованных лиц.
На первый раз отведите на подготовку по крайней мере 2–3 рабочих дня. Однако при подготовке следующих раундов вы сможете сократить время до двух дней, а то и до одного.
А можно я буду заниматься тестированием чаще, чем разв месяц?
Разумеется. Одно утро в месяц – это минимум. Что бы вы ни делали, результат от более частого тестирования только улучшится.
Важно тут другое – делать это не реже раза в месяц. Как только вы перестанете проводить тестирование каждый третий четверг месяца, вам снова придется принимать решение, когда же его проводить, со всеми неизбежными последствиями.
Наш проект строится на принципах гибкогопрограммирования. А вы говорите – один раз в месяц! Я смеюсь!
Ах да, гибкое программирование[13 - Я говорю «гибкое программирование», но имею в виду любые популярные методы программирования, характеризующиеся очень коротким циклом разработки и смещением приоритетов с предварительного планирования в сторону итерационности и адаптируемости.]. Короткий цикл разработки в гибкой среде – если вы будете ждать целый месяц, вы вне игры. Ну что ж, в таком случае скажем так: «Спринт каждое утро, мы не просим о большем».
Во многих отношениях самостоятельное тестирование прекрасно совместимо с Гибким программированием, основанным на очень быстром производстве работающих элементов и предоставлении их пользователям. Единственная проблема заключается в том, что этими «пользователями» оказываются члены той же команды разработчиков. (Эту проблему и нужно решить.)
Поскольку вы намереваетесь проводить тестирование чаще, чем раз в месяц, то можно сделать каждый раунд еще более компактным (например, два участника вместо трех) и некоторые раунды проводить удаленно (глава 14), что сэкономит вам массу времени. Но в остальном процедура тестирования ничем не будет отличаться.
Главная сложность с тестированием юзабилити в гибкой среде заключается в том, что нужно постоянно бежать впереди паровоза и укладывать для него рельсы. У стремительно работающих программистов нет времени на то, чтобы разрабатывать прототип. Предполагается, что все, что они пишут, – это работающий код.
Это значит, что вам придется тратить часть своего времени на разработку прототипов того, что программисты будут делать в ходе следующего спринта. Значит, на каждом раунде вы сможете тестировать то, что разработано в ходе предыдущего спринта. Плюс бумажный проект того, что им нужно будет делать в ходе следующего.
Обязательно заниматься этим именно по утрам?
По утрам или нет – на результат не влияет. Легко представить себе ситуацию, когда участникам тестирования неудобно заниматься этим в рабочее время, и потому вы вынуждены проводить его в 6, в 7, а то и в 8 вечера (обед в таком случае можно посвятить привлечению наблюдателей, а совещание провести на следующий день, за завтраком или опять-таки за обедом).
Важно уложиться с тестированием в половину рабочего дня (это необходимо для того, чтобы на него могло прийти как можно больше наблюдателей) и обсудить результаты как можно скорее, пока впечатления еще свежи и все помнят детали.
Мне говорят: «Всякий раз ты тестируешь свой продукт на трехпользователях. Прости, но это недостаточный размер выборки. Твои результаты нельзя считать статистически достоверными!» Что ответить на это?
А вот что: «Вы абсолютно правы. Тестирование на трех пользователях не может дать статистически достоверных результатов. Выборка настолько мала, что тут и речи не может быть о статистике. Но цель такого тестирования заключается не в том, чтобы что-то доказать: задача в том, чтобы выявить наиболее существенные проблемы и, решив их, улучшить нашу продукцию. Эта методика работает, потому что большинство проблем настолько очевидны, что их существование не требует "доказательств"».
Постарайтесь произнести это уверенно и дружелюбно.
Что почем? Каков бюджет мероприятия?
Вот расчет затрат на год (за исключением вашего времени), необходимых для проведения самостоятельного тестирования:
А вот «бюджетный» вариант на случай, если вам не выделено вообще никакого бюджета:
Глава 4
Когда и что тестировать
Почему самое трудное приходится делать сначала
Давайте, на следующей неделе мы принесем вам набросок на салфетке побольше.
ТО, ЧТО ВСЕГДА ГОВОРЯТ МОИ КЛИЕНТЫ, КОГДА Я ПРОШУ ИХ ПОКАЗАТЬ ПРОЕКТ ДИЗАЙНА, ХОТЬ НА САЛФЕТКЕ
