Привет! Меня зовут Тимофей, я продуктовый дизайнер в Альфа-Банке.
Бывают ситуации, когда спроектировал сценарий и думаешь, точно ли всё ок, уверен ли я, что пользователи воспринимают дизайн так, как мы задумывали? А ещё ж хочется получать меньше очевидных правок на презентациях своих идей, ощущать доверие членов команды к собственной экспертиз, да и просто чувствовать себя не хухры-мухры специалистом :)
Пу-пу-пу…Есть ли какое-то решение?
Давайте попробуем выйти в поля и покричать проверить свои прототипы с помощью коридорных тестов.
Кратчайшая теория
Коридорные тесты — это тестирование интерфейса, иконок, подписей, акцентов, чего угодно, чтобы убедиться, что все работает так, как задумывалось. А в процессе такого тестирования находятся барьеры, которые мешают пользователям достигать своих целей.
Нам, как дизайнерам, они помогают:
Находить проблемы в интерфейсы на этапе дизайна, а не когда функциональность уже релизнута в продакшен.
Создавать более удобные интерфейсы и повышать лояльность пользователей к продукту, что в свою очередь повышает доверие членов команды к вашей экспертизе.
Делать дизайн для реального мира, а не в вакууме, что делает вас более уверенными при аргументации своих дизайн-решении перед коллегами и стейкхолдерами.
Коридорные тесты хорошо применять на этапе, когда у вас уже есть макеты и вам осталось убедиться, что все работает так, как задумывалось. Например, вы сделали форму авторизации и хотите убедиться, что люди легко проходят её без подсказок. Поверьте, после первых коридорных тестов вы иначе посмотрите на свои безупречные прототипы.
Этапы работы с коридорными тестами
В идеале для проведения тестов необходимо пройти семь шагов:
Гипотезы.
Выбор метода.
Сценарий.
Прототип.
Поиск респондентов.
Проведение теста.
Анализ и выводы.
№1. Гипотезы
Гипотезы — это предположения, которые мы хотим проверить в ходе исследования.
До тестов у нас уже должны быть на руках гипотезы и макеты, чтобы их протестировать и посмотреть работает ли наша гипотеза или нет.
Для гипотез лучше использовать такой шаблон:
«Если мы сделаем [идея], то она сможет положительно повлиять на [критерий успеха], так как [почему идея хорошая]».
Здесь хочу задержаться чуть подольше и разобрать составление гипотез на примере, так как они по сути стартуют этап тестов и очень помогут при проведении и анализе результатов.
Представим гипотетическую ситуацию: в групповом чате рабочего мессенджера на 30 человек ведётся переписка между двумя участниками группы. Нам прилетают уведомления, мы заходим в чат, видим 150 сообщений о том, что кто-то не прав, пытаемся вникнуть, но в итоге понимаем, что нас это не касается и идем дальше заниматься своими делами. Время потрачено, как и энергия на то, чтобы вылезти из одной задачи, переключиться на переписку, вернуться к задаче и снова на ней сфокусироваться.
Для бизнеса есть проблема (если говорим про бизнес, то это всегда про деньги), рабочее время сотрудников, за которое они получают деньги, тратится впустую. Переписка ведется между двумя людьми, а остальные 28 человек потратили в среднем 5 минут и получили расфокус от текущих задач. Оплачено впустую 2 рабочих часа.
Проблема для пользователей: трата времени и энергии на неактуальную для них переписку.
Проблема есть и нам нужно её решить. А как нам понять, что проблема решена? Для этого нам нужно знать критерий успеха: в нашем случае — уменьшение сообщений в групповых чатах и увеличение эффективности рабочего времени сотрудников, просто потому, что нет необходимости отвечать в общем чате. Уведомления из комментариев будут относится только к участникам обсуждения конкретного сообщения.
В итоге на старте проекта у нас была вот такая продуктовая гипотеза:
«Если мы сделаем комментарии для сообщений, то это поможет уменьшить количество отвлекающих сообщений в групповых чатах и увеличить эффективность рабочего времени сотрудников, так как позволит вести обсуждения внутри сообщений и не отвлекать других участников уведомлениями»
Гипотеза для исследования, после того, как мы спроектировали решение и хотим его проверить:
«Человек понимает, как отправить комментарий под сообщением».
№2. Выбрать метод тестирования
Методы тестирования можно разделить на модерируемые и немодерируемые — в зависимости от того, выполняет ли участник задания самостоятельно или под руководством исследователя. Также различают форматы по месту проведения теста: удалённые или очные. Форматы с модерацией как правило дают больше ценной информации и позволяют глубже понять мотивацию и сложности пользователей, поскольку исследователь может уточнять ответы и наблюдать за поведением пользователя.
Методов, которые применяются при коридорном тестировании много и по каждому можно сделать отдельный доклад. Это и монадический тест, и парное сравнение, и первый клик. Каждый из методов может быть модерируемым или немодерируемым.
Но мы сегодня поговорим о модерируемом UX-тесте.
Модерируемый UX-тест предполагает присутствие интервьюера с респондентом в момент проведения теста оффлайн или онлайн. При такой проверке пользователь выполняет поставленные задачи, в то время как исследователь наблюдает за ним в режиме реального времени, фиксируются факты прохождения точек и ставятся пометки о трудностях, возникших у пользователя.
№3. Сценарий
Интерфейс это всегда путь из нескольких шагов, у него есть пользовательский сценарий. Каждый шаг сценария — это экран или страница.
Поэтому вначале хорошо бы зафиксировать конверсионные точки интерфейса, которые пройдет респондент для достижения результата. В нашем кейсе такими точками могут быть:
В дальнейшем эти конверсионные отметки сценария помогут анализировать поведение пользователя на каждом шаге и выявлять барьеры, которые мешают ему достичь результата. Задача исследователя — найти их, а затем устранить. Поэтому важно зафиксировать эти отметки прохождения сценария.
№3. Подготовка прототипа
Прототип для тестирования может быть:
Интерактивный кликабельный.
Работающий сайт или тестовая версия.
Просто картинка.
Чек-лист для проверки прототипа:
Сценарии выполняются.
Тексты, визуальный контент, цифры похожи на настоящие.
Нет ошибок и опечаток в текстах и цифрах. Люди 100% зацепятся за ошибки и непохожий на настоящий контент и суть задачи будет уже не важна — проверено неоднократно.
Заложена возможность быстро вернуться к началу сценария. (чтобы не тупить во время теста если что-то пойдет не так).
Нет подсказок (зачем нам делать неверные выводы с подсказками?).
№4. Поиск респондентов
По-хорошему тесты проводят с реальными пользователями продукта — с теми, у кого такие задачи встречаются в жизни. Но коридорное тестирование делает скидку на реальность: иногда достаточно просто поймать людей поблизости и попросить пройти сценарий.
Что можно сделать, чтобы найти респондентов:
попросить друзей, знакомых, родственников, подходящих под выбранные критерии, принять участие в тестировании (я так и делаю),
в идеальном случае: найти респондентов среди текущих пользователей продукта,
написать в специальные чаты и группы в социальных сетях,
в крайнем случае, обращаться к коллегам.
Сколько респондентов? От 5 до 8 респондентов достаточно, чтобы выявить самые грубые проблемы интерфейса.
При разработке новой функциональности или продуктов, хорошо подходит метод итеративного тестирования. Вы проводите тестирование на 2-3 респондентах, исправляете обнаруженные проблемы, затем проводите следующую итерацию и так далее, пока несколько респондентов подряд не смогут пройти сценарий без существенных затруднений.
Главный принцип такой: как только информация начинает повторяться — пора остановиться.
Но этот метод плохо применим для тестирования живых систем (существующих продуктов). В этом случае применяется классический метод, когда сначала проходят все сессии тестирования, и только затем делаются выводы о юзабилити-проблемах и необходимых улучшениях.
Если ресурсы и время на работу над продуктом сильно ограничены, руководствуемся принципом: «лучше меньше, чем ничего». Один респондент лучше, чем ни одного. Коридорный тест, не привязанный к целевой аудитории, лучше чем никакого.
№5. Проведение тестов
И вот мы наконец подобрались к тестам. Пойдём по шагам:
Шаг 1. Начало теста.
В самом начале теста проговариваем для человека следующие вещи:
Рассказать, чего мы тут собрались.
Провести смол-ток, расслабить обстановку, завоевать доверие. Например, спросить как дела, как он пользуется продуктом.
Сказать, что тут совсем не нужно торопиться и это не проверка знаний человека, а проверка интерфейса.
Шаг 2. Контекст.
В самом начале теста обязательно нужно озвучить контекст, чтобы человек понимал, какую задачу он должен решить (оставить комментарий под сообщением, где его отметили). Нет контекста — человек придумает себе задачу и начнет фантазировать о том, что не так с интерфейсом и как его улучшить.
В описании контекста для респондента нам помогут 4 вопроса:
Кем является респондент?
Какая у него есть проблема/задача?
Как он пытается её решить?
Как он попал на страницу?
Ответ на некоторые вопросы можно не озвучивать, например, если человек уже пользователь этого мессенджера, то не обязательно говорить: «Представьте, что вы пользователь рабочего мессенджера» или что-то такое. Мы отталкиваемся от контекста. Для примера описание контекста для пользователя мессенджера, который мы тестируем:
«Представь, что сейчас рабочий день, тебе пришло уведомление о сообщении в группе, где ты активно обсуждаешь задачи и ты заходишь в рабочий мессенджер, чтобы на него ответить. Ты хочешь ответить так, чтобы твой ответ не потревожил всех участников группы и им не пришло уведомление. Ты заходишь в мессенджер и видишь такой экран…»
Шаг 3. Открываем прототип и задаем 3 главных вопроса:
Что видишь?
Что думаешь?
Что можешь сделать?
Если тестируем флоу мобильного приложений, то идем по экранам и на каждом задаем эти вопросы.
Если тестируем лендинг, вопросы хорошо задавать итерационно. Например, показать одну часть лендинга и задать эти вопросы, потом другую — и снова задать те же самые вопросы. Чтобы сохранять фокус на каждой из частей и находить проблемы в каждой из них. Эти вопросы побуждают респондента мыслить вслух и доставать мысли, которые ему приходят во время взаимодействия с прототипом.
Разберем каждый вопрос отдельно.
«Что видишь?»
Это вводный вопрос, цель которого — понять, как человек ориентируется в контексте, в котором он находится, что привлекает его внимание в первую очередь.
«Что думаешь?»
Ответ на этот вопрос помогает выяснить, как человек интерпретирует информацию, понял ли он ценностное предложение или у него возникают дополнительные вопросы. Какие ощущения возникают у человека на экране, что он чувствует. Например страх, что случайно куда-то нажмет, или разочарование, что ему открылся экран совсем не тот, которой он ожидал.
«Что можешь сделать?»
Другие варианты — «Как думаешь, что произойдет при нажатии на эту кнопку» или «Куда бы ты нажал, чтобы сделать это?» Эти вопросы направлены на выяснение целей каждого действия и ожиданий от интерфейса.
Ответы на эти вопросы дадут вам знание о том, что понял человек из вашего интерфейса или лендинга, что он увидел, а что — нет.
Вопросы иногда включают у респондента режим «самообороны» — он начинает оправдываться или искать «правильный ответ». Можно заменить вопросы побудительными фразами типа: «Расскажите, что вы сейчас подумали…», «Поделитесь, что вам здесь понятно, а что нет…», «Давайте чуть глубже разберём этот момент…». Это звучит естественнее и не давит на респондента.
Во время тестирования большую часть времени говорит респондент — модератор вмешивается только в крайних случаях или когда нужно задать вопрос. Чем больше модератор комментирует и направляет, тем сильнее он влияет на ход исследования и искажает результаты. Тут главное правило:
Когда человек перестаёт думать вслух, то побуждаем его теми же тремя вопросами: «Что видишь? Как это понимаешь? Что можешь сделать?» Лучше не допускать ситуаций, когда пользователь молча листает интерфейс.
Если респондент всё-таки застрял и без подсказки вообще не двигается, можно помочь, но очень аккуратно. Например:
Вернуть к задаче, если человек отвлёкся: «Давайте вспомним, какая у вас сейчас цель по заданию».
Дать лёгкий толчок в нужную сторону, без конкретики: «Кажется, вы уже видели нужный элемент раньше», «Посмотрите ещё раз внимательнее на страницу».
В крайнем случае — направить явно, если иначе никак: «Попробуйте нажать сюда и продолжайте».
Также важно анализировать не только то, что человек говорит, но и обращать внимание на эмоции, чтобы найти проблемные места. Например, если человек смущается или хмурится и ничего не говорит, хорошо бы у него спросить, что вызвало у него такие эмоции.
Ну и если респондент начал критиковать ваш интерфейс — не защищайте своё решение вместо того, чтобы выслушать всю критику. Мы тут не для того, чтобы самоутвердиться, а как раз, чтобы найти проблемы в интерфейсе.
Опасные вопросы
А теперь о вопросах, которые могут возникать во время тестирования, но которые вам стоит задавать с большой осторожностью:
«Что бы вы изменили в интерфейсе?»
Есть риск, что респондент начнет фантазировать о возможностях, которые нужно добавить. Всегда нужно выяснять, какие проблемы человек хочет решить с помощью новой функциональности, чтобы потом придумать для них решение (и понять, нужно ли вообще решать эту проблему).
«Если мы уберем или добавим эту функциональность, вам понравится эта страница?»
Люди плохо прогнозирует будущее, а в ответ на такой вопрос, вероятнее всего, соврут, сами того не желая, потому что в него заложены ваши ожидания. Поэтому вместо этого вопроса лучше изучить путь человека, который привел его к негативному восприятию. Например, спросить «Почему вам важно, чтобы она была?»
Во время проведения фиксируем, где респондент столкнулся с трудностями и почему. Я это делаю в блокноте. Помечать важно, потому что вся информация забудется, если её не фиксировать. Когда вы будете анализировать результаты, то просто начнете придумывать за респондента.
№6. Анализ результатов и выводы
Совет: ещё на старте, когда формируете гипотезы, сделайте таблицу с их декомпозицией, шагами пользователя и конверсионными точками.
После интервью ничего не держим в голове — всё сразу заносим в таблицу: прошла ли гипотеза проверку, справился ли участник с заданием и где допустил ошибки. Плюс отдельно отмечаем интересные моменты поведения: на чём завис, что искал взглядом, какие шаги дались легко, а какие — нет.
Хорошая практика фиксировать результаты в облачных сервисах, чтобы можно было легко поделиться с командой результатами. Мне нравится шаблон Вани Звягина. Ссылка на шаблон в конце статьи.
Во время теста люди часто предлагают «улучшения»: «Сделайте кнопку побольше», «Добавьте подсказку», «Перекрасьте в синий». Это не то, что нам нужно. Смотрим не на то, что человек говорит, а на то, что он делает. Ответы — в поведении.
На основе этого документа делаем выводы — какие гипотезы подтвердились, какие нет и что нужно переработать. Если по ходу тестов всплывают новые идеи или проблемы, формулируем новые гипотезы и добавляем их в работу.
Это не долго
На этом всё. Может показаться, что тесты занимают достаточно много времени.
Но на самом деле это недолго, чаще всего на это уходит несколько часов до 2х дней, если задействовано много респондентов.
Не забывайте про проверку своих интерфейсов на пользователях и не бойтесь выбрасывать в урну свои идеальные макеты :-)
Полезные ссылки
Собрал пару полезных ссылок с коротким видео как проводить UX-тест от Вани Замесина, шаблон таблицы для фиксирования результатов от Вани Звягина и книга про то, как проводить интервью, главные принципы, поменяет ментальную модель так точно, мастхэв для дизайнеров.
Видео демо UX-теста (8 мин)
Книга «Спроси маму».
Рекомендуем прочитать:
Статья о тестировании умной камеры, не выходя из офиса:
Когда нужен CJM, но на полноценное исследование нет времени, но есть 3 дня до дедлайна:
Большое исследование не столько о том, почему азиатские интерфейсы так сильно различаются от привычных нам, сколько о том, что с этим делать: