Эту книжку мне захотелось написать девять лет назад, как только я расквитался с предыдущей (она называлась «Не заставляйте меня думать»).

Совершенно случайно в процессе работы над рукописью я осознал три вещи.

• Лучшее, что можно сделать для усовершенствования сайта (или любой другой продукции, с которой должен так или иначе взаимодействовать пользователь), – это провести тестирование юзабилити.

• Поскольку владельцы большинства контор – жадины, они не склонны нанимать штатных тестировщиков, и поэтому тестировать свою продукцию должен уметь каждый. И наконец…

• Я подумал, что могу написать неплохую книжку о том, как овладеть этим умением.

Лишь одно меня смущало: я ненавижу сочинять тексты.

Ну, вообще-то, я не то чтобы так уж прямо ненавижу это делать. Может быть, стоило сказать по-другому: меня это порядком выматывает.

И вот, знаете, это не те мучения, которые, например, испытывает человек, стоящий у прилавка и размышляющий: «Черт, какой же iPhone купить? Черненький или беленький?» Я бы сравнил это с мучениями человека, который не спал трое суток подряд. Я всегда говорил: нет работы труднее, чем работа писателя, и для меня непостижимо, как ею можно заниматься по своей воле. Мне кажется, нормального человека на это может подвигнуть разве что дуло пистолета, приставленное к затылку (каковым, без сомнения, как раз и является дедлайн).

Мне чертовски повезло: предыдущая книга сослужила добрую службу. Одним из побочных эффектов ее появления на свет стала чудесная возможность провести ряд семинаров, что лишило меня мотивации сразу садиться за новую рукопись. Преподавание мне нравится куда больше, чем писательство или консалтинг [1] .

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

И вот, три года назад, после длительных размышлений, я наконец понял, что надо сделать. Я сменил формат семинаров: теперь участникам предлагалось в течение всего дня заниматься тем, чему посвящена эта книга: проводить самостоятельное тестирование.

Семинары в таком стиле я проводил в течение нескольких лет, и в результате мне удалось понять очень многое из того, чему я учил своих студентов. (Да, так и есть, уверяю вас: если вы хотите по-настоящему чему-нибудь научиться, попробуйте обучить этому других.) Глядя на то, как они постепенно овладевали новыми знаниями, я все больше убеждался в значимости самостоятельного тестирования.

Наконец, год назад, в минуту слабости, я не устоял. Заключил контракт с издательством на написание этой книги (и это означало, что к моему затылку приставили дуло дедлайна). В конце концов, количество людей, которые могут позволить себе провести целый день на семинаре, ограничено. Хотелось бы верить, что чтение этой книги в какой-то мере сможет заменить всем остальным радость живого общения со мной.

Нужна ли этому миру еще одна книга о тестировании юзабилити?

Я не изобретал велосипед. Тестирование юзабилити пришло в наш мир давным-давно, и немало известных людей, самый влиятельный из которых – Якоб Нильсен, вот уже более двадцати лет проповедуют идеи «доступного тестирования юзабилити».

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

Однако эта книга отличается от существующих по меньшей мере двумя аспектами.

•  Она НЕ является всеобъемлющей . Я предполагаю, что для вас юзабилити не стало и не станет делом всей жизни и что этого слова даже нет в вашей должностной инструкции. Раз так, вам вовсе необязательно знать все нюансы и тратить уйму времени на их постижение. Эту книгу, как и предыдущую («Не заставляйте меня думать»), я постарался сделать достаточно тонкой, такой, чтобы ее можно было прочитать, например, в самолете [2] .

Эта книга написана вовсе не для того, чтобы сделать из вас сурового эксперта по юзабилити или тестированию. Она нужна для того, чтобы вы знали, с какого конца подступиться к тестированию как таковому. Кого-то из вас, несомненно, эта тема увлечет настолько, что появится потребность узнать о ней как можно больше. Для таких я написал главу 15. Но вообще-то, чтобы провести тестирование и получить от этого огромнейшую отдачу, не нужно знать ничего сверх написанного на этих страницах.

•  Эта книжка не только о том, как НАХОДИТЬ проблемы с юзабилити . В отличие от многих других изданий, в этом рассказывается еще и о том, как устранять обнаруженные проблемы. В главах с 10-й по 13-ю я объясняю, как выбирать, что именно и каким образом исправлять. Об этом, на самом деле, написано довольно мало, а зря. Мне кажется, что это как-то… в общем, это важно.

Зовите меня безответственным

Некоторые профессионалы в области юзабилити полагают, что доверять «любителям» проведение тестирования безответственно. Так, между прочим, говорят многие умные люди, и я ценю их мнение. Аргументы, которые они приводят, обычно сводятся к следующим.

• Любители сделают все тяп-ляп, и в результате а) объект тестирования станет не лучше, а только хуже и б) это заставит всех считать, что тестирование никому не нужно.

• Любители сделают все безукоризненно, и профессионалы останутся без работы.

Прежде чем я займусь оспариванием этих позиций, я хотел бы донести до вас одну предельно простую мысль:

Если вы можете позволить себе нанять профессионала, который проведет тестирование [3] , наймите его

Поймите меня правильно: я не собираюсь подвергать сомнению то, что хороший специалист справится с тестированием лучше, чем любитель. Такой специально обученный человек не только имеет опыт разработки и проведения тестов – он уже собаку съел на выявлении одних и тех же проблем, которые встречаются у большинства разработчиков. Он прекрасно знает, как их устранять.

И кстати, никогда не повредит показать свое детище какому-нибудь постороннему человеку, который посмотрит на него свежим взглядом. Вы платите профессионалу за тестирование и при этом совершенно бесплатно получаете возможность услышать независимую экспертную оценку проекта в целом. Нанятому специалисту в любом случае придется это сделать – иначе он не сможет понять, как тестировать вашу продукцию.

Кроме того, есть еще одно, вполне объективное, соображение: постороннему специалисту (в отличие от сотрудника вашей компании) не составит никакого труда сообщить вам горькую правду о том, например, что рассматриваемое изделие не работает или что оно никому не нужно.

Проблема в другом. Абсолютное большинство разработчиков веб-сайтов не могут себе позволить профессионального тестировщика юзабилити. Во всяком случае, мало у кого хватает денег более чем на один раунд тестирования. Хуже того, даже если бы они имели такую возможность, едва ли они смогли бы найти настоящего специалиста [4] .

Теперь еще одна важная мысль. Я не считаю, что любители делают все тяп-ляп. Лично я такого никогда не видел. И еще я уже много лет прошу, чтобы хоть кто-нибудь поведал мне историю о том, как в результате такого «любительского» тестирования ухудшилось юзабилити продукции. Не слышал я о таких случаях [5] !

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

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

В 2001 году на ежегодной конференции UPA (Usability Professionals Association – Ассоциация специалистов по юзабилити [6] ) Якоб Нильсен блестяще описал свое видение того, что будет происходить с юзабилити в будущем. Он сказал, что «простым тестированием на уровне пользователя (отладкой дизайна)» придется заниматься всем. Профессионалам же достанется работа, требующая действительно специальных знаний и умений: проведение количественных тестов, сравнительных тестов и тестирование новых технологий. Наиболее опытные профессионалы, по словам Нильсена, займутся такими сложными вещами, как международное тестирование и разработка новых методологий (уделом этих мудрецов станет философствование и распитие спиртных напитков в кругу таких же аксакалов).

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

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

Не попало в кадр

Не пытайтесь найти в этой книге следующее.

•  Разные методы тестирования . Существует великое множество разнообразных методик тестирования юзабилити: качественные, количественные, суммирующие, конструктивные, формальные, неформальные, на основе больших и небольших моделей, сравнительные, эталонные, и так далее, и так далее. Все они по-своему хороши.

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

•  Тестирование пультов управления ядерными реакторами и воздушным движением , а также тестирование любых других систем, неправильное управление которыми может привести к гибели людей и другим серьезным последствиям. В книге не описывается, как с помощью тестирования организовать систему с «защитой от дурака». Цель всех интеллектуальных упражнений, о которых здесь будет написано, – всего лишь упростить работу с системой. Когда от вашей разработки зависят жизни людей, надо проводить всестороннее, тщательно спланированное, количественное, основанное на больших моделях, воспроизводимое, научно обоснованное исследование, дающее статистически достоверные результаты. По меньшей мере, лично я на вашем месте поступил бы именно так.

•  Истины в последней инстанции . Большинство проблем, которые я буду описывать, можно решать разными способами. Я старался выбирать наиболее универсальные или простые. Но это не означает, что не существует иных вариантов.

Что? Максимы? Можно не называть их «максимы»…

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

Для чего я их вставил, да еще и так сильно выделил? Я знаю, что именно такие краткие высказывания многие любят называть критичными факторами успеха. Обучая людей выполнять тестирование юзабилити, я понял, что, по большому счету, чтобы все получилось, надо помнить всего лишь о нескольких вещах. Но почему-то у многих не получается удержать их в голове. Чтобы облегчить эту задачу, я облек самые главные идеи в краткую и более-менее запоминающуюся форму.

Вы можете смело забыть все, что написано в этой книге, кроме приведенных в ней афоризмов. Для вашего удобства я перечислил их все в главе 16. Если хотите, можете вырезать и повесить в рамочке на стену.

Напутственные слова

Если быть точным, то всего этих слов четыре штуки: Вы способны это сделать.

Долгие годы моим девизом было выражение «Подумаешь, бином Ньютона!» Я уверен, что решение большинства проблем юзабилити не требует больших интеллектуальных усилий. Тем не менее необходимо обучать людей проводить тестирование достаточно качественно, чтобы его ценность была очевидна.

Вот вы сейчас читаете этот текст – из этого я делаю вывод, что дефакто вы в своей конторе являетесь человеком, защищающим права пользователя. Вы заинтересованы в том, чтобы ваша «продукция» (что бы это ни было: веб-сайт, сетевое или локальное приложение, да что угодно!) была дружественной по отношению к пользователю.

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

Мужайтесь! И ни в коем случае не унывайте. Это совсем не больно, это не нанесет вреда вашей «продукции», и вы сможете приступить к этому уже на следующей неделе. А вот еще один нюанс, о котором почему-то все всегда забывают: это весело! Все мои знакомые, которые долгие годы проводят тестирование юзабилити, по-прежнему находят его очень увлекательным занятием.

Так что вот вам мой совет: начинайте как можно быстрее, делайте все как можно проще и – получайте удовольствие!

ЧАВО

Это не переработка вашей предыдущей книги «Не заставляйте меня думать»?

Черт, кто включил этот микрофон?

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

Можно считать это издание дополненной версией главы из «Не заставляйте меня думать», в которой я объясняю, как проводить тестирование юзабилити [7] .

А если я не собираюсь ничего тестировать? Читать мне эту книгу?

Читать. Даже если сейчас вам кажется, что вы никогда, ни при каких обстоятельствах не будете проводить тесты, которые я здесь описываю, узнать о самом процессе (и в особенности о том, как устранять проблемы) вам будет очень полезно.

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

Не преуменьшаются ли здесь ожидающие нас сложности?

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

А ваши советы годятся только для веб-сайтов?

При написании книги я сконцентрировался на тестировании веб-сайтов, потому что в наши дни большинству нужно именно это и потому что это позволило сделать книжку тонкой и простой. Но ровно те же методы и принципы можно и нужно применять при тестировании и улучшении всего, чем пользуются люди. Сетевые и локальные приложения – это самые очевидные объекты для тестирования, но никто не мешает теми же методами оценить избирательные бюллетени, сотовые телефоны, презентации, сверстанные в PowerPoint, инструкции к цифровым фотикам и бланки, которые вы заполняете, когда приходите к врачу. Я бы предложил вам всюду, где у меня написано «ваш веб-сайт», считать, что там написано «ваша продукция».

Откуда взялись часто задаваемые вопросы в совершенноновой книге?

Итак, прежде чем мы займемся «самостоятельным тестированием юзабилити», разберемся, что же такое «тестирование юзабилити».

Это очень просто:

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

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

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

Количественный тест нужен для того, чтобы нечто проверить («В самом ли деле последняя версия лучше, чем предыдущая?»; «Работает ли наш сайт так же хорошо, как сайты наших конкурентов?»); осуществляется он путем сравнения таких показателей, как процент успешных попыток (сколько людей смогут выполнить те задания, которые вы им дали) и время, которое на это потребуется.

Поскольку задача количественных тестов – нечто проверить, то они оказываются очень похожи на научные эксперименты: они должны быть точными, иначе результаты их не будут надежными. Это значит, что вы должны создать протокол тестирования и следовать ему неукоснительно с каждым из участников [8] . Информация должна собираться очень тщательно. Вы должны собрать достаточно много участников, чтобы полученные вами результаты были статистически значимы; кроме того, эти участники должны быть типичными представителями вашей целевой аудитории, чтобы вы имели возможность экстраполировать полученный результат на всех остальных. Все это значит, что вы должны понимать, что вы делаете, и делать это аккуратно.

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

Так что же такое «самостоятельное тестирование юзабилити»?

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

«Самостоятельное» тестирование юзабилити – качественное тестирование. Целью его не является проверить что бы то ни было; цель его – раскрыть сознание, достичь откровения, позволяющего улучшить то, что вы делаете.

Как следствие, «самостоятельное» тестирование может быть куда более неформальным и ненаучным. Это значит, что можно тестировать меньшее количество пользователей (в поиске откровения), вы даже можете менять протокол прямо в процессе тестирования. Например, если первый участник оказывается не в состоянии выполнить задание и причина этого очевидна, то, перейдя к следующему участнику, вы можете изменить это задание (или даже пропустить его). Это невозможно при количественном тестировании, поскольку сделает недействительными его результаты.

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

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

Вот, пожалуй, и все.

Вы будете смеяться, но оно работает!

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

Я вызываю волонтера на роль участника тестирования, и за 15 минут мы проводим сокращенную версию теста. (Настоящий тест обычно длится около часа, хотя может быть пятиминутным, а может занять весь день.)

Результаты почти всегда одни и те же.

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

• «Хозяин» сайта все 15 минут яростно записывает, какие проблемы нужно решить, и спрашивает, нельзя ли получить запись всего происходившего, чтобы показать своей команде и боссу [9] .

• Остальные приходят к мысли: «Хе-хе. И это всё? Так и я могу».

• По окончании тестирования я спрашиваю: «Как, на ваш взгляд, это стоящий способ провести 15 минут?» – и все согласно кивают головами.

Такое демо-тестирование нужно для того, чтобы показать людям, что а) это очень просто и б) это всегда работает. Многие из участников подозревают, что мне удается создать иллюзию легкости просто потому, что я уже много раз это делал. Но к концу дня, после того как каждый попробовал сам провести тестирование, все, кажется, понимают, что тут нет никакого волшебства и что все так же просто, как выглядит со стороны.

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

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

Но почему же оно работает?

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

•  Оно работает, потому что нет сайтов без недостатков . Мы все это знаем по собственному опыту. Часто ли вам случалось пользоваться сайтом и не нарваться на какую-нибудь проблему с юзабилити? И нередко это значительные проблемы, они вас фрустрируют, а порой даже мешают сделать то, что вы намеревались.

У некоторых, неновых, сайтов проблем меньше, особенно если они прошли уже несколько раундов тестирования юзабилити, но не обманывайте себя: у вашего сайта есть проблемы с юзабилити. Черт, даже у моего сайта есть проблемы с юзабилити, что, скажем прямо, довольно-таки стыдно. Да даже у Amazon.com есть проблемы с юзабилити, а всем известно, какого я высокого мнения об Amazon.com [10] .

•  Оно работает, потому что большинство серьезных проблем легко выявить . Опять-таки подумайте о тех проблемах с юзабилити, которые вам приходилось встречать на чужих сайтах. Разве вы не думали всякий раз: «Как они умудряются не знать об этой проблеме?» Большинство наиболее серьезных проблем лежат на поверхности, и практически каждый на них натыкается. Но нам почему-то кажется, что на наших собственных сайтах такого рода проблемы выявить сложно. Это мне всегда напоминает мультфильм о Дунсбери, где Фред спрашивает куратора стертого с лица земли Камбоджийского музея, был ли он разрушен в ходе секретных бомбардировок.

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

