Самым информативным, трудоемким и интересным типом исследования, которое проводится для изучения юзабилити интерфейса – это тестирование «на», или лучше сказать «с» пользователями. Основной его задачей является предоставление возможности всем заинтересованным лицам увидеть то, как человек пользуется продуктом и с какими трудностями он сталкивается при взаимодействии с ним. Некоторые неподготовленные зрители после этого начинают по-новому смотреть на свое детище и переставать удивляться, почему им никто не хочет пользоваться (впрочем, не всегда такой эффект сохраняется надолго, поэтому принимать эту «пилюлю» рекомендуется регулярно). Другое дело модератор — искушенный зритель пользовательской драмы.
В классическом понимании, модератор – это человек, который исключительно проводит сессии. Его основная задача – создать такие условия тестирования, чтобы человек чувствовал себя комфортно, забыл о том, что он сидит в незнакомой комнате с незнакомым человеком, и взаимодействовал с интерфейсом так, как он привык это делать в реальной жизни. Наблюдением за респондентом и фиксированием трудностей, возникающих у него в ходе работы с продуктом, занимается наблюдатель (на зарубежный манер, «ноуттейкер»). В идеальном случае, модератор имеет минимальное представление о дизайне исследования и специфике продукта, что позволяет ему быть максимально беспристрастным.
В реальной практике все несколько иначе. Модератор часто является исследователем «полного цикла», задействованным на всех этапах юзабилити-тестирования.
Первый и, пожалуй, самый важный из этих этапов – подготовительный. Перед проведением исследования мы стараемся внимательно изучить продукт, чтобы выявить всевозможные подводные камни, которые могут встретиться нам в процессе его тестирования с пользователями. Мы беседуем с заказчиком и активно «щупаем» продукт с разных сторон.
С самого начала работы в качестве аналитика, я задавалась вопросом о том, насколько хорошо мне как модератору необходимо знать интерфейс, который мы собираемся тестировать на пользователях. Кажется очевидным, что для подготовки сценариев тестирования и составления списка вопросов для респондентов мы должны хорошо ориентироваться в интерфейсе. Кроме того, кажется, что мы должны быть готовы предвосхищать все те трудности, с которыми может столкнуться пользователь во время тестирования, чтобы в случае непреодолимого препятствия вывести его на верный путь, нами же запланированный.
Надеюсь, вы уловили нотку сомнения в моих словах? Итак, предлагаю поставить под сомнение очевидную вещь: «Модератор должен досконально знать интерфейс, тестирование которого он проводит».
Юзабилист – не адвокат пользователя
Будучи консалтинговой юзабилити-компанией, чаще всего мы не являемся создателями продуктов, которые тестируем (мы бы и рады помочь не только словом, но и делом, да не всегда заказчик готов предоставить такой «доступ к телу» своего проекта). По этой причине мы заведомо хуже знаем продукт, чем наши заказчики, которые либо являются владельцами бизнеса, целям которого служит интерфейс, либо подрядчиками, занимающимися разработкой или продвижением интерфейса.
И это – одна из причин, по которой к нам обращаются. Мы можем взглянуть на продукт со стороны – глазами пользователя, при этом мы либо сами имитируем поведение пользователей (экспертная оценка), либо проводим наблюдение за реальными пользователями (юзабилити-тестирование). Наш взгляд еще не замылен. Мы не тратили дни и ночи за бесконечными перекраиваниями интерфейса; мы никогда не получим денег с рекламных баннеров, размещенных в нем; мы не проводили часы в совещаниях, на которых совершались безуспешные попытки примирить разнонаправленные стороны, всегда присутствующие внутри компании. Мы еще не страдали. У нас нет эмоциональной привязанности к продукту в целом, или к отдельным решениям в его интерфейсе.
В этом плане до начала проекта, мы не находимся ни на стороне разработчиков, так как не имеем отношения к разработке продукта, ни на стороне пользователей, так как не являемся «пользователями» тестируемого интерфейса. Вопрос заключается в том, на чью сторону мы должны встать как исследователи. И ответ очень прост: ни на какую, или, если хотите, остаться на своей.
Мотивация определяет опыт
Как правило, любой интерфейс или продукт тестируется на двух «глобальных» группах пользователей: опытных и неопытных. Опытные – это те пользователи, которые уже сталкивались с этим или аналогичным продуктом при решении своих задач. Новички – это, как правило, пользователи, которые еще не имели опыта взаимодействия с интерфейсом, но потенциально в этом заинтересованы. Например, в настоящее время они выполняют аналогичные действия офлайн, но это является для них муторным и неинтересным занятием, которое может быть упрощено с участием технологий.
В ходе подготовки к тестированиям мы приобретаем опыт работы с приложением, как будто бы приближаясь в этом плане к группе «опытных» респондентов.
Интуитивно кажется, что это так, но давайте и это поставим под сомнение. Как я уже упоминала, чаще всего, мы не являемся пользователями продукта, который тестируем. Простыми словами, у нас нет реальной мотивации к его использованию, наша мотивация, если хотите, это проведение исследования – изучая продукт перед проведением исследования, мы сознательно или бессознательно ищем в нем изъяны (и находим). А это отличается от поведения «среднего» пользователя, который хотел бы не замечать проблем.
Когда слон на самом деле муха
В чем здесь заключается опасность? Модератор тоже человек, а значит, у него есть подсознательные и бессознательные порывы, с которыми он не всегда в силах совладать. Например, зная, что приложение не соответствует общепринятым эвристикам и, ожидая, что это приведет к проблемам в работе с ним, он может незаметно для себя во время сессии тестирования подтолкнуть пользователя к признанию этого факта. Это выльется в гипертрофированном представлении проблемы, которая имеет критическое значение только в уме модератора, но не является реальным препятствием для работы пользователей.
Подчеркну, что речь идет не о надуманной проблеме, а о реально существующей. Просто каждая проблема имеет свою степень критичности – то есть, блокирует она работу пользователей, готовы ли они бросить использовать приложение или будут вполне успешно продолжать работать с ним несмотря ни на что.
Самый простой пример, который лежит на поверхности – социальные сети. Кто-то может не согласиться, но осмелюсь заявить: интерфейс социальной сети Facebook далек от того, что мы бы назвали «интуитивным». Этап «вхождения» дается новичку непросто, так что долгое время он использует только самые базовые функции. Но это все неважно. Ничто не может отвратить пользователя от использования социальной сети, если там его друзья (как поется в известной детской песенке: «Что мне снег, что мне зной, что мне дождик проливной, когда мои друзья со мной!»). В конечном счете, пользователи привыкают к предложенной им логике, и так называемые «улучшения» интерфейса могут быть, напротив, восприняты негативно.
Не дай бог кто-то подумает, что таким образом можно «обойти» юзабилити, сделав всякий сервис успешным только за счет включения социального аспекта. Речь не об этом или не совсем об этом. Всякому юзабилисту знакома фраза (она же название книги) «Не заставляйте меня думать». У меня есть еще одно предложение: «Не думайте за пользователей!». Кажется, что теперь никто не будет думать, но нет. Если мы немного видоизменим фразу Стива Круга, то она станет практически синонимичной моему варианту: «Не заставляйте пользователей думать так, как вы».
Знание – сила или слабость?
Этим всем я вовсе не хочу сказать, что изучение модератором интерфейса перед тестированием – это бесполезное и даже вредное занятие. Сбор данных о тестируемом продукте и разработка дизайна исследования – это очень важный этап, от которого зависит релевантность полученных результатов.
Завершая статью, хочется отметить те моменты, на которые исследователям стоит обратить внимание перед проведением юзабилити-тестирования:
- Изучая продукт для последующего проведения его тестирования на пользователях нам важно выяснить то, как его используют люди, а не искать и находить подтверждение собственным убеждениям.
- Формулируйте задания для тестирования в как можно более свободной форме – не сдерживайте пользователей, давайте им возможность свободно работать с интерфейсом, позвольте им забыть о вашем присутствии. Еще лучше – дайте им самим сформулировать задачи. Предтестовое интервью нередко дает такую возможность.
- Различные продукты требуют разной степени погруженности модератора в тематику: если мы тестируем массовый продукт – модератору не обязательно иметь собственное мнение о продукте, если оно у вас есть – лучше держите его при себе.
- Для каждого правила есть исключения, каждый интерфейс требует своего подхода. Например, тестируя игровой интерфейс, очень желательно, чтобы модератор имел о нем четкое представление и сам был игроком, иначе ему будет очень трудно разобраться в происходящем на тесте и включить эмпатию.
- Две головы всегда лучше одной – не забудьте дать прочитать свой сценарий коллеге, это всегда дает больше гарантий непредвзятости.
На сегодня все. Спасибо за внимание!
Автор: Екатерина Каминская, аналитик UIDG.
