Тестируем дизайн за 7 шагов и $0

Хороший дизайн — это не про красивые картинки, а про решение потребностей бизнеса. И единственный способ понять, насколько вам удалось достичь цели — запустить дизайн в работу, то есть протестировать. Полноценное юзабилити-тестирование, фокус-группы или дизайн-спринты — всё это дорого и может требовать вовлечения всей команды. Что же тогда остается?

Есть два бесплатных способа тестирования

Начните проверку с небольшой и простой части вашего продукта, иначе тест займет много времени, а мотивация тестировщиков снизится.

Для этого вполне подойдёт Фигма, но есть и другие инструменты.

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

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

На менее специализированные вещи, вроде сайнапа или смены пароля, можно звать почти кого угодно.

a) В случае трудностей, постарайтесь не давать никаких подсказок тестировщикам и не влиять на их решение

Если ваш тестировщик застрял или думает слишком долго — спросите, о чем он думает, но никогда не предлагайте ему готовый следующий шаг, иначе результат будет необъективным.

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

b) Не задавайте наводящих вопросов или вопросов, на которые можно ответить «да» или «нет».

c) Сдерживайте жалобы пользователей, если они выходят из-под контроля

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

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

d) Никогда не пытайтесь решать проблемы во время тестирования.

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

Как говорит Ким Гудвин, ориентироваться на первичные данные тестирования — то же самое, что съесть пирог перед тем, как его запечь.

Разделите эти типы данных и сгруппируйте следующим образом:

Отсортируйте их по частоте возникновения, начиная с наиболее часто встречающихся.

По возможности, начните с самых простых, но тех, что способны принести максимум результата.

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

Буду рад вашим комментариям и письмам на anton@humbleteam.com