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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И наконец:

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

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

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

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

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

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

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