Разумеется, существуют не менее серьезные, но получше спрятанные проблемы с юзабилити, такие, на которые наткнется меньшее количество людей. Но если вы не можете уделить тестированию юзабилити значительное количество усилий и времени (если это ваша основная работа – тогда другой разговор), то я настоятельно рекомендую вам начать с разрешения очевидных проблем. Для большинства сайтов это еще не пройденный этап.

И наконец:

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

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

Что мешает провести тестирование

Но если тестирование юзабилити так просто и так полезно, то почему же оно так редко становится обязательной частью интернет-проекта? Даже сегодня очень мало организаций проводят тестирование юзабилити своих сайтов, а если все-таки проводят, то только один раз, ближе к завершению проекта.

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

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

Наконец, существует вполне естественный (и почти универсальный) страх показывать кому бы то ни было незаконченную работу. Мы всегда знаем, что то, над чем мы работаем, имеет недостатки, так зачем же показывать это другим людям, тратить и их, и свое собственное время для того, чтобы они сказали нам то, что мы и так знаем? (Да и кому нравится демонстрировать на публике изъяны своей работы?)

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

ЧАВО

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

Да, веб-аналитика может предоставить вам точную картину того, что люди делают на вашем сайте («72 % посетителей покинули вашу домашнюю страницу меньше чем через 5 секунд»). Объем выборки действительно очень велик (в общем-то, все ваши пользователи), информация основана на реальном использовании вашего сайта, вы можете составить практически любой статистический запрос – и мгновенно получить ответ. А с пришествием Google Analytics это стало доступно всем и каждому благодаря весьма привлекательной цене (безвозмездно, то есть даром!).

Проблема, однако, заключается в том (и любой специалист по юзабилити вам это скажет), что хотя аналитики могут вам в подробностях рассказать, что люди делают на вашем сайте, они не смогут сказать, почему они всё это делают. Например, если пользователи проводят очень много времени на какой-то конкретной странице, статистика не разъяснит вам, происходит это потому, что они нашли там много полезного и заняты чтением, или потому, что там ничего непонятно и они пытаются разобраться.

Тестирование же юзабилити, напротив, призвано помочь вам понять, почему люди делают то, что они делают.

Если задача заключается в том, чтобы обнаружить и решить проблемы с юзабилити, то, выбирая между великими и ужасными аналитиками, способными точно сказать, что делают мои пользователи (но ничего не знающими о том, что пользователи думают, когда это делают), и возможностью в течение часа пообщаться с одним-единственным человеком, понимая, что он думает и задавая наводящие вопросы, я всегда выберу последнее.

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

Большинство действий, которые вам предстоит выполнить, вы будете выполнять и при тестировании собственного сайта/приложения/чего угодно. Единственный нюанс: при реальном тестировании этих действий будет больше, и на каждое из них вы будете тратить больше времени (в сумме на все про все вам понадобится около часа).

Зайдите на сайт нашего издательства по адресу www.piter.com, найдите там страницу, посвященную этой книге, и скачайте файл Steve_Krug_UsabilityDemo [11] .

1. (Может быть, вы сейчас летите в стареньком самолете, где нет доступа в Интернет по WiFi, и потому не можете скачать этот файл. Не расстраивайтесь. Переходите к следующей главе, но потом не забудьте все же скачать и посмотреть его.)

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

И это всё?

В общем-то, да! Ловкость рук и никакого мошенничества! Как видите, для проведения тестирования не нужно быть волшебником, не нужно обладать никакими специальными навыками. Одни люди заметят и захотят исправить больше, другие – меньше, но в среднем каждый участник тестирования получит немало полезных сведений.

ЧАВО

Извините, но зачем вы посвятили этому целую главу?

Затем, что этот пример важен, и таким образом я хотел заставить вас обратить на него внимание.

Как я уже говорил в главе 1, у людей находится масса уважительных причин для того, чтобы не проводить тестирование юзабилити. Но главная причина, по которой большинство его не проводит, – убежденность в том, что это очень трудоемкая работа (такой вариант я называю Большим Навороченным тестированием).

В ходе моих мастер-классов я выработал, с моей точки зрения, максимально рациональный план, которым может воспользоваться всякий (вне зависимости от того, проводите вы тестирование для себя или для большой организации) и который позволит вам в ходе проекта протестировать то, что вы делаете, несколько раз.

Эта методика легко осуществима и приносит результаты. Она обнаруживает ровно столько проблем, сколько вы можете решить. Кроме того, она работает по принципу: самые существенные проблемы решаются первыми.

Сформулируем мой генеральный план так:

В общем, от вас потребуется раз в месяц проводить раунд тестирования с тремя пользователями.

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

Тут есть два ключевых слова, на которых следует сосредоточить внимание.

• Утро . Сокращение времени тестирования до половины дня (а это значит привлечение не более трех участников) облегчает процесс подбора пользователей и позволяет большему числу заинтересованных лиц прийти и понаблюдать за тестированием.

• Месяц . Раз в месяц – оптимальный интервал. С одной стороны, проводить тестирование чаще мало кто готов, с другой же – одно тестирование выявляет достаточно проблем, чтобы вам было чем заняться в течение следующего месяца.

Если вы объявите, что каждый третий четверг месяца вы намереваетесь проводить тестирование, вы таким образом донесете до ваших сотрудников мысль о том, что вы рассчитываете на их присутствие на тестировании, а до разработчиков – что к этому времени у них что-то должно быть готово.

Сделав тестирование регулярным этапом работы, вы избавитесь от необходимости решать, когда проводить тестирование; вы просто будете тестировать то, что окажется готово ко дню тестирования. (Если приходится думать, когда проводить тестирование, то все обычно кончается тем, что оно не проводится никогда.)

Самостоятельное тестирование против Большого Навороченного тестирования

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

«Самостоятельному тестированию» доступно не все, что доступно Большому Навороченному тестированию, но оно достигает результатов, которые вам нужны, за ту цену, которую вы можете себе позволить. Перед вами сводная таблица различий, существующих между двумя этими типами тестирования (все элементы этой таблицы будут подробно прокомментированы в следующих главах):

ЧАВО

А что, действительно достаточно заниматься этим один разв месяц?

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

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

На первый раз отведите на подготовку по крайней мере 2–3 рабочих дня. Однако при подготовке следующих раундов вы сможете сократить время до двух дней, а то и до одного.

А можно я буду заниматься тестированием чаще, чем разв месяц?

Разумеется. Одно утро в месяц – это минимум. Что бы вы ни делали, результат от более частого тестирования только улучшится.

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

Наш проект строится на принципах гибкогопрограммирования. А вы говорите – один раз в месяц! Я смеюсь!

Ах да, гибкое программирование [13] . Короткий цикл разработки в гибкой среде – если вы будете ждать целый месяц, вы вне игры. Ну что ж, в таком случае скажем так: «Спринт каждое утро, мы не просим о большем».

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

Поскольку вы намереваетесь проводить тестирование чаще, чем раз в месяц, то можно сделать каждый раунд еще более компактным (например, два участника вместо трех) и некоторые раунды проводить удаленно (глава 14), что сэкономит вам массу времени. Но в остальном процедура тестирования ничем не будет отличаться.

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

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

Обязательно заниматься этим именно по утрам?

По утрам или нет – на результат не влияет. Легко представить себе ситуацию, когда участникам тестирования неудобно заниматься этим в рабочее время, и потому вы вынуждены проводить его в 6, в 7, а то и в 8 вечера (обед в таком случае можно посвятить привлечению наблюдателей, а совещание провести на следующий день, за завтраком или опять-таки за обедом).

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

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

А вот что: «Вы абсолютно правы. Тестирование на трех пользователях не может дать статистически достоверных результатов. Выборка настолько мала, что тут и речи не может быть о статистике. Но цель такого тестирования заключается не в том, чтобы что-то доказать: задача в том, чтобы выявить наиболее существенные проблемы и, решив их, улучшить нашу продукцию. Эта методика работает, потому что большинство проблем настолько очевидны, что их существование не требует "доказательств"».

Постарайтесь произнести это уверенно и дружелюбно.

Что почем? Каков бюджет мероприятия?

Вот расчет затрат на год (за исключением вашего времени), необходимых для проведения самостоятельного тестирования:

А вот «бюджетный» вариант на случай, если вам не выделено вообще никакого бюджета:

Очень простая мысль: если вы хотите посмотреть, как люди пытаются использовать создаваемый вами продукт, вам необходимо этот продукт им предоставить, хоть в каком-нибудь виде. Это означает, что вы должны хорошо понимать, что именно вы будете тестировать в следующий раз.

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

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

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

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

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

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

•  «Продукт еще слишком сырой». Дизайнеры очень не любят показывать свои недоделанные работы. Однако пользователи меньше стесняются в выражениях при описании своих впечатлений от продукта, зная, что он впоследствии будет доработан.

•  «Зачем заставлять людей тратить время на разглядывание того, что еще сто раз изменится?» Когда вы занимаетесь разработкой, идеи, которые вы держите в голове, всегда лучше тех, которые уже воплощены в виде кода или наброска. Да, пользователи расскажут вам об уже известных вам проблемах, но, поверьте, без сюрпризов не обойдется. По большому счету, именно ради таких сюрпризов все и затевается: на многое вы могли не обратить внимания, потому что слишком хорошо знаете предмет или потому что гораздо меньше смыслите в чаяниях пользователей, чем вам кажется.

Я дам вам в связи с этим вот какой совет:

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

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

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

Тестирование своего сайта

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

КАК ТЕСТИРОВАТЬ

Сверяясь с процессом, описанным в главах 5–9.

ЧТО ВАМ ЭТО ДАСТ

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

А еще вы узнаете много нового о том, как на самом деле люди работают с вашим сайтом.

Тестирование чужих сайтов

Пока у вас нет своего сайта, вы можете воспользоваться чужими. Почему бы не протестировать их? Они могут принадлежать конкурентам или просто быть похожими по контенту или функционалу на то, что собираетесь сделать вы. Еще один ход – выбрать для тестирования сайт, предназначенный для той же целевой аудитории, которую вы хотите привлечь на свой интернет-ресурс.

Чужие сайты – это сильно недооцененные объекты для тестирования. Я очень люблю повторять следующую несложную мысль: «Кому-то уже пришлось помучиться, создавая полномасштабный работающий прототип сайта, и при этом решались те же проблемы, которые пытаетесь решить вы. Так почему бы не воспользоваться результатами их труда?»

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

КАК ТЕСТИРОВАТЬ

Сверяясь с процессом, описанным в главах 5–9.

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

Однако во время разбора полетов (см. главу 10) вместо выявления самых серьезных проблем (которые вы, очевидно, решать не будете) стоит предложить всем обсудить, что на протестированных сайтах сделано хорошо, что – не очень, и какие уроки из этого можно извлечь.

ЧТО ВАМ ЭТО ДАСТ

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

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

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

Тестирование набросков на салфетке

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

Никогда не пренебрегайте тестированием набросков.

КАК ТЕСТИРОВАТЬ

Конечно, эту методику нельзя считать полноценным тестированием. Это что-то вроде экскурсии по главной странице, описанной в моем в демо-тесте (глава 2). Тестирование длится не более пяти минут. К участию в нем можно привлекать друзей, соседей – в общем, кого угодно. Имеет смысл предложить изучить черновик дизайна потенциальным посетителям вашего сайта, с этой же просьбой можно обратиться и к посетителям соответствующих отраслевых выставок.

Для проведения тестирования достаточно произвести следующие несложные манипуляции.

1. Подойти к понравившемуся вам человеку.

2. Сказать: «Будьте так любезны, окажите небольшую услугу – взгляните вот на это!»

3. Вручить набросок (он может быть выполнен в виде аккуратной схемы, а может представлять собой небрежный рисунок на салфетке).

4. Спросить: «С чем этот рисунок у вас ассоциируется? Что можно сделать на основе этого наброска?»

Обратите внимание: вы не должны интересоваться, понравился ли набросок собеседнику. Единственное, что вам нужно, – понять, с чем ассоциируется у зрителя ваша схема.

5. Слушайте внимательно. Вы, должно быть, услышите следующее: «Что ж, это похоже на главную страницу сайта. Сдается мне, с его помощью вы пытаетесь распространять нечто. А вот эти штучки – изображения лучшей продукции из вашего ассортимента. А вот здесь написано «Магазин». Наверное, можно сделать заказ прямо на сайте. Правда непонятно, что скрывается за названием раздела «Бонусы».

Если хотите, можете задать несколько уточняющих вопросов, например: «Как вам кажется, что может находиться в разделе "Бонусы"?»

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

ЧТО ВАМ ЭТО ДАСТ

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

Вот пример из личного опыта. Много лет я хотел назвать эту книжку «Полевой справочник Стива Круга для пользователей». Ее оформление должно было напоминать справочник для тех, кто любит наблюдать за птицами: Тот же размер и пропорции, тот же внешний вид и стиль изложения.

Мне казалось это прекрасной идеей. Даже не так. Это казалось мне просто потрясающей идеей. Мне самому она дико нравилась. Когда я думал о ней, у меня улучшалось настроение. Черновой вариант обложки висел на стене у меня над столом и вдохновлял меня [14] .

Потом я совершил глупость: последовал своему собственному совету и решил протестировать этот вариант названия и оформления. Все, кого я опросил, были единодушны.

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

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

Я сам не смог разглядеть проблему, потому что слишком близко знал предмет тестирования. Я-то прекрасно понимал, как должна была работать моя концепция.

Тестирование каркасной модели

После создания набросков веб-разработчики, как правило, приступают к построению каркасных моделей.

Эта модель представляет собой, по сути, чертеж будущей страницы. На ней обычно показано, где будут размещаться разные типы контента, как будут соотноситься между собой размеры заголовков и инструментов навигации.

КАК ТЕСТИРОВАТЬ

Каркасные модели тестируют, предлагая пользователям задания, связанные с навигацией: «Как бы вы стали искать__________?», «Что вы ожидаете увидеть при переходе по этой ссылке?»

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

ЧТО ВАМ ЭТО ДАСТ

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

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

КАК ТЕСТИРОВАТЬ

Вначале покажите участникам тестирования главную страницу, потом все остальные. Попросите дать описание каждой из них (подробности – на странице 104, в разделе «Экскурсия по главной странице»).

ЧТО ВАМ ЭТО ДАСТ

Ваша цель – выявить проблемы юзабилити, связанные с визуальной организацией страниц. Постарайтесь понять, очевидно ли для пользователей, как «работает» каждая из страниц?

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

КАК ТЕСТИРОВАТЬ

Сверяясь с процессом, описанным в главах 5–9.

ЧТО ВАМ ЭТО ДАСТ

А теперь самое скучное (по крайней мере, для меня): набор участников.

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

Мне этот этап никогда не нравился. Возможно, потому, что он единственный не имеет никакого отношения к юзабилити. А может быть, потому, что у меня неподходящий для такого рода дел характер. (Нужно быть очень собранным и любить общаться с незнакомыми людьми.) У некоторых же, напротив, очень хорошо получается, а некоторые так даже получают от этого удовольствие.

Но вне зависимости от того, нравится вам все это или нет: если вы намереваетесь наблюдать за людьми, вам потребуются люди. И при этом (как и на всех остальных этапами процесса) хотелось бы избежать лишних трудностей.

Дело сводится в конечном счете к трем вопросам:

• Кого тестировать?

• Сколько человек понадобится?

• Как их найти?

• Чем компенсировать им потраченное время?

С кем проводить тестирование?

Когда встает вопрос о том, кого привлечь к тестированию, практически все интуитивно приходят к одной и той же идее:

Это звучит в высшей степени разумно. Ведь:

• Первое и самое очевидное: совершенно все равно, смогут ли пользоваться вашим сайтом люди, которые не собираются им пользоваться. Так зачем же привлекать их к тестированию?

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

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

• Люди, принадлежащие к вашей целевой аудитории, могут, в отличие от остальных, иметь некие предметные знания [15] .

Однако, как показывает опыт, привлекать к тестированию людей, принадлежащих именно к вашей целевой аудитории, не столь важно (и не так легко), как кажется с первого взгляда.

Взять, к примеру, предметные знания.

