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

• Название: Как сделать сайт удобным. Юзабилити по методу Стива Круга
• Автор: Стив Круг
• Жанр: Компьютерная литература

В этой книге знаменитый Стив Круг, автор мирового бестселлера «Не заставляйте меня думать» (Don't Make Me Think: A Common Sense Approach to Web Usability), излагает принципы своего метода по улучшению юзабилити интернет-сайтов. В присущей ему ироничной манере автор описывает процесс тестирования и обнаружения проблем с юзабилити, а также их эффективного устранения.

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

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

Перевод: В. Шрага

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 4 Когда и что тестировать Почему самое трудное приходится делать сначала

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

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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

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

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

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

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

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

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

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

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

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

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

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