Читать онлайн Как сделать сайт удобным. Юзабилити по методу Стива Круга бесплатно

Вступительное слово

Зовите меня Измаил

Как появилась эта книга. Парочка оправданий. Пара слов о домоводстве

Я люблю дедлайны. Особенно этот свист, с которым они проносятся мимо.

Дуглас Адамс, написавший «Автостопом по галактике» и никогда не сдававший свои рукописи вовремя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЧАВО

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

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

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

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

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

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

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

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

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

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

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

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

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

Обнаружение проблем с юзабилити

Глава 1

Слонов-то не видать

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

– Для чего ты вертишь курицу у себя над головой?

– Так я отгоняю слонов.

– И что, помогает?

– Ну, слонов-то не видать!

ОЧЕНЬ СТАРАЯ ШУТКА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И наконец:

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

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

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

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

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

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

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

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

ЧАВО

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

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

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

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

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

Глава 2

А теперь я распилю мою [прекрасную] ассистентку пополам

На что похоже самостоятельное тестирование

И это всё, друг мой?

ПРИПЕВ ИЗ ПРОПИТАННОЙ ТОСКОЙ ПЕСНИ ПЕГГИ ЛИ «IS THAT ALL THERE IS?»

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

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

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

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

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

И это всё?

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

ЧАВО

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

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

Глава 3

Одно утро в месяц – мы не просим о большем

План, которому запросто можно следовать

Одна банка в неделю – мы не просим о большем!

НЕВЕРОЯТНО УДАЧНЫЙ РЕКЛАМНЫЙ СЛОГАН КОМПАНИИ BLUE DIAMOND GROWERS, ПРИМЕРНО 1990 ГОД

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

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

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

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

Одно утро в месяц – мы не просим о большем

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

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

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

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

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

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

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

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

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

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

ЧАВО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 4

Когда и что тестировать

Почему самое трудное приходится делать сначала

Давайте, на следующей неделе мы принесем вам набросок на салфетке побольше.

ТО, ЧТО ВСЕГДА ГОВОРЯТ МОИ КЛИЕНТЫ, КОГДА Я ПРОШУ ИХ ПОКАЗАТЬ ПРОЕКТ ДИЗАЙНА, ХОТЬ НА САЛФЕТКЕ

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

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

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

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

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

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

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

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

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

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

Начинайте раньше, чем вам кажется нужным

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестирование дизайна страниц

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

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

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

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

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

Тестирование работающих прототипови всего остального

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

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

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

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

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

Глава 5

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

С кем проводить тестирование и как найти этих людей

Один участник тестирования – это на 100 % лучше, чем ноль участников.

Стив Круг. Первый закон тестирования юзабилити

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

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