Разумеется, встречаются случаи, когда знание и опыт играют роль. Допустим, вы тестируете форму, которую нужно заполнить, чтобы заказать промышленный кран, и участникам тестирования нужно при этом заполнять графы в духе Вылет стрелы (м), Максимальная высота подъема крюка (м), Грузоподъемность (т). В этом случае вам, пожалуй, понадобятся люди, которые разбираются в кранах.

Но даже если вы работаете в области, где предметные знания имеют значение, тут есть свои «но»:

• Ваша аудитория может оказаться значительно менее однородной, чем вам кажется. Например, новички могут и не обладать предполагаемым предметным знанием, а вашим сайтом им все равно надо пользоваться. Если вы продаете в интернете страховки на автомобили, то, вероятно, вы захотите сосредоточиться на людях, у которых автомобили есть и которые что-то уже знают про их страхование. Но ведь нужно, чтобы и те, кто впервые купил машину, могли воспользоваться вашим сайтом.

• Люди, которые обладают предполагаемым знанием, не всегда знают то, что они должны знать (по вашему мнению). Например, много лет назад я тестировал некий продукт, созданный для агентов по торговле недвижимостью. В интерфейсе постоянно использовался термин, значения которого я не знал. Я спросил у разработчиков. Они сказали, что все агенты этот термин знают и постоянно его используют. Позднее я попросил агента (продавшего, кстати, мне мой дом) поучаствовать в небольшом тестировании этого же продукта. И как только мы сели за тестирование, он ткнул пальцем в этот термин и спросил: «Что это значит?»

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

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

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

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

У меня уже много лет есть девиз:

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

Если у участника тестирования возникает проблема, просто спросите себя: «Столкнутся ли с той же проблемой наши пользователи? Или она возникла только потому, что участник тестирования не знает профессионального жаргона или недостаточно знаком с предметом, а следовательно, не грозит нашим реальным пользователям?»

Соображайте на троих

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

Почти все согласны с тем, что увеличение количества участников, выполняющих одно и то же задание, уменьшает отдачу от тестирования: чем дольше вы за ними наблюдаете, тем меньше новых проблем вы способны заметить. Большинство исследований, проводившихся в этой области, сводились к поиску того количества участников тестирования, которое позволяет выявить максимум проблем. Выводы при этом обычно формулируются примерно так: «Тестирование с пятью участниками выявит 85 % проблем».

Однако все эти аргументы – не для вас (если вы собираетесь заниматься самостоятельным тестированием). Не гонитесь за выявлением максимального количества проблем. Ваша задача – понять, что вам нужно, чтобы обнаружить ровно столько проблем, сколько вы сможете устранить.

За долгие годы работы в этой области я пришел к выводу, что в каждом раунде тестирования должны принимать участие три пользователя. Эта цифра оказалась оптимальной по целому ряду причин.

• Большинство серьезных проблем выявляется первыми тремя участниками тестирования.

• Найти трех человек не так уж трудно (а вот с поиском большего количества участников могут возникнуть проблемы).

• Пытаться выжать максимум из каждого раунда – ложная цель. Куда важнее провести их как можно больше. Чем меньше участников на каждом раунде, тем проще этого добиться.

• Когда в процесс вовлечены всего три человека, можно успеть провести и тестирование, и разбор полетов в течение одного дня.

• Небольшое количество пользователей легче уговорить принять участие в тестировании.

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

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

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

Деньги решают всё

Если у вас случайно завалялись деньжата, а времени и желания нанимать участников тестирования нет, озадачьте этой проблемой какого-нибудь агента по поиску персонала.

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

Агент разузнает у вас, какие люди вам нужны. Потом подыщет возможных кандидатов (по своей базе или при помощи рекламных объявлений), отберет лучших, расскажет им, когда и куда надо прийти, и даже разошлет им напоминания накануне назначенной даты. Все это стоит не так дорого, как кажется. Буквально две-три тысячи рублей за подбор одного человека. Может, чуть дороже, если у вас очень специфические требования.

Рекрутинг – это та часть процесса тестирования, которую лучше поручить специалисту. Впрочем, моя книга все-таки посвящена самостоятельному тестированию, поэтому я готов предположить, что вы и сами способны справиться. Вот как это делается.

Где их искать?

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

Например, если вам нужны пожилые, стоит посетить социальные учреждения, где они проводят свой досуг, а также библиотеки и церкви. Если нужны потребители, пользующиеся вашей продукцией, поищите соответствующие интернет-форумы, группы по интересам и отраслевые выставки (кстати, и само тестирование можно провести прямо на выставке).

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

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

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

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

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

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

Если вам никак не удается подыскать нужных людей, попробуйте провести удаленное тестирование (подробнее об этом читайте в главе 14). В таком варианте значительно упрощается задача рекрутинга, поскольку вам не надо искать людей, непременно живущих неподалеку. Достаточно, чтобы у участников тестирования был широкополосный доступ в Интернет.

Повесьте объявление

После того как вы поймете, где «прячутся» ваши пользователи, надо их оттуда как-то выманить. Повесьте приглашение. Например, такое:

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

Где вешать объявление? Там, где его смогут увидеть:

• на доске объявлений;

• на электронной доске объявлений;

• разошлите его по электронной почте знакомым специалистам в интересующей вас предметной области и попросите переслать дальше по цепочке;

• на главной странице вашего сайта или во всплывающем окне, появляющемся при входе на сайт.

Выберите самых перспективных

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

• узнайте, действительно ли этот человек свободен в день тестирования;

• поймите, соответствует ли его квалификация вашим ожиданиям (хотите верьте, хотите нет, но многие готовы приврать ради возможности заработать пару сотен рублей, и ваша задача – выяснить это раньше, чем человек придет на тестирование);

• расскажите, что человека ждет (тестирование будет длиться около часа, работать надо будет с веб-сайтом, вы будете записывать все происходящее, но лиц в кадре видно не будет, и так далее);

• сообщите о размере компенсации за потраченное время и о способе ее получения;

• решите для себя, сможет ли ваш собеседник стать адекватным участником тестирования, не стесняется ли он высказывать свои мысли вслух, все ли у него хорошо с артикуляцией;

• назначьте собеседника одним из трех участников тестирования.

Доведите дело до конца

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

• карта проезда (на автомобиле и на общественном транспорте);

• схема парковки;

• схема здания;

• телефон, по которому можно будет позвонить в случае чего в день тестирования или накануне;

• договор о неразглашении (если он вам нужен), чтобы участник тестирования мог ознакомиться с ним заранее.

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

Дружеское рукопожатие

Много лет назад у меня был чудесный начальник, который как-то раз вместе с премией вручил мне табличку со следующей надписью: «С тех пор, как в Финикии изобрели деньги, одной благодарности недостаточно».

На самом деле, иногда достаточно. (К слову, госслужащим так и вовсе запрещено предлагать что-либо за участие в тестировании.) Всегда найдутся люди, которые захотят просто помочь вам. Например, пользователи вашей продукции будут просто счастливы, если вы спросите их мнение: у них будет надежда, что они смогут повлиять на процесс разработки. В таких случаях деньги действительно не нужны. Гораздо лучше будет, если вы разошлете участникам тестирования благодарственные письма (только бумажные, ни в коем случае не электронные!).

Некоторые будут в восторге от каких-нибудь прикольных сувениров: подарите им кружку, или футболку, или образец своей продукции.

Впрочем, в большинстве случаев от вас все-таки будут ждать денежной компенсации за потраченное время (не забудьте, что людям придется тратить время еще и на дорогу до вашего офиса и обратно).

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

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

Одно из простейших решений – подарочные сертификаты каких-нибудь популярных и достаточно универсальных магазинов.

Скамейка запасных

Если вы лично договорились с участниками, вероятнее всего, они не подведут и появятся вовремя. Но бывают случаи, когда вы вынуждены нервно поглядывать на часы и гадать, куда все подевались. У кого-то могла сломаться машина, еще кто-нибудь заблудился… От таких случайностей никто не застрахован.

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

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

•  Почти все равно, кто будет тестировать. Просто тот, кто окажется рядом . В этом случае можно поймать кого-нибудь, кто трудится в одном здании с вами или даже в одной организации (но в другом отделе).

•  «Настоящий пользователь», с которым можно провести удаленное тестирование . Если у вас достаточно жесткие требования к участникам, вряд ли вы с ходу найдете подходящую кандидатуру. Спасти ситуацию может удаленное тестирование (глава 14). Это своего рода «звонок другу» (так это называется во всем известной телеигре).

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

ЧАВО

Не упустим ли мы из виду каких-нибудь серьезных проблем, если в тестировании принимают участие всего три человека?

Упустим, наверняка упустим. В этом конкретном раунде. Именно поэтому надо проводить как можно больше раундов.

Можно ли приглашать одних и тех же людей на разные раунды тестирования?

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

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

Общая идея ясна, но хотелось бы узнать побольше подробностей

Все книжки, в которых детально описывается процесс подбора участников тестирования, перечислены в списке рекомендуемой литературы (с. 188–189). Если вы в самом деле хотите узнать все нюансы, прочитайте соответствующие работы Джареда Спула (Jared Spool) и Якоба Нильсена (Jacob Nielsen) (с. 190–191).

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

• Вначале надо выбрать задания.

• Затем надо расширить описания этих заданий, превратив их в сценарии, содержащие все необходимые подробности.

Первым делом – список заданий

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

Попробуйте прямо сейчас.

1. Возьмите лист бумаги.

2. Составьте список из 5-10 наиболее существенных задач, для решения которых, собственно, планируется запуск вашего сайта.

Вот, например, список, составленный для моего сайта.

Получить информацию о моих мастер-классах.

Записаться на мои мастер-классы.

Прочитать отрывок из моей книги.

Купить мою книгу.

Узнать, какие консультации я предоставляю.

Все еще жду.

Ну, что? Было не слишком трудно, не так ли? (Вы ведь написали этот список? Я в вас верю! Нет-нет-нет. Я имею в виду, вы не просто подумали, а в самом деле написали, так? Ага, все-таки не написали. Ну, напишите же. Это займет у вас не больше минуты. Я жду.)

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

Вам, однако, придется проверить, что именно эти задачи в действительности придется решать пользователям сайта.

Имея перед глазами наконец-то составленный список, выберите, какие его пункты будут проверяться в ходе ближайшего раунда тестирования.

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

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

Выбирать задания для тестирования следует с учетом следующих соображений.

•  Наиболее критичные задачи . Это те действия, которые пользователям необходимо выполнять на сайте. Если они не смогут их выполнить, это будет означать, что ваш сайт вообще никуда не годится. Например, если вы создаете книжный интернет-магазин, пользователям необходимы система поиска книг и возможность их покупки.

•  То, что заставляет вас просыпаться по ночам в холодном поту . Это задачи, с решением которых у пользователей могут возникнуть проблемы, элементы сайта, которые могут их смутить или, оказаться не такими понятными, как хотелось бы, и т. п.

•  Задачи, с которыми, судя по уже проведенным исследованиям, пользователям трудно справляться . Узнайте в службе поддержки, с какими проблемами чаще всего сталкиваются клиенты. Вспомните, на какие недостатки юзабилити указали ваши веб-аналитики.

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

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

Задание: «Поступить в аспирантуру московского Института международных отношений».

Сценарий: «Вы – выпускник факультета международных отношений СПбГУ. У вас есть ряд научных публикаций, и вы хотите продолжить свою научную карьеру в МГИМО.

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

Единственная сложность с составлением сценария заключается в том, что в нем не должно быть никаких подсказок.

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

Плохой пример: «Настройте свой плейлист в LAST. FM».

Пример получше: «Выберите музыкальные жанры, которые вам нравятся».

Выдавая задания участникам тестирования, сообщите им о двух ограничениях.

•  Поиск – вне закона. (Если вы, конечно, не занимаетесь тестированием поисковой системы.) Обязательно проинформируйте об этом участников, если не хотите, чтобы тестирование сайта превратилось в проверку того, насколько хорошие результаты выдает поисковик. Не грех еще раз напомнить об этом правиле во время тестирования, если участники о нем забудут.

•  С сайта не уходить! В большинстве случаев требуется, чтобы пользователи провели на вашем сайте все время, отведенное на тестирование. Это вполне естественное ограничение, и нарушают его довольно редко. Может быть, не стоит специально оговаривать это перед началом тестирования, но, если в процессе вы заметите, что люди ушли с вашего сайта, попросите их вернуться.

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

Для этого надо всего лишь усадить кого-нибудь перед монитором, дать почитать сценарий и попросить приступить к выполнению заданий. Все непонятные моменты и нестыковки станут сразу же очевидны. Это как раз тот случай, когда к тестированию можно привлечь кого угодно (отличный повод пообщаться с друзьями и членами семьи!).

Обычно такую проверку устраивают за день-два до тестирования. К этому времени сценарии уже должны быть написаны, а дизайнеры и разработчики должны [почти] завершить работу над тестируемыми модулями.

По окончании работы над сценариями их надо напечатать в двух видах.

• Для участников: каждый сценарий на отдельной странице. Перед началом выполнения задания выдайте соответствующий листочек каждому из участников.

Сценарий должен быть напечатан большим шрифтом на отдельной странице. Лучше всего напечатать на листе формата А4 два сценария, а потом разрезать его пополам.

Не нумеруйте сценарии, поскольку в процессе тестирования вы можете захотеть сменить порядок выполнения заданий.

Я вообще-то не люблю контрольные списки. Мне они кажутся шорами, символом жестко организованных процессов, тогда как я люблю импровизировать. Но вместе с тем я предпочитаю иметь дело с методами, которые работают, и потому я не стал бы умалять ценность контрольных списков.

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

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

С сайта нашего издательства по адресу www.piter.com можно скачать электронную версию этих списков. Приведите их в соответствие с реалиями вашего проекта и используйте во время тестирования.

За три недели до тестирования

• Понять, что я буду тестировать (сайт, каркасную модель, прототип или что-нибудь другое).

• Написать список заданий для участников тестирования.

• Определиться с требованиями к участникам тестирования.

• Пригласить участников тестирования.

• Арендовать помещение с доступом в Интернет, столом, двумя стульями и устройством громкой связи.

• Рядом с комнатой, где будет проходить тестирование, найти место, где участники могли бы дожидаться своей очереди.

• Арендовать помещение для наблюдателей с доступом в Интернет, столом, достаточным количеством стульев, устройством громкой связи, проектором и экраном (или не забыть взять с собой проектор/большой монитор).

• Арендовать помещение для разбора полетов, в котором хватит места всем участникам тестирования.

За две недели

• Получить комментарии от команды разработчиков и других заинтересованных лиц по поводу списка заданий.

• Решить вопросы, связанные с вознаграждением для участников (например, заказать подарочные сертификаты или написать заявку на выдачу наличных денег).

• Приступить к отбору участников, назначить время, в которое они должны явиться.

• Разослать команде разработчиков и другим заинтересованным лицам электронные письма с напоминанием о предстоящем тестировании.

За неделю

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

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

• Если предстоит первый раунд тестирования, установить и проверить ПО для захвата видеопотока и дублирующего монитора.

За день-два

• Позвонить участникам и узнать, не изменились ли их планы и нет ли у них каких-нибудь вопросов.

• Разослать напоминалки наблюдателям.

• Дописать сценарии.

• Проверить сценарии.

• Получить все технические сведения (логины/пароли) и тестовые данные (например, фиктивные номера кредитных карт или счетов).

• Сделать копии раздаточных материалов для участников:

– соглашение о ведении записи во время тестирования (с. 203);

– наборы сценариев, напечатанных на отдельных листах;

– дополнительные экземпляры договоров о неразглашении.

• Сделать копии раздаточных материалов для наблюдателей:

– инструкции для наблюдателей (с. 128);

– комплект сценариев;

– копия текста для ведущего.

• Договориться с кем-нибудь, кто сможет встретить участников и дать им указания о дальнейших действиях.

• Договориться с кем-нибудь, кто займется подготовкой комнаты наблюдателей, выдать ему экземпляр Инструкции для дежурного (с. 133).

• Убедиться, что вознаграждения для участников тестирования готовы.

• Убедиться в наличии микрофона, динамиков, удлинителей, компакт-дисков для записи видеофайлов.

• Заказать плюшки и напитки для наблюдателей.

• Убедиться, что никто не забронировал арендованные вами помещения на то же самое время (такое иногда случается!).

