Главная сложность с тестированием юзабилити в гибкой среде заключается в том, что нужно постоянно бежать впереди паровоза и укладывать для него рельсы. У стремительно работающих программистов нет времени на то, чтобы разрабатывать прототип. Предполагается, что все, что они пишут, – это работающий код.
Это значит, что вам придется тратить часть своего времени на разработку прототипов того, что программисты будут делать в ходе следующего спринта. Значит, на каждом раунде вы сможете тестировать то, что разработано в ходе предыдущего спринта. Плюс бумажный проект того, что им нужно будет делать в ходе следующего.
Обязательно заниматься этим именно по утрам?
По утрам или нет – на результат не влияет. Легко представить себе ситуацию, когда участникам тестирования неудобно заниматься этим в рабочее время, и потому вы вынуждены проводить его в 6, в 7, а то и в 8 вечера (обед в таком случае можно посвятить привлечению наблюдателей, а совещание провести на следующий день, за завтраком или опять-таки за обедом).
Важно уложиться с тестированием в половину рабочего дня (это необходимо для того, чтобы на него могло прийти как можно больше наблюдателей) и обсудить результаты как можно скорее, пока впечатления еще свежи и все помнят детали.
Мне говорят: «Всякий раз ты тестируешь свой продукт на трехпользователях. Прости, но это недостаточный размер выборки. Твои результаты нельзя считать статистически достоверными!» Что ответить на это?
А вот что: «Вы абсолютно правы. Тестирование на трех пользователях не может дать статистически достоверных результатов. Выборка настолько мала, что тут и речи не может быть о статистике. Но цель такого тестирования заключается не в том, чтобы что-то доказать: задача в том, чтобы выявить наиболее существенные проблемы и, решив их, улучшить нашу продукцию. Эта методика работает, потому что большинство проблем настолько очевидны, что их существование не требует "доказательств"».
Постарайтесь произнести это уверенно и дружелюбно.
Что почем? Каков бюджет мероприятия?
Вот расчет затрат на год (за исключением вашего времени), необходимых для проведения самостоятельного тестирования:
А вот «бюджетный» вариант на случай, если вам не выделено вообще никакого бюджета:
Глава 4 Когда и что тестировать Почему самое трудное приходится делать сначала
Давайте, на следующей неделе мы принесем вам набросок на салфетке побольше.
ТО, ЧТО ВСЕГДА ГОВОРЯТ МОИ КЛИЕНТЫ, КОГДА Я ПРОШУ ИХ ПОКАЗАТЬ ПРОЕКТ ДИЗАЙНА, ХОТЬ НА САЛФЕТКЕ
Очень простая мысль: если вы хотите посмотреть, как люди пытаются использовать создаваемый вами продукт, вам необходимо этот продукт им предоставить, хоть в каком-нибудь виде. Это означает, что вы должны хорошо понимать, что именно вы будете тестировать в следующий раз.
Многие думают, что тестировать недоделанный продукт невозможно, что для этого нужен хотя бы функционирующий прототип.
Однако профессионалы, занимающиеся юзабилити, советуют начинать тестирование как можно раньше.
Их опыт позволяет им утверждать, что серьезные проблемы с юзабилити можно выявить уже на начальных этапах разработки, даже если вам почти нечего показать пользователю.
Более того, они прекрасно знают, что гораздо проще и дешевле устранить недостатки в начале, еще до того, как ошибочные идеи будут внедрены. Порой серьезные проблемы выявляются настолько поздно, что их уже невозможно исправить. Худшее, но, увы, самое распространенное решение – дождаться, пока сайт будет разработан и готов к запуску, и в этот момент начать тестирование.
К сожалению, приходится признать, что люди склонны сопротивляться идее раннего тестирования. Чаще всего они пытаются оправдаться, используя следующие аргументы.
• «Мы еще слишком мало сделали». Казалось бы, если ничего не работает, то нечего и тестировать. Но что мешает показать людям наброски дизайна, даже если они нарисованы от руки на салфетке?
• «Продукт еще слишком сырой». Дизайнеры очень не любят показывать свои недоделанные работы. Однако пользователи меньше стесняются в выражениях при описании своих впечатлений от продукта, зная, что он впоследствии будет доработан.
• «Зачем заставлять людей тратить время на разглядывание того, что еще сто раз изменится?» Когда вы занимаетесь разработкой, идеи, которые вы держите в голове, всегда лучше тех, которые уже воплощены в виде кода или наброска. Да, пользователи расскажут вам об уже известных вам проблемах, но, поверьте, без сюрпризов не обойдется. По большому счету, именно ради таких сюрпризов все и затевается: на многое вы могли не обратить внимания, потому что слишком хорошо знаете предмет или потому что гораздо меньше смыслите в чаяниях пользователей, чем вам кажется.