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

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

ЧАВО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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