• Найти кого-нибудь, кто встретит участников тестирования, разместит их и в нужный момент проводит в комнату тестирования.

В день тестирования (перед началом первого теста)

• Заказать угощения, которые вы предложите участникам тестирования, когда будете заниматься с ними «разбором полетов».

• Отнести раздаточные материалы в комнату наблюдателей.

• Убедиться, что объект тестирования установлен (или доступен через Интернет) и работает.

• Проверить устройство видеозахвата: записать небольшой отрывок (со звуком!) и проиграть его.

• Проверить дублирующий монитор и систему громкой связи в комнате наблюдателей.

• Закрыть все работающие на тестовом компьютере программы, которые могут помешать процессу (среди них, например, почтовые клиенты, сервисы мгновенных сообщений, напоминалки календаря, антивирусное ПО).

• Создать закладки для всех страниц, которые могут понадобиться при тестировании.

• Убедиться, что у вас есть все нужные номера телефонов:

Комната наблюдателей ___________________________.

Комната для проведения тестирования _____________________________.

Тот, кто встречает участников тестирования _________________________________.

Разработчик __________________________.

( позвонить при возникновении проблем с тестируемым объектом )

Системный администратор ___________________________.

( позвонить при возникновении проблем с сетью или сервером )

• Убедиться, что все динамики в комнате наблюдателей и в комнате для тестирования работают.

Перед каждым тестом

• Очистить историю браузера.

• Открыть пустую страницу в браузере.

Пока участник заполняет соглашениео ведении записи

• Включить запись!

В конце каждого теста

• Остановить запись!

• Сохранить запись!

• Отключить (при необходимости) дублирующий монитор.

• Сделать пятиминутный перерыв и записать краткие комментарии к проведенному тесту.

• Если этот тест последний в данном раунде, скинуть файл с записью на компакт-диск или флеш-карту.

Внимание! (Барабанная дробь…) А сейчас – гвоздь нашей программы! Тестирование как оно есть.

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

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

Что делает ведущий

Вам предстоит играть сразу две роли.

•  Экскурсовод . Вы отвечаете за объяснение участникам стоящих перед ними задач, за их комфорт и плавное перемещение.

В отличие от настоящего экскурсовода, вы не имеете права отвечать на вопросы, касающиеся «достопримечательностей» (в данном случае сайтов). Участники тестирования должны обо всем догадываться без подсказок.

•  Психоаналитик . Вы должны выудить из ваших «пациентов» их сокровенные думы относительно тестируемого объекта.

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

Именно эти мысли вслух, называемые «устным протоколом», обеспечивают эффективность тестирования юзабилити.

Наблюдателям надо на время стать телепатами. Особенно важно научиться считывать возникающие в голове у пользователя вопросы и восклицания: они означают, что человек смущен, раздражен или просто запутался.

Как только вы начнете чувствовать, что мысли участника ускользают от вас, вы обязаны восстановить канал связи, задав вопрос: «О чем Вы думаете?»

Глядя, как пользователи работают с вашим сайтом, и слушая, что они при этом думают, вы как бы смотрите на свою разработку чужими глазами – глазами человека, который (в отличие от вас) мало знает о том, как устроен ваш сайт. Так и только так приходят озарения, столь необходимые для улучшения юзабилити.

Комната для тестирования

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

1. Компьютер 2. Внешний монитор и клавиатура 3. Мышь 4. Микрофон 5. Громкая связь

Вот что вам понадобится в комнате для тестирования.

1. Компьютер с доступом в Интернет, ПО для видеозахвата, ПО для дублирующего монитора .

Что до компьютера , то это может быть практически любой ноутбук, ПК или Macintosh. Лучше прийти со своим ноутбуком, в этом случае можно заранее установить и проверить все нужные программы. Кроме того, не придется опасаться, что кто-нибудь возьмет и снесет эти программы без вашего ведома.

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

ПО для видеозахвата . С его помощью вы сможете протоколировать все происходящее на мониторе и фиксировать все действия пользователя. Главное достоинство этого ПО состоит в том, что вам не нужно тратить время на подробное ручное протоколирование. Вам достаточно будет одного движения мышью, чтобы найти в видеофайле нужный момент тестирования [17] . Плюс ко всему, имея на руках такие записи, очень удобно проводить «разборы полетов»: никогда не возникнет разночтений по поводу того, что сказал или сделал пользователь.

Теоретически все, кто не пришел на тестирование, смогут потом посмотреть эту видеозапись, но в том мире, где живу я, такое почти никогда не случается [18] . Впрочем, я считаю, что так даже лучше. Предпочитаю, чтобы люди лично участвовали в тестировании.

Какое именно ПО использовать? Мне нравится Camtasia (версия для ПК стоит от 9 тысяч рублей, версия для Mac – вдвое меньше). Есть, конечно, программы и подешевле (а CamStudio, например, и вовсе бесплатная), но ни у одной из них нет такого количества полезных функций (в Camtasia встроены инструменты видеомонтажа, с ее помощью очень удобно резать и склеивать куски видео, добавлять титры и т. д.). Я ей доверяю, и она меня (тьфу-тьфу-тьфу, постучим по дереву!) ни разу не подводила.

ПО для дублирующего монитора позволяет тем, кто находится в комнате наблюдателей, видеть и слышать происходящее в комнате для тестирования. Ассортимент таких программ весьма широк. На некоторые из них надо оформлять платную подписку, но большинством можно пользоваться бесплатно в течение определенного периода. Если вы работаете в большой организации, узнайте, не приобреталось ли такое ПО ранее (корпоративным стандартом, похоже, считается система WebEx).

Лично я пользуюсь программкой GoToMeeting. Она очень надежная, и у нее замечательный интерфейс. Установить GoToMeeting можно как на ПК, так и на Mac. Ее безлимитное использование обойдется вам в 1,5 тысячи рублей в месяц, при этом одновременно вы сможете подключить 15 компьютеров. У этой программы есть встроенная функция голосовой связи по VoIP.

Эта программа вам особенно пригодится для проведения удаленного тестирования (глава 14).

2. Монитор и клавиатура.

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

При отсутствии особых требований со стороны потенциальных пользователей разрешение у монитора должно быть 1024x768. (Если участник тестирования говорит, что привык видеть гораздо больше на своем экране, увеличьте разрешение до 1280x1024.)

3. Обыкновенная мышь и обыкновенный коврик для нее.

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

4. USB-микрофон.

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

Вместо обычного телефона с функцией громкой связи я порекомендовал бы (при наличии такой возможности) воспользоваться технологией VoIP или голосовым чатом типа Skype.

Вам понадобится микрофон. Мой выбор – недорогой (продается за 1000 руб.) микрофончик Logitech USB Desktop Microphone. Внешний микрофон (в отличие от встроенного в ноутбук) можно расположить так, чтобы наблюдатели могли хорошо слышать одновременно и ведущего, и пользователя.

5. Телефон с функцией громкой связи.

Даже при использовании технологии VoIP надо на всякий случай в обеих комнатах поставить телефоны. (Убедитесь, что у вас записаны их номера.)

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

• Проверьте ПО для видеозахвата . Запишите несколько секунд, потом воспроизведите файл.

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

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

• Проверьте дублирующий монитор . Для этого попросите кого-нибудь зайти на минутку в комнату наблюдателей и запустите ПО дублирующего монитора. Убедитесь, что там все хорошо видно и слышно.

• Установите увеличенный размер курсора . Зачем? Чтобы, как тот волк из «Красной шапочки», лучше видеть. И ведущему, и наблюдателям в этом случае будет проще следить за действиями пользователя.

• Закройте все программы, которые могут помешать . Почтовый клиент, Google Talk, ICQ, напоминания, антивирусное ПО – все это может в самый неподходящий момент прервать спокойный ход тестирования.

• Сделайте закладки для всех страниц, которые вам могут понадобиться . Зачем тратить время на ввод их адресов в браузере?

• Проверьте, все ли хорошо с тестируемым объектом . Никогда не повредит лишний раз это проверить. Всякое могло случиться с тех пор, как вы в предыдущий раз запускали свой сайт. Мог «упасть» сервер, могло отключиться интернет-соединение. Какой-нибудь альтернативно одаренный разработчик мог в последнюю минуту что-нибудь поменять, не поставив вас в известность. Разбираться с этими проблемами лучше сейчас, а не в присутствии участника тестирования.

• Сбросьте настройки браузера . Если пользователю предстоит вводить какие-нибудь данные, убедитесь, что их еще нет в памяти браузера. Очистите историю, чтобы список недавно открытых сайтов не стал подсказкой для пользователя.

• Свяжитесь с человеком, встречающим участников . Убедитесь, что он готов к прибытию гостей.

Каждый сеанс тестирования начинается с приветствия, в ходе которого ведущий излагает порядок предстоящей работы [19] .

Есть любители импровизаций, которые придумывают текст на ходу, полагая, что это выглядит более естественно. Однако я рекомендую воспользоваться шпаргалкой и, не стесняясь, говорить по бумажке. Я провожу тестирования уже двадцать лет, и, несмотря на это, всякий раз меня тянет отклониться от написанного текста. При этом в половине случаев я начинаю нести какую-нибудь околесицу (например, использую слова «мнение» или «обратная связь»). Не надо импровизировать!

Произносите только то, что написано у вас на бумажке [20] .

В процессе чтения постарайтесь расслабиться и наладить контакт с участником тестирования.

• Установите визуальный контакт. Для этого надо, чтобы текст речи был напечатан крупным шрифтом. Тогда вам не придется пристально вглядываться в свой листочек. Старайтесь время от времени поднимать взгляд на собеседника.

• Не бубните. Участник тестирования должен хорошо слышать то, что вы ему говорите.

• Не пытайтесь прочитать весь текст, как скороговорку, но и слишком медленно его произносить тоже не стоит.

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

Вопросы 2 минуты

Участникам тестирования нередко задают несколько вопросов перед началом и по окончании сеанса.

Я обычно задаю простые вопросы, которые решают следующие три задачи.

•  Разговорить собеседника . Ответить на простые вопросы может каждый, а небольшой рассказ о себе послужит хорошим началом хорошей беседы. Человеку предстоит озвучивать свои мысли, и надо с чего-то начать.

Не стесняйтесь задавать уточняющие вопросы. Обычно я выясняю какие-нибудь подробности о работе собеседника (например, что входит в его обязанности или чем занимается контора). А если вы ничего из сказанного не поняли («Наша компания оказывает брокерские и депозитарные услуги, а также является посредником по совершению фьючерсных и опционных сделок»), не делайте вид, будто поняли. Попросите объяснить.

•  Выяснить, похож ли собеседник на представителя целевой аудитории . После проведения опроса вы отлично поймете, а) чем участник тестирования зарабатывает на жизнь и б) насколько продвинутым пользователем компьютера и Интернета он является. Все это, плюс понимание уровня его предметных знаний (которое вы получите, увидев реакцию на главную страницу сайта), даст вам представление о схожести собеседника с образом потенциального пользователя вашего сайта.

Экскурсия по главной странице

Приступая к тестированию сайта, я всегда для начала предлагаю пользователю поглядеть на главную страницу и вкратце рассказать, что он понял.

Моя цель при этом – узнать, ясна ли общая идея сайта, и убедиться, что пользователи способны уловить ее. Далее в этой книге описано [21] , почему так часто сайты не выдерживают даже этого испытания. Не ожидали?

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

Обратите внимание: не надо интересоваться мнением пользователя о главной странице. Ведь в сценарии не написано «посмотрите и скажите, что вы об этом думаете».

Сценарий не надо пересказывать – его надо зачитывать дословно, только в этом случае пользователь получит правильное задание: описать общую идею сайта. Это задание очень важно, а главное – реалистично. Именно с этого начинается работа пользователя с новым для него сайтом. Просто в данном случае ему нужно вербализовать свои мысли.

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

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

Задания

В заданиях – вся соль тестирования.

Для начала надо выдать участнику экземпляр сценария и прочесть его вслух (дословно!).

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

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

Когда двигаться дальше? Для этого надо ответить на следующие вопросы.

•  Пользователь выполнил задание? В этом случае выдавайте следующее. (Если он только полагает, что справился с заданием, попросите решить ту же задачу каким-нибудь другим способом, таким образом намекнув на ошибку.)

•  Пользователь опечален? Выполняя ваши задания, пользователь может испытывать целую гамму чувств. Цитируя психолога Элизабет Кюблер-Росс:

Необязательно доводить пользователя до отчаяния. От расстроенного человека пользы меньше, чем от довольного. Тестирование юзабилити – это не краш-тест: выявить проблемы можно и без разрушений.

Я не говорю, что при первых же признаках неудачи надо бросаться на выручку, однако надо знать меру. Если вы видите, что участник тестирования начинает выходить из себя, подумайте, надо ли оно вам? Стоит ли причинять человеку такие страдания? Постоянно контролируйте психологическое состояние пользователя.

•  Сколько осталось времени и заданий? Следите за временем, особенно если еще остались невыполненные задания.

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

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

Расследование

Наблюдая за тем, как пользователь выполняет задания, вы неизбежно захотите что-нибудь уточнить, узнать какие-нибудь подробности.

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

Отведите несколько минут на этап расследования. Используйте эту возможность, чтобы убедиться, что вы правильно поняли все действия и слова пользователя. Узнайте, почему он в определенных обстоятельствах действовал так, а не иначе.

Небольшие уточнения можно вносить и по ходу дела («Вы имеете в виду____________?»). Но более сложные вопросы типа «Почему вы поступили именно так?» надо записывать в блокнот («Не заметил боковую панель навигации», «Выбрал вторую ссылку. Почему?») и задавать на этапе расследования.

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

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

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

Еще можно задать уточняющие вопросы относительно внесенных пользователем предложений (я имею в виду пожелания типа: «Было бы круто повесить тут карту, а не этот дурацкий список регионов»). Изредка такие пожелания будут действительно полезными, но чаще всего их можно пропустить мимо ушей [22] . Все-таки пользователи – это не дизайнеры. Они далеко не всегда знают, что им нужно и чего им на самом деле хочется. Тем не менее надо дать им высказаться. Все равно их речь закончится словами: «Вообще-то, сам я не стал бы этим пользоваться. Я бы, наверное, продолжил делать это так, как делаю сейчас».

Иногда, впрочем, вам будут попадаться отличные идеи. Как отделить зерна от плевел? О, это элементарно. Если будет высказано гениальное предложение, над головой у вас и у всех наблюдателей загорятся лампочки. Все как один зашумят: «Потрясающе! Как же мы сами об этом не подумали? Это же очевидно!»

Эндшпиль

Поблагодарите своего собеседника, узнайте, не осталось ли у него вопросов, расплатитесь и проводите до двери. Вот, собственно, и все.

На прощанье я всегда говорю одно и то же: «Большое вам спасибо. Все прошло замечательно. Вы нам очень помогли». Я произношу эти слова, даже если все отнюдь не было замечательно. Особенно важно сказать это, когда сеанс прошел просто отвратительно.

Подготовка к следующему тесту

Обратите внимание: сеанс тестирования длится не полный час, а 50 минут. Академический час тоже никогда не совпадает с астрономическим, и сделано это ровно по той же причине: чтобы выжать максимум, нужно делать перерывы. За время антракта надо успеть забыть о предыдущем сеансе, собраться с мыслями и, возможно, сделать пару физических упражнений.

Итак, у вас есть 50 минут на сеанс тестирования. Увеличение этой цифры приведет только к тому, что все запутаются во времени начала сеансов. Между тестами должно быть минут 10–15. Затягивать антракт тоже не стоит, а то наблюдатели «выйдут на минутку, проверить тут одну штуку» и больше не вернутся.

Во время перемены нужно.

•  Сделать пару заметок относительно предыдущего сеанса . Иначе все сеансы потом смешаются у вас в голове в одну кучу.

•  Перезагрузить компьютер . Надо все вернуть в исходное состояние. Загрузите тестовые данные, очистите историю браузера.

•  Подумать, не надо ли что-нибудь подправить . Чтобы не наступать на одни и те же грабли, попробуйте убрать их с дороги. Видя, что пользователь по объективным и очевидным причинам не справился с каким-нибудь заданием, измените его или вовсе не предлагайте во время следующих сеансов. Можно даже попробовать исправить что-нибудь на тестируемом сайте, если это можно сделать за пару минут (например, подставив другую таблицу стилей или поменяв заголовок).

