90% всех юзабилити-тестов - бесполезны

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

Метод тестирования юзабилити берет свое начало из науки, изучающей процесс взаимодействия "человек-компьютер" (Human-Computer Interaction - HCI).

 

 

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

Контекст, а не измерения

Веб, словно некий Франкенштейн, - дикая смесь творческого потенциала и кода, вдохновения и обыденности, формы и функционала, искусства и науки. Хороший веб-дизайн соединяет себя все эти факторы, и часто трудно сказать, где заканчивается один и начинается другой. Глупо пытаться точно оценить точное время, необходимое для решения той или иной определенной задачи. Самый важный вопрос, на который прежде всего необходимо ответить, почему пользователи останавливаются? Что они разглядывают? Что они об этом думают? Ваша навигация их запутала потому, что она неудачно разбита на категории, или из-за неверно выбранных слов, а может из-за неудачного расположения? А может из-за того, что она в разных разделах сайта разная, или потому что плохо написаны CSS стили? Традиционное тестирование юзабилити не даст вам ответы на эти вопросы.

Мы должны отказаться от мифа, что тестирование сайтов с помощью пользователей - это количественный процесс. Фокусируясь лишь на числах и игнорируя другие типы данных, вы в результате получаете лишь пустые высказывания типа "Дизайн А на 5% более удобен, чем дизайн Б" (или "90% всех тестов юзабилити - бесполезны"). Вместо этого исследования должны углубляться в качественные показатели дизайна с целью понять, как и почему люди реагируют на то, что было создано, и, что более важно, как использовать эти реакции в будущих работах.

Сделайте это сами

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

Итак, настало время закатать свои рукава. Для тестирования юзабилити веб-сайта вовсе не нужны сторонние фирмы, которые никак не участвуют в процессе его разработки. Тестирование должно быть включено как определенный этап в сам процесс разработки. Его необходимо выполнять с полноценным привлечением всей команды разработчиков, так, чтобы каждый мог взглянуть на свою работу с точки зрения пользователя. Разработка и проведение юзабилити тестирования должны быть неотъемлемой задачей одного из членов вашей команды (при этом многие считают, что это не должен быть сам дизайнер сайта).

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

Тестирование юзабилити - это часть проектирования, а не контроль качества

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

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

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

Меньше затрат

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

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

Больше новых идей

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

Дополнительная литература

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

• "Don't Make Me Think" by Steve Krug (есть на русском)
• "The Culture of Usability" by Janice Fraser
• "Observing the User Experience: A Practitioner's Guide to User Research" by Mike Kuniavsky
• Bolt and Peters' remote usability testing tutorial

Лэйн Беккер

Lane Becker is a Partner at Adaptive Path. He specializes in design and process strategy consulting, but he's also run a lot of usability tests.