На прошлой неделе мне позвонил клиент, спросить совета по поводу своего первого юзабилити-тестирования. Его продукт — это большой информационный сайт потребительской направленности с миллионами посетителей ежемесячно (почти как большой финансовый ресурс об акциях, инвестиционных стратегиях от «гуру» — инвесторов и аналитиков, советы которых так любят читать пользователи).
Они планируют ре-дизайн страниц и навигации. У них есть три варианта дизайна страниц и пять — навигации, которые им разработала некая фирма. Никакого анализа предоставленных вариантов дизайна не проводилось.
Чтобы выяснить, какой из вариантов выбрать, команда разработчиков получила от руководства (наконец-то!) «добро» на проведение первого в жизни ресурса юзабилити-тестирования. Сайт существует уже несколько лет, но его создатели никогда еще исследовали, как реальные пользователи работают с ним.
До сих пор менеджмент рассматривал юзабилити-тестирование как «роскошь», которую они не могли себе позволить — главным образом из-за отсутствия необходимого времени. Чтобы первое юзабилити-тестирование было гарантированно успешным, команда проекта обратилась к нам.
Они долго и упорно добивались у руководства одобрения на проведение этого проекта. Если все пройдет успешно, то впоследствии будет легче проводить будущие исследования. Если кому-нибудь покажется, что исследование не помогло выбрать правильный вариант дизайна, то убедить руководство в необходимости нового будет крайне сложно.
Трудности сравнительного анализа
Когда мы начали обсуждать проект, первый вопрос, который задали члены команды, был — как сравнивать варианты дизайна. В идеале, думали они, мы дадим каждому участнику тестирования поработать с каждым вариантом дизайна и навигации, а потом как-нибудь решим, какой из них «лучший». Пара дней тестирования вариантов, затем подсчет набранных очков — и объявляем победителя.
Однако даже в идеальных условиях сравнительный анализ — дело непростое. Во-первых, необходимо определить, действительно ли сравниваемые варианты отличаются друг от друга? Если нет, все они могут быть созданы на общем ложном предположении, и выбор любого из них будет неверным решением.
Допустим, разработчики прекрасно справились с созданием действительно альтернативных вариантов дизайна, наша следующая проблема — провести их пользовательскую оценку. Для этого каждый вариант необходимо прогнать через пользовательское тестирование с реальными задачами.
Подбирать реальные пользовательские задачи всегда сложно, но еще сложнее это делать, если информация о пользователях ранее не собиралась и не изучалась. Команда собрала какую-то информацию из маркетинговых исследований, какую-то из статистики посещаемости сайта, но в ходе обсуждения этой информации стало ясно: они не совсем понимают, почему люди приходят на сайт.
Положим, что команда все-таки может подобрать пользовательские задачи, остается еще одна проблема — сравнительный анализ всех вариантов. Поскольку в нашем случае речь идет о тестировании новых вариантов дизайна, необходимы исходные показатели.
Как минимум, нам потребуется протестировать каждый вариант дизайна первым (против существующего дизайна), чтобы исключить «эффект обучения». (Этот эффект проявляется, когда задачи и варианты идентичны. Откуда вы знаете, почему второй по счету вариант эффективнее — потому, что он объективно лучше, или потому, что пользователь уже научился в ходе тестирования первого?)
Исходя из соображений статистики, для первого исследования мы рекомендуем брать не менее четырех пользователей для тестирования каждого варианта. Значит, для шести вариантов понадобится минимум 24 пользователя.
В нашей истории это создает еще одну проблему: имеющийся бюджет не позволяет протестировать все варианты дизайна с 24 пользователями за два дня. Требуется креативный подход.
Посмотрим на проблему с другой стороны
Что будет, если не спрашивать пользователей, какой из вариантов «лучший»? Пусть команда сама выберет лучший вариант дизайна.
Вместо пользовательского тестирования всех вариантов мы предложили сфокусироваться на исследовании имеющегося дизайна, чтобы затем, на основе полученных в ходе исследования знаний и предположений, запустить процесс принятия решения. Вместо сравнительного анализа вариантов мы рекомендовали такую схему:
Шаг 1: Создайте матрицу значимых отличий
Во-первых, мы предложили проектной команде в ходе подготовки исследования создать Матрицу Значимых Отличий (МЗО) вариантов дизайна. Каждая строка в МЗО будет отражать признак, который отличает данный вариант от существующего дизайна.
Затем команда присваивает каждому такому признаку «вес» — цифра от одного до пяти, которая означает его важность для пользователя. Такую же оценку можно указать и под каждым вариантом дизайна, обозначая, насколько хорошо каждый из них удовлетворяет конкретную потребность пользователя. В конце команда подсчитывает баллы, набранные каждым вариантом дизайна, и выявляет «лучший» из них.
Шаг 2: Возьмите пользователей из двух разных групп
Мы посоветовали проектной команде рекрутировать для исследования как опытных (лояльных) пользователей ресурса, так и новичков. В первый день мы предложили провести тестирование с опытными пользователями, во второй день — с новыми пользователями сайта. Лояльные пользователи помогут нам выяснить список важных для них задач. Новички помогут определить, что важно для людей, которые впервые пришли на сайт, например, как они выясняют основные принципы его работы.
Шаг 3: Исследуйте внутреннюю ценность
Исследование внутренней ценности сайта (the Inherent Value Test) поможет вам понять, что ценного находят лояльные пользователи в существующем дизайне. Результаты исследования помогут определить, эффективно ли транслируются эти ценности новым пользователям сайта.
Модератор выясняет, как каждый участник из группы опытных пользователей использует сайт. Он узнаёт, почему пользователь заходит на сайт, что он пробовал сделать в прошлый раз, какие результаты получил. Потом модератор просит участника тестирования повторить свои недавние действия, что даст команде представление о ценных для пользователя свойствах сайта. Таким образом, у команды сложится понимание, что именно нравится лояльным пользователям на сайте.
У пользователей из группы новичков модератор должен узнать, какие из задач, указанных опытными пользователями, они наверняка бы захотели бы выполнить на сайте. Потом участники должны будут выполнить выбранные задачи, исследуя достоинства сайта. Это поможет проектной команде понять, насколько хорошо существующий дизайн передает ценность сайта пользователям, впервые зашедшим на него.
Шаг 4: Покажите «лучший» вариант
После того, как все участники тестирования попробуют реализовать свои задачи в существующем дизайне, дайте им поработать с «лучшим» вариантом, выбранным в соответствии с Матрицей Значимых Отличий. Это будет скорее критика, чем опыт использования, поскольку этот вариант не является пока функциональным.
Однако благодаря тому, что пользователи только что пробовали рабочий сайт, они смогут достаточно точно описать, каким образом они выполняли бы те же задачи в новом варианте дизайна. Таким образом, у команды сложится представление о пользовательском видении разницы существующего и лучшим из альтернативных вариантов дизайна.
Шаг 5: Если есть время, протестируйте конкурента
Если позволяет время, во время каждого тестирования уделите несколько минут выполнению тех же задач на сайте, принадлежащем конкуренту. Это поможет команде увидеть, в чем конкурентное преимущество их сайта, и даст пищу для новых дизайнерских решений. Если выяснится, что участник регулярно пользуется сайтом конкурента, рекомендуем поработать с ним именно на сайте конкурента, чтобы выжать максимум информации о его преимуществах перед нашим сайтом.
Шаг 6: Проведите сравнительный анализ вариантов дизайна
При анализе результатов тестирования, мы посоветовали проектной команде снова обратиться к составленной Матрице Значимых Отличий. Теперь к МЗО надо добавить пользовательские задачи и ценности, а также и провести заново оценку (внеся соответствующие изменения в иерархию важности задач). Когда все будет сделано, матрица поможет принять окончательное решение, какой из имеющихся вариантов дизайна целесообразно развивать.
Информированные решения
Команды обязаны принимать решения. Успешные команды принимают информированные решения.
Возможно, описанный подход лишен изящества исследования дизайнерских решений на основе интуиции. Однако для данного клиента и в данных условиях, исследование действующего дизайна является лучшим решением. Субъективная оценка пользователей каждого из вариантов дизайна заняла бы больше времени и дала бы неясные результаты. Нам показалось, что исследование главным образом существующего дизайна сайта даст команде наилучшее представление, какой из альтернативных вариантов выбрать для ре-дизайна (если он вообще нужен).
Джаред М. Спул 19 мая 2008 г.
Впервые опубликовано в «Юзабилити Бюллетень, выпуск 18, июнь 2008».