Фрейд гордился бы вами

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

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

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

•  Вы повторяете одни и те же фразы снова и снова . И многие из этих фраз активно применяются психоаналитиками.

•  Вы отвечаете за психологическое состояние собеседника .

Сделайте так, чтобы они не умолкали

Вы наверняка заметите, что некоторые люди способны высказывать свои мысли вслух, только если им напоминать об этом. Соответственно, перед вами встает вопрос: насколько часто можно надоедать им своими напоминаниями?

Я всегда полагал, что это несложная функция, зависящая от длительности паузы: если человек молчит 20 секунд (или 30, или 40 – не знаю), то пора ему намекнуть на то, что молчание затянулось. Но потом до меня дошло, что есть еще один фактор:

В большинстве случаев, даже если человек молчит, вы прекрасно знаете, о чем он думает. Скажем, если он что-то читает, не надо его дергать своими напоминаниями. Если пользователь выполняет какие-то осмысленные действия, которые ни вас, ни его не смущают, тоже не надо прерывать молчание – все и так понятно. Но если вы чувствуете, что потеряли нить молчаливых рассуждений собеседника, значит, пришло время спросить, о чем он думает.

И не надо бояться быть назойливым. Это вам только кажется, что ваши вопросы звучат слишком часто. Проведите эксперимент и спросите, надоели ли вы пользователю своими напоминаниями о необходимости мыслить вслух. Уверяю вас, большинство даже не замечает ваших возгласов. Другое дело, что вы сами можете утомиться, спрашивая постоянно одно и то же. Что ж, варьируйте содержание вопросов. Вместо «О чем вы думаете?» спросите: «Что вы сейчас делаете?», «На что вы сейчас смотрите?»

Сохраняйте нейтралитет

Самое трудное как в работе ведущего, так и в работе психоаналитика – оставаться беспристрастным. Это необходимо для исключения влияния на собеседника.

Самый тяжелый случай – это ведущий, явно преследующий свои собственные интересы (сознательно или подсознательно). Например, человек, принимающий участие в разработке сайта, заинтересован в том, чтобы пользователь остался доволен. А ведущий, которого изначально бесила идея создания сайта, заинтересован в полном провале теста.

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

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

• Не говорите, что надо делать. Не давайте даже минимальных подсказок. Видя, как пользователь мучается с сайтом, как у него что-то не получается, вы захотите броситься ему на помощь. Сдерживайте себя.

• Не отвечайте на вопросы. Лучший вариант ухода от ответа – встречный вопрос: «А вы как думаете?».

• Не высказывайте свое мнение («Это классная фишка!»). Не поддакивайте («О, да, это действительно классная фишка!»).

• У вас должно быть лицо игрока, которому ни в коем случае нельзя раскрывать свои карты. Ничто не должно указывать на то, довольны вы или недовольны происходящим. Рекомендую вам постоянно сохранять спокойно-удовлетворенное выражение лица, как бы говорящее о том, что все под контролем.

Что сказал бы психоаналитик

Во время выполнения участником тестирования заданий вам придется для поддержания собственной беспристрастности снова и снова повторять одни и те же фразы. Я подготовил для вас небольшой разговорник.

Есть еще три вида выражений, которые вы можете использовать.

•  Звуки, подтверждающие восприятие информации . Говорить «угу», «ясно», «хорошо», «мм» можно сколь угодно часто. Благодаря этим словам участник тестирования понимает, что вы следите за его мыслью и хотите услышать продолжение монолога. Обратите внимание: эти звуки означают лишь то, что вы внимательно слушаете. Ни в коем случае нельзя придавать им эмоциональную окраску («Хорошо», а не «Хорошо!!!»).

•  Парафразы . Иногда бывает полезно подводить промежуточные итоги, перефразируя только что сказанное участником тестирования («Итак, вы хотите сказать, что вот эти надписи плохо читаются?»). Такие повторы позволяют убедиться в том, что вы правильно услышали и поняли пользователя.

•  Разъяснения для наблюдателей . Если пользователь ссылается на какой-то элемент интерфейса, следует описать этот элемент, чтобы наблюдатели могли следить за ходом тестирования. Например, если пользователь вдруг восклицает: «О, какая классная штучка!» – надо переспросить: «Вы про этот список в правой части экрана?» Поскольку вы сидите рядом с пользователем, вы, очевидно, лучше понимаете, о чем он говорит, чем наблюдатели, сидящие в другой комнате.

Моральная ответственность

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

Вообще-то тестирование – это совсем не страшно. Вы ни к кому не подключаете никакие датчики и электроды, и если вы не мизантроп и не социопат, то вряд ли у кого-то в результате общения с вами испортится настроение. Я все-таки предполагаю, что вы относитесь к участникам тестирования с уважением, пониманием, что вы в состоянии сопереживать. (Даже если у пользователя просто болит голова. Да что там. В особенности, если у пользователя болит голова.) Иными словами, я надеюсь, что вы – адекватный человек.

У пользователя есть право в любой момент прервать тестирование и уйти. Это не должно иметь для него негативных последствий. (Да-да, вы должны заплатить даже в этом случае.) Работайте над тем, чтобы психологическая обстановка в комнате для тестирования была максимально комфортной. Пользователь не должен испытывать стресс или страх. Постоянно следите за настроением собеседника, будьте учтивы и дружелюбны. С пониманием отнеситесь к желанию пользователя остановить тестирование. Бывают даже случаи, когда имеет смысл спросить, не надо ли прервать сеанс.

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

Записи, сделанные во время сеансов тестирования, – это тоже ваша зона ответственности. Они должны храниться только у вас и удаляться, как только в них отпадает необходимость. Если вы хотите выложить записи в своей корпоративной сети, снабдите их грозным запретом на дальнейшее распространение и вычистите из них всю персональную информацию типа номеров телефонов и кредитных карт. (Замечательная программа Camtasia поможет вам в этом.) Наиболее скандальные высказывания лучше тоже вырезать [23] . Я никогда не стану распространять записи сеансов тестирования, участниками которых были мои коллеги, поскольку тем самым я могу выставить их в невыгодном свете.

Душные клиенты

Большинство участников тестирования оказываются милыми людьми, с которым можно весьма продуктивно сотрудничать. Но бывают и исключения…

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

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

Как и с котами, надо быть вежливым, но строгим, и заставлять заниматься делом. Например, так: «Хорошо [выдерживаем паузу и делаем вид, что все в самом деле замечательно]. Отлично [предполагаем, что пользователь уже успел снова на что-нибудь переключиться]. У нас впереди много дел, так что позвольте мне попросить вас.»

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

Некоторых персонажей приходится осаживать снова и снова. Это раздражает. Сосчитайте до десяти и успокойтесь. Вы должны вести себя достойно, что бы ни происходило. Некоторые собеседники, которые кажутся совершенно безнадежными, высказывают порой замечательные идеи.

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

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

Не парься, будь счастлив

Теперь, когда вы прочитали эту главу, вам может показаться, что быть ведущим очень муторно. К счастью, это не так. Стоит лишь попробовать, и окажется, что все очень просто. Никаких особенных умений тут не нужно, и единственное, что может как-то травмировать, – это первые «выходы на сцену». Чтобы избавиться от всех страхов, проделайте следующее.

•  Потренируйтесь читать сценарий вслух . Для начала несколько раз прочитайте его в полном одиночестве, потом – одному-двум членам семьи или коллегам. После этого страх чтения перед публикой у вас пройдет.

•  Проведите игрушечное тестирование . Если вы действительно очень волнуетесь перед первым сеансом, поиграйте в тестирование с друзьями. Вам понадобятся два человека: один будет участником, второй – наблюдателем. Пройдите с ними все этапы тестирования, включая настройку дублирующего монитора в соседней комнате.

ЧАВО

Кто может стать ведущим?

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

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

Кому не стоит быть ведущим?

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

И совершенно точно нельзя вести тестирование тому, кто ни за что не откажется от своей личной выгоды ради объективности.

Где мне сесть? Рядом с пользователем? За его спиной?

Участник тестирования должен сидеть непосредственно перед монитором и клавиатурой, а вы должны расположиться таким образом, чтобы хорошо видеть экран и следить за действиями пользователя. Мне кажется, лучше всего сидеть сбоку и чуть позади. Главное – сохранять дистанцию и не вторгаться в чужое личное пространство.

Нужно ли ведущему записывать что-нибудь в блокнот?

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

Наблюдатели же пусть испишут все свои блокноты. А вы помните, что всегда есть возможность посмотреть запись. Единственное, что действительно надо записать, пока не забылось, это Список Основных Проблем (СОП).

Почему вы задаете так мало вопросов в начале и в конце?

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

Во-первых, выборка слишком мала, чтобы можно было делать какие-либо выводы. Во-вторых, как известно, люди почти не способны искренне отвечать на такие вопросы. Знаете самую популярную шутку специалистов по юзабилити? «Все мы видали пользователей, дошедших до белого каления, пытаясь выполнить элементарное задание с помощью тестируемого сайта. Но когда их просишь оценить сайт в целом по семибалльной шкале (1 – человеконенавистнический, 7 – бесподобно дружественный интерфейс), то все они ставят оценку 6. Мы не знаем, почему так, но это так. Всегда [24] ».

Camtasia, Camtasia. А почему не Morae?

Несколько лет назад программу Camtasia стали настолько часто применять при тестировании юзабилити, что парни из TechSmith решили создать еще одну приблуду под названием Morae, специально предназначенную для проведения сеансов тестирования. По мне так, Morae – это Camtasia, накачанная стероидами. В нее запихали десятки дополнительных функций, включая возможность ведения заметок, синхронизированных с видеозаписью. Одновременно она может служить и программой для дублирующего монитора. В общем, она как бы решает весь комплекс проблем.

Нет, это чудесный инструмент, многим он нравится, но использовать его для того типа тестирования, о котором я тут рассказываю, все равно что из пушки палить по воробьям. Я советую начать с чего-нибудь попроще, а на Morae переходить лишь тогда, когда в этом возникнет настоящая потребность. Собственно, ничто не мешает вам скачать пробную версию и бесплатно поиграться с ней в течение 30 дней.

Почему вы против видеосъемки самого участника тестирования?

Мне никогда не нравилась идея целиться видеокамерой в лицо пользователя.

Изначально «кадр в кадре» (а точнее, «пытка в кадре») задумывалась для того, чтобы посмотреть на раздраженное лицо пользователя. Оно служило дополнительным доказательством того, что с юзабилити есть проблемы. А мне кажется, что это только отвлекает.

Лучше подумать об улучшении качества записи звука. По интонации всегда можно понять, какое у человека настроение.

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

Почему так важно личное участие? Да потому, что Видеть – значит верить.

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

Во-первых, весь их скепсис улетучивается. Они начинают относиться к тестированию с большим энтузиазмом. Это и понятно: стоит один раз понаблюдать за тестированием, чтобы понять, как это полезно.

Кроме того, происходят еще и менее заметные, но крайне важные изменения: глядя на то, как пользователи взаимодействуют с сайтом, понимаешь, что они совсем не похожи на тебя! Большинство людей полагает, что все работают в Интернете одинаково. И нужно лично присутствовать на сеансе тестирования, чтобы пришло озарение: они не такие, как я! Хуже того, они вообще все разные! Тестирование расширяет сознание. (Как путешествие, во время которого вдруг понимаешь, что далеко не все живут и думают одинаково.) Это переломный момент. У тех, кто присутствовал на тестировании, отношение к пользователям изменится раз и навсегда, что позволит им стать действительно хорошими программистами, дизайнерами, менеджерами, кем угодно.

Не совсем понятно, почему этот эффект гораздо больше проявляется при личном присутствии и гораздо меньше – при просмотре записи. Это, наверное, все равно что смотреть футбол по телевизору: одно дело, когда матч показывают в прямом эфире, другое дело – когда в записи. А еще, придя на тестирование, люди получают дополнительный заряд энергии от общения с другими наблюдателями, они могут обмениваться мнениями и сравнивать свои впечатления.

В общем, аргументов можно приводить много. Вывод один: на тестирование стоит позвать людей.

Чем больше, тем веселее

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

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

Сделайте все, что в ваших силах, чтобы они пришли. Вот несколько дельных советов.

•  Планируйте с умом . Назначайте ежемесячное тестирование на наименее напряженный день недели и наименее напряженную неделю месяца.

•  Реклама – двигатель прогресса . За две недели до тестирования разошлите письма с просьбой не занимать этот день. За несколько дней разошлите письма еще раз (чтобы про вас не забыли). Наконец, накануне назначенного срока отправьте всем напоминалки.

•  Расскажите о том, что это даст . Все хотят, чтобы были устранены те дефекты, которые раздражают именно их. Заверьте, что при разборе полетов будут выслушаны и приняты во внимание все пожелания.

•  Исхитритесь, чтобы затащить на тестирование высшее руководство . Я всегда рекомендую прилагать максимум усилий, чтобы первые лица компании оказались в комнате наблюдателей. Придумайте что-нибудь. Ну, скажите, например, что это поднимет боевой дух команды разработчиков. Я лично видел топ-менеджеров, которые отменяли назначенные совещания и приходили на тестирование. Помимо Дилбертов [25] в мире есть много других руководителей, которые вообще-то достаточно умны, чтобы оценить значимость личного присутствия на тестировании.

• Закажите вкусные плюшки . И люди к вам потянутся.

За чем наблюдать наблюдателям

Задачи людей, пришедших в комнату наблюдателей, очень просты:

• смотреть, делать выводы и писать заметки;

• в конце каждого сеанса фиксировать на специальном бланке три наиболее важные, с их точки зрения, проблемы;

• придумывать вопросы, которые ведущий должен задать пользователю;

• лакомиться плюшками;

• участвовать в «разборе полетов».

Вот и все. Ниже приводится готовый набор инструкций, который я рекомендую распечатать и раздать всем наблюдателям [26] .

Комната наблюдателей

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

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

1. Компьютер 2. Проектор (или большой монитор) 3. Динамики 4. Плюшки 5. Телефон

1.  Компьютер с доступом в Интернет и ПО для дублирующего монитора . В качестве компьютера можно использовать ноутбук или настольный компьютер, ПК или Mac. Для передачи сигнала с монитора на монитор понадобится доступ в Интернет . Некоторым программам для дублирующего монитора нужна еще и отдельная программа просмотра видеопотока, но большинству, в том числе GoToMeeting, хватит и стандартного веб-браузера.

2. Изображение на экране или мониторе должно быть достаточно крупным и ярким, чтобы всем было видно, что делает пользователь. Если тестируется сайт, с которым наблюдатели уже знакомы, это не так существенно, но если объектом тестирования является новый дизайн, сайт конкурентов или страницы с динамическим контентом, то важно видеть детали.

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

3.  Пара мощных динамиков . В комнатеLogitech X-140 (стоят 1000 рублей). У них для тестирования должен стоять хороший микрофон, а в комнате наблюдателей – хорошие динамики. Рекомендую неплохое соотношение сигнал/шум, они достаточно мощные и имеют регулятор громкости.

4.  Плюшки . Еда – это здорово. Если ее поставить на стол, комната наблюдателей сразу становится уютной, в нее хочется вернуться. Не экономьте на вкусняшках! Это ведь приманка. Подумайте, на что могут клюнуть программисты в 9 утра? Рогалики и плюшки – это универсальный вариант, но надо учитывать и местные традиции. Если вы знаете, что многие обожают сухие завтраки или творожные сырки, купите их побольше. Не забудьте про напитки.

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

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

ЧАВО

Не слишком ли это жестоко, ведь нервные клетки не восстанавливаются?

Об этом меня часто спрашивают. Не слишком ли тяжело наблюдателю смотреть, как люди безуспешно пытаются воспользоваться тем, что он сам же и создал? Да еще в присутствии коллег и начальников! Не может ли это стать причиной озлобленности, разочарования или страха потерять работу?

Опыт подсказывает мне, что все это ерунда.

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

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

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

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

Можно ли разрешить наблюдать за тестированием удаленно тем, кто не смог присутствовать лично?

Это зависит от причин, по которым они не пришли. Если они искренне хотели бы поучаствовать, но не смогли по объективным причинам (например, потому что находятся в другом городе), то, конечно же, можно. Но я не рекомендовал бы баловать тех, кому просто лень дойти до вашего офиса. Во-первых, они не смогут участвовать в общей дискуссии. Во-вторых (и это еще важнее), сидя у себя за столом, за своим компьютером, очень сложно заставить себя целых три часа не проверять почту, не отвечать на сообщения, пришедшие по аське, и так далее. Соответственно, человек не сможет быть полноценным наблюдателем.

Могут ли наблюдатели находиться в одной комнате с участником тестирования?

Нежелательно. Опытные ведущие, может быть, смогут с этим как-то справиться, но новичкам будет трудновато.

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

Если же по каким-то причинам необходимо, чтобы наблюдатели находились в комнате для тестирования, представьте их пользователю и объясните, почему они тут находятся. Наблюдателям же надо очень строго сказать, чтобы они соблюдали ряд правил.

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

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

• Сидеть с лицом картежника, которому нельзя раскрыть свои карты. Никаких улыбок, гримас неудовольствия, никаких усмешек, если только пользователь не решит в самом деле пошутить. И, главное, никаких вздохов.

• Не давать пользователю никаких указаний и подсказок. Кивать головой, когда пользователь наконец находит нужный элемент интерфейса, тоже не надо.

Задачи, решаемые при «разборе полетов», предельно ясны. На выходе вы должны получить два списка:

• наиболее серьезных проблем, замеченных во время тестирования;

• проблем, которые вы собираетесь решить в течение ближайшего месяца.

Проводить «разбор полетов» следует сразу после тестирования, пока еще свежи впечатления.

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

Я прекрасно понимаю, что в вашей конторе такой фокус может не пройти. Что ж, если все так устроено, не лезьте на рожон. Но имейте в виду, что я предлагаю вам лучший способ убедить людей прийти на тестирование и одновременно лучший способ проведения «разбора полетов». Согласитесь, лучше, когда речь идет только о том, что все видели своими глазами, и никто не пытается фантазировать и затевать пустые религиозные споры.

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

Начните с худшего

Для начала примите как аксиомы следующие соображения.

1. Сайтов без недочетов не бывает.

2. Во всех организациях объем ресурсов, выделяемых на устранение проблем с юзабилити, ограничен.

3. Проблем, которые необходимо устранить, всегда больше, чем ресурсов.

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

Следовательно:

5. Начинать надо с решения самых серьезных проблем.

Можно сформулировать это в виде максимы:

Я могу гарантировать, что если вы проигнорируете это правило, то худшее, что удалось выявить при тестировании, не будет исправлено ни через месяц, ни через полгода.

Как же понять, какие проблемы самые серьезные?

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

Серьезность проблемы можно определить по двум факторам:

• процент столкнувшихся с ней пользователей;

• степень причиняемого ею неудобства.

На некоторые проблемы натыкаются лишь немногие, но они становятся причиной настоящих цорес [28] (например, если пользователь не может совершить транзакцию).

Степень критичности выявленных недостатков придется определять лично вам. Понятно, что проблемы, доставляющие массу неприятностей большому количеству пользователей, – вне конкуренции. Сложнее всего, как всегда, оценивать пограничные и неоднозначные случаи (с той же проблемой сталкиваются медики. От чего искать вакцину: от насморка – массового явления, не причиняющего больших страданий, или от эстезионейробластомы?).

Как проводить «разбор полетов»

Кто проводил тестирование, тому и карты в руки: он будет вести разбор полетов. Надеюсь, я доступно излагаю? Да-да, работать снова придется именно вам. Действуйте в соответствии с планом:

1. Начать надо с описания порядка действий.

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

2. Попросите, чтобы каждый просмотрел свой список и выбрал три важнейшие проблемы.

3. Подойдите к каждому из присутствующих и попросите зачитать вслух итоговый список из трех пунктов. (Если какие-то из выбранных проблемы уже названы, можно просто сказать: «У меня тоже есть про____________________________».)

4. Прикрепите окончательные списки к доске (оставьте между листочками промежутки для внесения возможных уточнений).

5. После того как каждый выскажет свое мнение, посмотрите на все списки и выберите десять самых-самых главных проблем.

Можно, конечно, устроить голосование, но будьте готовы сделать выбор самостоятельно и сказать: «Я считаю, что надо выбрать вот эти». Обведите финалистов маркером. После этого выслушайте возражения и, если понадобится, внесите коррективы.

6. Теперь составьте еще один список. На этот раз он должен быть отсортирован по степени серьезности проблем. Начните с самых серьезных. Делайте промежутки между пунктами: в них вы потом впишете указания по исправлению соответствующих недочетов.

И тут снова решение должны принимать вы сами, прислушиваясь к мнению собравшихся.

7. Изучите получившийся список и обсудите, пункт за пунктом (ничего не пропуская!), каким образом, затратив минимум усилий, в течение месяца избавиться от этих багов (подробности – в главе 11).

8. Работая со списком, вы в какой-то момент поймете, что все имеющиеся ресурсы перечислены и будут полностью исчерпаны. Соответственно, дальнейшее планирование не имеет смысла. Сразу же подведите черту и объявите, что «разбор полетов» окончен.

Как преуспеть

Чтобы «разбор полетов» получился максимально результативным, прислушайтесь к моим советам.

• В верхней части доски, к которой вы намерены прикреплять листочки со списками, напишите крупно:

«Говорим только о том, что видели.

Сосредоточим внимание на главном.

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

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

• Держите наготове ноутбук с записью сеансов тестирования, чтобы в случае чего проверить какие-нибудь нюансы.

• Времени у вас мало, поэтому сделайте так, чтобы никто не отвлекался. Каждый волен вкратце изложить свое мнение, главное, чтобы «разбор полетов» не превратился в пустопорожний спор. Вам придется побыть модератором: надо пресекать разговоры, не имеющие прямого отношения к делу: «Вы почему так считаете? Вы наблюдали это в процессе тестирования?», «Разве кто-нибудь из участников тестирования сталкивался с этой проблемой?»

• Уважайте мнение каждого, никем не пренебрегайте.

• При работе со «списком финалистов» нельзя ничего пропускать. Вы так долго его составляли, чтобы выявить то, что действительно необходимо исправить. А это значит, что вы должны хотя бы что-нибудь сделать по всем пунктам, на которые у вас хватит ресурсов. Только не надо перфекционизма. Изобретение идеального решения «на века» – это не наш метод. Вы должны оставаться в жестких рамках, определяемых следующей формулой: затратив минимум усилий, исправить максимум проблем.

Часто можно слышать следующее высказывание: «Да, пользователям это доставляет массу неудобств, но уже в следующем месяце [или следующем году], когда мы провернем нашу «операцию Оверлорд», эта проблема решится сама собой. Так что нет смысла сейчас тратить на нее время».

Не верьте.

Все мы прекрасно знаем, что на самом деле с большой долей вероятности «операция Оверлорд» отложится, отменится или изменится до неузнаваемости. По крайней мере, полагаться на то, что «вот-вот» благодаря ей все исправится, слишком рискованно. Сегодня, сейчас проблема существует, и это бесит наших пользователей.

Короче, не покупайтесь на эти обещания. Лучше спросите: «Как при помощи минимальных изменений улучшить ситуацию?»

Маленький неформальный отчет

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

• что именно тестировалось;

• какие задания выполняли участники;

• какие проблемы были выявлены и будут исправлены в ближайший месяц.

Расскажите, как получить доступ к видеозаписи теста и когда состоится следующая сессия тестирования.

ЧАВО

Можно ли проводить «разбор полетов» как-нибудьпо-другому? А то знаю я такие совещания: поставят огромнуюдоску, залепят ее всю малюсенькими бумажками. Ничегонепонятно, да и выглядит ужасно!

Ну конечно, шнурки можно завязывать тысячами разных способов. Смотрите: к вам пришла толпа народа, у каждого – свое мнение, а вам надо как-то все это свести к одному знаменателю. Вам надо договориться о том, как действовать дальше. Что ж, это нормальная, классическая бизнес-проблема.

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

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

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

Самое главное, что я понял за годы работы над улучшением юзабилити, можно выразить одной фразой:

Решая, каким образом вы будете совершенствовать свою продукцию, спросите себя:

В чем состоят самые простые, минимальные исправления, с помощью которых можно избавить пользователя от обнаруженных проблем?

Многим не нравится эта идея. Придя на «разбор полетов», они выдумывают самые разные доводы против исправления недостатков минимальными средствами.

•  «Раз уж мы взялись что-то исправлять, надо делать это как положено». Те, кто так говорит, кажется, считают, что избавление от проблем с юзабилити означает поиск окончательного и идеального решения: «Чтобы забыть об этом раз и навсегда!» Я смотрю на мир более приземленно: «Нам надо сделать так, чтобы пользователю прямо сейчас стало чуть более приятно пользоваться нашим сайтом». Я считаю, что это как раз тот случай, когда «лучшее – враг хорошего».

Разумеется, внедрив «быстрое решение», можно подумать над идеальным решением. Но совесть ваша уже спокойна: на данный момент вы сделали то, что смогли. Как сказал генерал Паттон: «Хороший план, реализованный сегодня, лучше идеального плана, реализованного завтра» [29] .

•  «Это одна из важнейших проблем. Просто так, с кондачка, ее не решить». Почему-то считается, что у серьезных задач не может быть простых решений. Наверное, возникает когнитивный диссонанс: «Если это так легко исправить, то почему мы не сделали этого раньше?»

Может быть, вам и не удастся быстро устранить причину, лежащую в основе серьезной проблемы, но хотя бы чем-нибудь помочь пользователю надо как можно быстрее [30] .

•  «Все равно скоро все поменяем, поэтому сейчас нет смысла заниматься этой проблемой». Это одна из самых популярных отговорок. Ссылаясь на грядущий редизайн, люди пытаются оправдать свое нежелание прямо сейчас заниматься устранением проблем. Может быть, разработчики и смогут смириться на какое-то время с недостатками своего сайта, но будут ли пользователи с этим мириться? А что, если редизайн отложится или вовсе отменится?

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

•  «Кажется, это будет клудж [31] какой-то». Я терпеть не могу это слово – оно такое уродливое и неприятное! Конечно, не очень здорово плодить временные решения, ставить заплатки на живую нитку. Но, согласитесь, залепленная скотчем дыра на штанах все же лучше, чем просто дыра.

•  «Сейчас нам не до этого. У нас нет времени». На внедрение идеального решения вам действительно может не хватить времени, но, чтобы подкрутить там и сям гайки, много времени не нужно. Для того мы и составляли список из десяти насущных проблем, сортировали их по степени критичности и обсуждали, ничего не пропуская, чтобы теперь работать над действительно САМЫМ ВАЖНЫМ. Так что варианта «ничего не делать» у нас нет, а нужно либо спешить, либо придумать, как быстро облегчить положение наших пользователей.

Вот вам два совета, которые помогут найти простейшее решение проблем.

• Отлаживайте, а не переделывайте.

• Избавляйтесь от лишнего.

Отлаживайте, а не переделывайте

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

Спокойно. На самом деле достаточно лишь отладить определенные вещи.

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

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

Я все прекрасно понимаю, идея редизайна всегда выглядит так заманчиво: начнем новую жизнь, все на этот раз сделаем как надо…

Отладка – это не столь романтичное занятие, оно не приносит достаточного удовлетворения. Это все равно что чинить старую машину вместо приобретения новой. (Да, вам не светит вдохнуть «запах нового сайта».)

Но у отладки, как видите, есть ряд преимуществ.

Но в чем же суть этой «отладки»?

Отладка подразумевает внесение небольших изменений, это тонкая настройка, которая порой проводится в несколько этапов, методом проб и ошибок.

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

Вот как проводится отладка (на следующей странице этот процесс изображен в виде блок-схемы).

1. Начинать следует с самого простого изменения, способного устранить проблему.

2. Если оно не помогло, примените более жесткий вариант того же изменения. Например, если вы увеличили что-нибудь, но проблема осталась, попробуйте увеличить еще больше. Настраивайте выбранный параметр, пока не добьетесь нужного результата или пока не станет очевидно, что эти изменения проблему не решат.

3. Не отчаивайтесь: прежде чем задумываться о редизайне, попробуйте настроить какой-нибудь другой параметр.

4. Постоянно следите за тем, чтобы не испортить случайно то, что нормально работает. Не пытайтесь «заодно» исправить что-нибудь еще. Как в одной песенке поется, «того не вылечишь, кто не больной».

Избавляйтесь от лишнего

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

Между тем зачастую лучшим решением оказывается как раз обратное: избавление от излишеств.

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

Сдержите свой первый порыв «срочно что-нибудь добавить». Лучше подумайте, что можно убрать.

Как сказал Антуан де Сент-Экзюпери: «Создатель понимает, что достиг совершенства, не тогда, когда больше нечего добавить, а когда больше нечего убрать».

Но ведь иногда все-таки нужен редизайн?

Редизайн? О, да. Мы свой, мы новый мир построим. Может быть.

Было время, когда периодическая глобальная смена дизайна считалась необходимой. Это было так же модно, как ежегодно выпускать новые модели автомобилей. Вообще-то никто не ожидал, что они будут лучше прошлогодних, просто эти – новые, а те – старые. Однако сейчас в мире веб-дизайна наметилась другая тенденция. От глобального и решительного редизайна переходят к поэтапным, постепенным изменениям, затрагивающим отдельные модули, а не весь сайт. Наиболее жестко по этому поводу высказался Джаред Спул, который заявил, что не встречал в своей жизни ни одного удачного глобального редизайна.

Как понять, помогла ли отладка? Надо ли для этого во времяследующего тестирования предложить участникам те жезадания?

Я привык считать, что проверять внесенные изменения при следующем тестировании действительно необходимо. Перефразируя Рональда Рейгана, я говорил: «Отлаживай, но проверяй».

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

Но на самом деле такие «перепроверки» устраивать приходится не так уж часто, поскольку во многих случаях эффективность внесенных изменений вполне можно проверить самостоятельно. Просто посмотрите на обновленную страницу и спросите себя, осталась проблема или ушла. Это нетрудно. (О, тут можно ввернуть мое любимое: «Подумаешь, бином Ньютона!»)

Обычно все сразу становится ясно. Если же вас одолевают сомнения, воспользуйтесь одним из следующих вариантов.

•  Проведите «экспресс-тестирование в коридоре». Вам нужно проверить очень конкретные вещи, например: «Раньше пользователи не замечали боковую навигационную панель. Интересно, заметят ли они ее теперь, когда она стала более выпуклой?» Попросите любого, кто подвернется под руку, выполнить небольшое задание, которое поможет вам получить ответ на свой вопрос. Не забудьте, что пользователь должен комментировать вслух свои мысли и действия.

Регулярно проводя тестирования юзабилити, постепенно осознаешь, что все время сталкиваешься с одними и теми же проблемами.

Казалось бы, скучно. Но нет. Почему-то не скучно. Некоторым проблемам даже начинаешь радоваться, как старым друзьям. Так биологи, каждый год приезжая на одно и то же место, радуются знакомым китам, узнавая их по рубцам на плавниках. Так узники, давно сидящие в тюрьме, настолько хорошо знают все анекдоты, что им достаточно просто называть их номера [32] .

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

Когда встретите их (а это обязательно произойдет, не сомневайтесь), передавайте от меня большой привет.

Если пошел не в ту сторону

ПРОБЛЕМА

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

Наблюдение за тестированием – это наблюдение за небольшим путешествием, которое совершает пользователь. Он выбирает пункт назначения, определяет направление и отправляется в путь. А ты идешь рядом и следишь за каждым шагом. Но даже зная, что пользователь заблудился, не имеешь права ему помогать.

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

Очень точно это описал Эрик Йонссон в своей книге «Внутренняя навигация» (Erik Jonsson, Inner Navigation).

Ранним утром 1948 года, направляясь в Кёльн, Йонссон сошел с поезда и пошел в сторону Рейна. Он был уверен, что движется на запад, несмотря на то, что прямо перед ним занималась заря нового дня. Так он и шел, перепутав стороны света, пока не вышел из города. Впоследствии он много лет собирал истории о том, как люди сбивались с пути, и пытался понять причины их неудач.

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

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

• Формируется общее впечатление (прежде всего, визуальное), зависящее от того, выглядит ли сайт:

профессиональным;

элегантным;

серьезным;

надежным.

Этому посвящена замечательная научная работа («Внимание, веб-разработчики! У вас есть полсекунды на то, чтобы произвести хорошее впечатление!» [33] ), в которой доказывается, что первая оценка дается очень быстро.

• Анализируется страница в целом, определяется, на какие разделы она разбита, делаются предположения о содержимом этих разделов.

• Идентифицируется суть сайта: что он собой представляет, каковы его возможности, кто его владелец, и т. д.

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

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

КАК ПРИДУМАТЬ РЕШЕНИЕ

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

Но помните, что надо проявлять бдительность даже в отношении хорошей главной страницы.

Так, ориентиры, которые дает главная страница, могут постепенно размываться из-за того, что заказчики постоянно настаивают на навешивании все новых и новых функций на имеющийся сайт. В результате большинство главных страниц со временем начинают страдать синдромом кухонной мойки: слишком много хлама. (Когда я смотрю на такие сайты, – перенасыщенные, не дающие информации о своем предназначении, – я чувствую себя, как мальчик из фильма «Шестое чувство». Разница только в том, что он постоянно восклицал: «Я вижу мертвецов!» – а мне приходится восклицать: «Я вижу заказчиков!»)

Надо регулярно проверять, не «испортилась» ли главная страница. Именно поэтому я предлагаю проводить «Экскурсию по главной странице» в каждом сеансе тестирования. Лучше перебдеть, чем недобдеть. (И, кстати, будет здорово, если все, кто причастен к созданию сайта, – особенно заказчики, – будут регулярно слышать высказывания посторонних людей: «Что-то тут очень много всего, ни черта непонятно!»)

Если не докричаться

ПРОБЛЕМА

Дизайнеры, особенно те, кто привык работать с полиграфией, обожают делать так, чтобы визуальные различия между элементами были минимальными. Милое дело: заголовок первого уровня написать 15-м кеглем, а заголовок второго уровня – 14-м, сохранив ту же гарнитуру и начертание. И читатели в самом деле замечают эту разницу, особенно на бумаге (что еще важнее, эту разницу замечают члены жюри на дизайнерских конкурсах). В мире полиграфии низкий контраст шрифта и фона, а также едва заметные линии являются признаками утонченного дизайна.

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

КАК ПРИДУМАТЬ РЕШЕНИЕ

Если нужно, чтобы какой-нибудь элемент сайта обязательно заметили, его надо выделить немного сильнее, чем вам подсказывает ваш изысканный вкус. И гораздо сильнее, чем хочется вашему дизайнеру.

И вы, и дизайнер тем не менее должны понимать, что никто не просит сделать элемент уродливым.

Посмотрите на приведенную ниже картинку и угадайте, какие два элемента, по мнению создателей Amazon.com, пользователь обязан заметить?

Конечно же, это две большие кнопки. Догадаться нетрудно. Я много раз показывал эту картинку во время мастер-классов, и ни для кого не составляло труда разглядеть кнопки, даже с большого расстояния.

А вот другой пример. Сайт Ассоциации специалистов по юзабилити, сделанный несколько лет назад по случаю Всемирного дня юзабилити. Сайтом пользоваться очень удобно (сюрприз!). Шапка его выглядела так:

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

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

ЧАВО

ЗАЧЕМ СТОЛЬКО ЗАНИМАТЬСЯ ГЛАВНОЙ СТРАНИЦЕЙ? РАЗВЕ В ЭПОХУ GOOGLE ГЛАВНЫЕ СТРАНИЦЫ ЕЩЕ КОМУ-ТО НУЖНЫ?

Спору нет, Google заменил нам мозг. Чаще всего первое, что мы открываем в браузере, это Google или Wikipedia.

Приходится признать, что даже для поиска по Википедии я использую Google, набирая, например, Синатра wiki. Разумеется, первая строчка в результатах поиска – ссылка на статью про Фрэнка Синатру в Википедии. В девяти случаях из десяти грамотно составленный поисковый запрос сразу выдает мне то, что нужно.

И в самом деле, многие пользователи (большинство!) не заходят на сайт через главную страницу. Они что-нибудь ищут в поисковике и сразу попадают на ту страничку, где есть интересующая их информация.

Из этого, казалось бы, можно сделать вывод, что главная страница больше никому не нужна. Но это не так.

Придя с Google на одну из страничек сайта и ничего полезного там не обнаружив, большинство будет сразу искать ссылку на главную страницу, чтобы «всплыть на поверхность», осмотреться и понять, о чем этот сайт, кто его создал и можно ли ему доверять. Очень часто с главной страницы люди уходят на страничку «О проекте». Я надеюсь, у вас в разделе «О проекте» кратко и четко написано, кто вы такие и чем занимаетесь (потому что именно за этим сюда приходят пользователи), а не какая-нибудь многословная болтовня под названием «миссия компании».

Так что главная страница все-таки по-прежнему важна, и на ней вкратце должно быть сказано, кто вы и что вы. Только тогда пользователи, которых Google телепортировал на ваш сайт, смогут решить, стоит ли на нем задерживаться.

Пока я писал эту книгу, я просмотрел десятки отчетов о тестах, проведенных мною за долгие годы. Для своих клиентов я всегда делаю очень симпатичные версии «Больших и навороченных отчетов»: вставляю в них снимки экранов, иллюстрирующие обнаруженные проблемы, и иногда даже снимки «исправленных версий» интерфейсов, демонстрирующие возможные решения. Приятно посмотреть! (Мне так и говорили.) Все так понятно! Клиенты всегда соглашались с моими выводами. Их воодушевлял и сам процесс тестирования, и идея улучшения их продукции.

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

В отчетах были названы десятки проблем, но я всегда составлял список из 10–15 самых серьезных, которые просто необходимо устранить.

Для исправления некоторых из них требовалось внести совсем небольшие изменения, а сайты стали бы намного лучше и (весьма вероятно!) прибыльнее. Люди, с которыми я делился своими соображениями (большинство из них занимали очень высокие посты в своих организациях), соглашались, что очень важно устранить обнаруженные проблемы. Интересно, что для тех сотрудников, которые просили меня провести тестирование, выявленные недостатки не были сюрпризом, тогда как для начальства они становились настоящим открытием, но все, казалось, были настроены самым решительным образом на борьбу за скорейшее улучшение юзабилити. А в итоге, выходит, ничего не делалось!

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

Почему ничего не происходит

Так в чем же дело? Если все прекрасно понимают серьезность проблем, знают, что надо сделать для их устранения (зачастую не так уж много!), и располагают всеми необходимыми ресурсами, то почему же ничего не происходит?

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

• Смена руководства, смена вектора развития или и то и другое одновременно.

• Непреодолимое желание разработчиков отмахнуться от проблем, если на их устранение приходится потратить чуть больше сил, чем предполагалось. Конечно, проще всего в этом случае сказать: «Отложим это до следующего редизайна». (Перевожу: «Готовьте денежки!»)

• Недостаточная поддержка со стороны тех, кто ее должен оказать.

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

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

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

Наконец, самое главное:

• Жизнь вносит свои коррективы. «По целому ряду причин» оказывается недостаточно времени, средств или желания.

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

Кабинеты моих друзей

Меня часто спрашивают, каким образом лучше всего «продавать юзабилити» руководству компаний.

Есть прямой и очевидный путь: понять цели, которые ставит перед компанией руководство, и доказывать, что улучшение юзабилити поможет приблизиться к этим целям. Придется изъясняться в терминах, близких менеджменту, как можно чаще делать презентации, доказывающие эффективность вашей деятельности, и т. д. Это, конечно, хороший путь.

Еще можно вычислить рентабельность инвестиций в юзабилити и представить эту цифру в виде сильного и объективного аргумента. Этой теме целиком посвящена целая книга – «Юзабилити и уменьшение издержек» (Cost-Justifying Usability, 2005) под редакцией Рэндольфа Байеса (Randolph Bias) и Деборы Мэйхью (Deborah Mayhew). Исследование рентабельности – это очень убедительная штука [34] , но она требует больших затрат времени и денег.

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

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

Естественно, в результате на свет божий появляются хромые и косые проекты, и даже когда через некоторое время их пытаются сделать удобными для использования, это не очень получается. Руководству компаний часто хватает ума только на то, чтобы понять: без кода и контента сайт существовать не может. А на то, что им невозможно пользоваться, часто закрывают глаза: «Ничего, кому надо, как-нибудь да справится».

Лично я не очень люблю доказывать, что инвестирование в юзабилити рентабельно. Я уверен, что компании, которым нужна такая аргументация, не готовы ни к каким свершениям. Чтобы заниматься юзабилити, необходимо нечто большее: энтузиазм, искреннее желание сделать все наилучшим образом. Когда компания процветает, то ей, возможно, и достаточно просто вложить деньги. Но когда ресурсов не хватает, без людей, фанатично преданных своему делу, не обойтись. Нужны энтузиасты, готовые тратить время и средства на создание продукции высшего класса, использование которой будет доставлять пользователю удовольствие.

Что делать?

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

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

Суть удаленного тестирования проста: вместо того чтобы звать пользователей к себе, вы сами приходите к ним – по проводам. Вместо того чтобы заглядывать в экран через плечо пользователя, вы пользуетесь программой дублирования экрана. Ну а вместо разговора с глазу на глаз, говорите по телефону.

Первый сеанс удаленного тестирования я провел 15 лет назад. Не было тогда еще никаких программ для дублирования экрана, поэтому мне приходилось самому догадываться, что делает пользователь (он описывал мне это по телефону), и повторять его действия на своем компьютере. Разумеется, очень много времени уходило на вопросы типа: «Какое окошко сейчас у вас активно?»

Теперь, с приходом быстрого Интернета и классных программ для дублирования экрана, удаленное тестирование максимально приблизилось к очному.

Зачем это нужно?

Все объясняется одним-единственным словом: удобство. Удаленное тестирование обладает рядом существенных достоинств.

•  Легко подыскивать участников . Можно не беспокоиться о том, где находится человек, – главное, чтобы у него был высокоскоростной Интернет. Такое расширение параметров поиска особенно сильно выручает, когда надо найти людей, обладающих знаниями в какой-нибудь узкой предметной области.

•  Не надо никуда ехать . А значит, на всю процедуру участнику тестирования придется потратить не два и не три часа, а ровно час. На таких условиях помочь вам согласятся даже весьма занятые люди.

•  Удобство планирования . Можно назначать тестирование на любое время. Если вам нужен редкий специалист, который освобождается только в 11 часов вечера, вы можете запросто назначить тестирование на это время.

•  Дает [почти] те же результаты, что и очное тестирование . Да, удаленное тестирование действительно способно вскрыть те же проблемы.

Может, в таком случае полностью перейтина удаленное тестирование?

Что я могу сказать. Результативность удаленного тестирования на 20 % ниже по сравнению с очным, а усилий на его организацию требуется на 30 % меньше [35] .

Итак, вы теряете 20 % чего-то за счет того, что участник тестирования не сидит рядом с вами. Конечно, вы получаете более богатый опыт, когда пользователь находится в метре от вас: так вам гораздо проще понять, о чем он думает.

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

Кроме того, удаленным тестированием труднее управлять. Если, например, кто-нибудь войдет в кабинет участника тестирования и отвлечет его, то вы почти ничего не сможете с этим поделать. Особенно туго придется, если попадется «душный клиент»: у вас не будет возможности взглядом или жестом показать ему, что пора вернуться к выполнению задания.

Как это делается?

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

Вам надо будет заранее проверить работу программы для дублирования экрана. Это можно сделать, например, когда вы созвонитесь, чтобы назначить время начала сеанса.

Еще надо решить, чей экран будет ведущим, а чей – дублирующим. Лучше всего попросить пользователя предоставить доступ к его рабочему столу, чтобы вы могли только наблюдать за его действиями. Участнику тестирования не придется при этом нервничать из-за неизбежных (но обычно все-таки небольших) временных задержек. Если же вы тестируете некий программный продукт, который установлен только на вашем компьютере, сделайте наоборот: предоставьте пользователю доступ к своему рабочему столу.

(Если при тестировании вы будете видеть экран пользовательского компьютера, не забудьте попросить его спрятать все окошки, которые ему не хотелось бы вам показывать. Например, окно почтового клиента.)

В главе 8 я писал, что ассортимент программ для дублирования экрана весьма широк. При удаленном тестировании на первый план выходит удобство и простота использования. Следовательно, вам надо выбрать такое ПО, которое а) быстро настраивается (меньше чем за минуту), б) «пробивает» корпоративные брандмауэры и, возможно, в) не требует инсталляции приложения на компьютер (поскольку это может быть запрещено системными администраторами).

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

Еще при использовании GoToMeeting не возникает проблем с изменением размеров экрана (это важный нюанс: ведь у вас и у пользователя могут быть совсем разные мониторы с разным разрешением) и со сменой ведущего/ведомого экрана [36] .

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

Если вы не собираетесь пользоваться IP-телефонией, посоветуйте участнику тестирования поставить на столе телефон с громкой связью, чтобы не пришлось в течение 50 минут прижимать трубку к уху. Попросите вашего собеседника сделать так, чтобы во время тестирования ему никто не звонил. Впрочем, будьте готовы к тому, что его время от времени все равно будут отвлекать.

Организовать запись тестирования можно, придвинув микрофон к телефону.

Еще быстрее, еще дешевле и еще менее управляемо

В главе, посвященной удаленному тестированию, я не могу не рассказать про еще одну возможность, которую надо иметь в виду: неуправляемое удаленное тестирование [37] .

Такую услугу предоставляет сайт Usertesting.com [38] . Вот как все происходит.

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

Запрос направляется в пул тестировщиков, некоторые из них соглашаются пройти тестирование. На вашей страничке они проводят около 15 минут, выполняя задание (или задания) и размышляя вслух. После этого вы получаете запись сеансов тестирования.

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

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

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

С учетом всего сказанного вполне имеет смысл рассматривать такое тестирование как запасной вариант. Оно поможет вам быстро получить ответы на животрепещущие вопросы, которые по разным причинам не удалось выяснить в ходе ежемесячного тестирования. Еще с помощью этого сервиса очень удобно проверять, исчезла ли обнаруженная проблема после внесения изменений (сценарий задания у вас останется с «большого» тестирования, так что вам достаточно будет просто ввести уже готовые данные в форму заказа).

ЧАВО

ПОЧЕМУ Ж ВЫ ПОМЕСТИЛИ ЭТУ ГЛАВУ В КОНЕЦ КНИГИ?!

Прекрасный вопрос. Согласен, эти советы смотрелись бы более логично в первой части книги. Но я сознательно переставил их в конец. И вот почему:

Не надо пытаться устраивать удаленное тестирование, если есть возможность провести очную сессию.

Удаленное тестирование требует большей сосредоточенности, и при этом у вас нет возможности наблюдать, например, за выражением лица тестировщика, а это (особенно поначалу) очень важно.

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

НУЖНА ЛИ КОМНАТА НАБЛЮДАТЕЛЕЙ?

Да. Присутствие наблюдателей при удаленном тестировании ничуть не менее важно, чем при очном. Это важно, поскольку одной из составляющих успеха является общение, обмен мнениями и опытом. К тому же для наблюдателей вообще нет никакой разницы между удаленным и очным тестированием: в обоих случаях они смотрят на дублирующий экран и слушают высказывания пользователя через динамики.

Некоторые из вас, занявшись тестированием юзабилити, наверняка захотят получить дополнительную информацию [39] . Для самых продвинутых я решил перечислить в этой главе мои любимые книжки по тестированию и смежным дисциплинам [40] .

О тестировании в целом

Как я вас и предупреждал в самом начале, в этой книге нет детального описания тестирования. А в трех перечисленных ниже – есть, и очень хорошее. Выбирайте любую: не ошибетесь.

Handbook of Usability Testing (Second Edition)

Jeffrey Rubin and Dana Chisnell, John Wiley & Sons, 2008.

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

A Practical Guide to Usability Testing (Revised Edition)

Джо и Джинни, похоже, знают о тестировании юзабилити больше, чем все мы вместе взятые. Очень здорово, что они решили поделиться своими знаниями и написали «Практическое руководство по тестированию юзабилити».

Usability Testing Essentials: Ready, Set, Test!

Сейчас, когда я пишу эти строки, Кэрол все еще продолжает работать над переизданием своей чудесной книги «Основы тестирования юзабилити: на старт, внимание, тест!», вышедшей в 2002 году. Я уверен, что ее труд не будет напрасным и она порадует нас новой книгой, в которую будут включены вопросы обеспечения специальных возможностей и международного тестирования. Специальные вопросы

Paper Prototyping

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

Moderating Usability Tests

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

Measuring the User Experience

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

Recruiting Without Fear

Компания Джареда Спула набирает тестировщиков с 1988 года, и в статье «Рекрутинг без опасений», которую можно за 50 долларов скачать с сайта uie.com, рассказывается о том, как это делается.

233 Tips and Tricks for Recruiting Users as Participants in Usability Studies

В этой книге – «233 совета тем, кто набирает участников тестирования юзабилити», – соавтор Якоба Нильсена, Дебора Сова, делится своим богатым опытом: она уже много лет занимается рекрутингом тестировщиков. Устранение недостатков

Letting Go of the Words: Writing Web Content That Works

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

Forms that Work: Designing Web Forms for Usability

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

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

Я верю, у вас все получится. И помните: в этой книге содержатся лишь рекомендации. Экспериментируйте. Делайте так, как вам удобно.

В добрый час, друзья! Я жду ваших писем и интересных историй. Пишите мне по адресу stevekrug@rocketsurgerymadeeasy.com.

Сценарий теста

Здравствуйте,___________________. Меня зовут_____________________.

Сейчас я расскажу, что Вам предстоит.

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

Вы, должно быть, уже хорошо знаете, зачем мы Вас сюда пригласили, и все же я вкратце повторю основные идеи. Мы просим людей немного поработать с веб-сайтом, который мы разрабатываем, чтобы понять, всё ли работает как надо. Сеанс тестирования будет длиться около часа.

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

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

И еще: пожалуйста, не надо стесняться в выражениях. Смело ругайте все, что Вам не нравится. Наша конечная цель – сделать хороший сайт, поэтому нам крайне важно знать всю правду.

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

Если Вам в какой-то момент понадобится перерыв, не стесняйтесь сообщить мне об этом.

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

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

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

Есть ли у Вас вопросы?

Хорошо. Прежде чем мы откроем сайт, я хотел бы задать Вам пару вопросов.

Для начала: кто Вы по профессии? Чем занимаетесь?

Теперь такой вопрос: вы можете примерно оценить, сколько часов в неделю вы проводите в Интернете, с учетом просмотра сайтов и проверки электронной почты?

И каково процентное соотношение времени, которое Вы тратите на почту и на просмотр сайтов?

Какие сайты Вы чаще всего просматриваете?

Великолепно. Это был последний вопрос, и теперь давайте взглянем на наш объект тестирования.

Для начала я хотел бы, чтобы вы посмотрели на эту страничку и описали увиденное. Что она вам напомнила? Чей это сайт? Что на нем можно делать? Для чего он предназначен?

Страничку можно прокручивать вверх-вниз, но не надо пока нажимать ни на какие ссылки.

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

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

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

Спасибо, все, что вы сказали, очень полезно.

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

У вас остались какие-нибудь вопросы?

Соглашение о ведении записи

Благодарим Вас за участие в нашем исследовании юзабилити.

Сеанс тестирования будет записываться, что позволит ознакомиться с ним сотрудникам [НАЗВАНИЕ ОРГАНИЗАЦИИ], которые не смогли сегодня присутствовать лично.

Пожалуйста, прочитайте текст соглашения и поставьте свою подпись.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Я осознаю, что сеанс тестирования будет записываться.

Я даю разрешение компании [НАЗВАНИЕ ОРГАНИЗАЦИИ] использовать эту запись в целях улучшения тестируемой продукции.

Подпись: _____________________________

Расшифровка подписи: ________________

Дата: ________________________________

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

Вот имена этих героев (список никак не отсортирован).

Мои рецензенты: Джо Дюма, Кэролин Джарретт, Карэн Уайтхауз и Пол Шекспир . Именно эти люди спасли мою книгу от многих глупостей, которые в ней едва не появились. Впрочем, я должен оговориться: мнение этих людей далеко не по всем вопросам совпало с тем, что в нее все-таки вошло.

Элизабет Бэйл . Три года назад она появилась на моем горизонте, а до того почти 30 лет я работал один. Я и думать не хотел о том, чтобы изменить эту ситуацию! У меня уже был печальный опыт в начале 80-х, и повторять его не было никакого желания. Однако Элизабет стала настоящим другом, коллегой и помощником. Мне приятно с ней работать. Иногда ей со мной бывает трудно, временами у нас возникают разногласия, но мы с самого начала договорились, что никогда не будем кидать друг в друга тяжелые предметы.

Барбара Флэнаган . Это мой редактор и старый друг. Она великолепно разбирается в грамматике, и без ее помощи книга не вышла бы раньше 2014 года. О, эти бесчисленные «также» вместо «так же»! Бедной Барбаре пришлось заниматься этой ерундой. А все из-за моего упрямства. Мне бы хотелось когда-нибудь вместе с ней написать книгу о том, как писать книги.

Эллисон Сесил (и ее немецкий дог). К счастью, она смогла оторваться от дизайна серебряных табличек для садовых растений (их всего 4 тысячи, они продавались на www.anthropologie.com) и нашла время на оформление еще одной моей книги.

Марк Мачо . Без его иллюстраций книга была бы гораздо скучнее.

Нэнси Рюнцель, Нэнси Дэвис, Лиза Брэзьель, Глен Бисиньяни, Шарлен Вилл и все остальные замечательные, трудолюбивые, интеллигентные сотрудники издательства Peachpit, которые сделали эту книгу (уж не знаю, сколько часов они провели в спорах по поводу нее).

Джинни Редиш и Кэролин Джарретт . Спасибо вам за то, что вы есть.

Сообщество специалистов по юзабилити . Вы классные парни! Тем, кто еще в этом не уверен, надо съездить на вашу ежегодную конференцию и убедиться в этом лично.

Рэндольф Байес и Кэрол Бэрнам . Вы круто разбираетесь в теории, мне вас никогда не догнать. Спасибо за то, что мужественно согласились поучаствовать в дискуссии под названием «Дешевое любительское тестирование: угроза или опасность?», которая состоялась во время конференции 2008 года.

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

Харри . Хоть ты сейчас и в колледже, но все равно как-то умудряешься присылать мне забавные ссылки.

Наконец, Мелани . Ты меня поддерживаешь всегда: даже когда уверяешь, что нет. Ты – лучшее, что у меня есть.

Примечания

1

Семинар невозможно отложить: ты либо являешься и проводишь его, либо нет. А когда он заканчивается, не нужно больше ни о чем думать. Рабочий день прошел, и ты – свободный человек. Всё. По окончании самого первого семинара, который я проводил, меня настигло удивительное чувство: я вдруг понял, что сделал дело. Я ни разу не испытывал ничего подобного, будучи консультантом. Рекомендую попробовать!

2

Если вы в самом деле собираетесь взять эту книгу в дорогу, пожалуй, вам пригодится демонстрационный видеоролик, о котором я буду рассказывать в главе 2. Загрузите его на свой ноутбук с сайта www.piter.com.

3

…и который не попросит за один его этап столько, что в бюджете после этого не останется денег ни на какие улучшения…

4

Во всем мире насчитывается около 10 тысяч человек, которых можно считать специалистами по юзабилити. При этом лишь часть из них зарабатывает себе на жизнь тестированием. А сайтов в Интернете миллиардов этак – дцать. Дальше считайте сами.

5

Честно говоря, я настолько впечатлен тем, что никто не может рассказать мне ни одной такой истории, что даже подумываю об учреждении Премии имени Стива Круга. Я готов раздать десять миллионов индонезийских рупий (это чуть больше тысячи долларов США) первым десяти людям, которые сообщат мне о доказанных случаях ухудшения юзабилити после тестирования оного.

6

Если вы вдруг всерьез увлечетесь проблемами юзабилити, то обратите внимание на деятельность этой ассоциации, и особенно на эти ежегодные конференции. Чаще всего они проводятся в июне, в каком-нибудь месте, где в это время нестерпимая жара. Тем не менее конференции эти прекрасны. Они носят очень практический (отнюдь не академический) характер, и народ на них собирается очень дружелюбный. Сайт ассоциации UPA в Интернете находится по адресу www.upassoc.org.

7

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

8

При тестировании юзабилити мы называем людей, за которыми наблюдаем, «участниками тестирования», а не «тестируемыми», чтобы напоминать самим себе, что мы на самом-то деле тестируем не людей, а то, что они используют.

9

Один из таких «хозяев» написал мне спустя несколько месяцев после мастер-класса, что его команда, посмотрев запись демо-теста сайта, тут же внесла небольшое изменение, которое, как они посчитали (основываясь на результатах за прошедшие несколько месяцев), должно сэкономить их компании $100 000 в год. (Изменение это касалось привлечения клиентов к регистрации в интернет-магазине.)

10

Люди любят писать мне о тех проблемах, которые они обнаружили на Amazon.com, словно я как-то могу эти проблемы исправить. Да, у меня есть на этом сайте привилегированное членство (за $79 в год я получаю «бесплатную» доставку на второй день), но этим мое влияние ограничивается. Кроме того, Amazon проводит столько тестирований юзабилити, что если там в самом деле есть какие-то проблемы, то, я уверен, не потому, что о них не знают; возможно, они еще не придумали, как эти проблемы решить.

11

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

12

Если вы занимаетесь гибким программированием, не волнуйтесь. Загляните в раздел ЧАВО на с. 40.

13

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

14

Вообще-то был у меня еще один вариант названия, который нравился мне еще больше: «Энциклопедия юных сурков» (это такая карманного размера книжечка, которую Вилли, Билли и Дилли, племянники Скруджа Макдака, постоянно таскали с собой и в которой можно было найти ответы на любые вопросы). Но я прекрасно понимал, что парни из отдела по защите авторских прав корпорации Дисней, не обрадуются, если я так назову свой труд.

15

Предметные знания зависят от опыта человека в данной конкретной области. Например, брокер по операциям с недвижимостью много знает об ипотечных кредитах, ценах на недвижимость, районировании и т. д. Я называю это «Знанием», и вот мой любимый пример: чтобы получить лицензию таксиста в Лондоне, нужно сдать экзамен, свидетельствующий, что вы знаете 320 стандартных городских маршрутов, в том числе названия и направления всех переулков, от них отходящих, дорожные знаки, встречающиеся на пути, и все близлежащие достопримечательности. На приобретение Знания обычно тратятся годы.

16

А вот как эта шутка родилась. Легендарный режиссер Сесил Б. Демилль снимал батальную сцену грандиозной исторической драмы. Десятки колесниц, многотысячные массовки, падающие горящие башни – бюджет сцены был умопомрачительный. Снять ее предполагалось за один дубль с помощью полутора десятка кинокамер. Когда бой завершился, Демилль прокричал в свой мегафон: «Снято!» А потом спросил у стоявшего на соседнем холме главного оператора: «Готово?» Тот помахал в ответ и с воодушевлением ответил: «Готов начать в любой момент, Сесил!»

17

Вы будете смеяться, но этот процесс даже имеет свое название: «отложенный просмотр».

18

Как говорил известный американский бейсболист Йоги Бера: «Теоретически между теорией и практикой разницы практически нет. Но практика показывает, что она есть».

19

С полной версией «Шпаргалки ведущего» можно ознакомиться на с. 198–202. Ее также можно скачать с сайта нашего издательства по адресу www.piter.com.

20

Если какое-нибудь выражение регулярно, при каждом прочтении кажется вам неестественным, можете внести в эту речь минимальные изменения. Главное, чтобы не искажался смысл. Скажем, если вам не нравится выражение «если у вас в ходе этого сеанса тестирования возникнут какие-нибудь вопросы…», отредактируйте текст и напишите, к примеру: «если в процессе у вас возникнут какие-нибудь вопросы...». Но после этого будьте любезны зачитывать всякий раз один и тот же текст.

21

Теория Большого Взрыва применительно к юзабилити веб-сайтов, с. 161.

22

Помните автомобиль, дизайн которого разработал Гомер Симпсон? С пушистыми коврами, пузырьковыми сводами и тремя «клаксонами» («…потому что, когда злишься, его невозможно найти!»), которые непременно должны играть Кукарачу. Себестоимость этого чудовища составила 82 тысячи долларов.

23

Кэролин Снайдер, специалист и автор книг по юзабилити, рассказывала, как она вырезала из записи упоминание о курении марихуаны. А мне однажды довелось тестировать сайт со студентами колледжа при католическом университете. Я спросил у моих участников тестирования, какие сайты они обычно посещают. «Ну, во-первых, порно-сайты…», – начал один из студентов. Пришлось вырезать этот момент из записи.

24

Наверное, так происходит потому, что люди считают себя гостями, а вас – любезными хозяевами. Им заплатили, их выслушали, и они не хотят показаться грубиянами. Еще это может означать, что у этих пользователей были настолько заниженные ожидания, что ваш уродливый сайт показался им вполне нормальным, не хуже других. Лично я считаю, что тут имеет место «Стокгольмский синдром», при котором жертвы в результате сильного шока начинают чувствовать эмоциональную связь с агрессорами, симпатизировать им и даже защищать их в суде.

25

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

26

Эти раздаточные материалы можно скачать с сайта нашего издательства по адресу www.piter.com, при необходимости отредактировать и распечатать.

27

Роберт Бенчли – великий американский юморист. В 1920-х годах его заметки можно было найти в The New Yorker (многие из них впоследствии были изданы в книге «Дэвид Коперфилд, или Двадцать тысяч лье под водой»). Господин Макгрегор был личным помощником Бенчли, и ему зачастую приходилось прибегать к различным уловкам, чтобы вытащить писателя из кровати.

28

Одесса. Очередь за дефицитом. Приезжий спрашивает: «Что дают?» – «Цорес!» – «Какой размер?» – «Как раз на вашу голову». (Цорес на идише означает душевное страдание, горе, трагическое событие.)

29

Ну вот, докатился до того, что цитирую генерала Паттона…

30

1937 год. Москва. Кремль. Сталину показывают новый фильм. «А что это главный герой так на Сталина похож? Актера – расстрелять! Режиссера – расстрелять!..» «А может, актеру усы сбрить, Иосиф Виссарионович?» «Ну… или так!»

31

Клудж – это программа, которая вообще-то не должна работать, но почему-то работает.

32

Попадает мужик в тюрьму. Вдруг замечает, что когда кто-то из сокамерников называет какое-нибудь число, все остальные заливаются смехом. «В чем дело?» – спрашивает он у соседа. «Мы слышали все анекдоты уже столько раз, что решили их пронумеровать», – объясняет тот. «Теперь не рассказываем их, а просто называем номера». Тогда новичок набирается смелости и выкрикивает: «37!» Никто не смеется. «Почему?» – спрашивает он. «Это очень скверный анекдот, парень!»

33

Attention Web Designers: You Have 50 Milliseconds to Make a Good First Impression. Gitte Lindgaard, Gary Fernandes, Cathy Dudek and J. Brown, Behaviour & Information Technology, Vol. 25, № 2, March – April 2006, p. 115–126.

34

…особенно когда имеешь дело с юзабилити интранета: в этом случае так легко подсчитать отдачу! Например: «Наши тесты показывают, что при использовании улучшенного дизайна работники могут экономить 15 минут ежедневно за счет удобного поиска контактов в электронном корпоративном справочнике. При средней зарплате 3 рубля в минуту и количестве сотрудников предприятия, равном одной тысяче, в год можно сэкономить 11 500 000 рублей. Наше тестирование вместе с редизайном стоит 300 000 рублей. Итого компания сможет сэкономить 11 200 000 рублей».

35

Конечно, расчеты приблизительные. Как любит шутить на презентациях Джаред Спул: «74 % статистических данных взяты с потолка».

36

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

37

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

38

Вообще-то уже есть несколько таких сайтов, и все они работают примерно по одной и той же бизнес-модели. Просто Usertesting.com появился раньше других, и я его лучше знаю.

39

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

40

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