{"id":13508,"url":"\/distributions\/13508\/click?bit=1&hash=84881d55bbad8a9fea0858220d4fa15ea06fdd4fceb0218db01a425f0cc754d2","title":"\u041a\u0430\u043a \u0441\u043d\u044f\u0442\u044c \u0440\u043e\u043b\u0438\u043a \u0441 \u0440\u0430\u0431\u043e\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u0447\u0442\u043e\u0431\u044b \u0431\u044b\u043b\u043e \u043d\u0435 \u0441\u0442\u044b\u0434\u043d\u043e","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}
Дизайн
Anton Stupnev

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

Зачем тестировать дизайн на реальных людях?

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

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

  1. Эвристика юзабилити (подробнее читайте здесь). Метод, когда дизайнер сам оценивает интерфейс на соответствие принципам удобства использования («эвристика»). Но в этом случае результаты нельзя назвать объективными, потому как данные исходят от одного человека.
  2. Проверка юзабилити на коллегах и друзьях — об этом мы как раз и поговорим.

Шаг 1. Выберите часть функционала, которую будете тестировать

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

Шаг 2. Создайте прототип для тестирования.

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

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

Шаг 3. Найдите тех, кто опробует ваш дизайн

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

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

Шаг 4. Правильно сформулируйте задачу

Шаг 5. Проведите ваш тест или исследование

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

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

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

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

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

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

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

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

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

Шаг 6. Обработайте результаты

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

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

  1. Сложности — обозначают места, где пользователь не понимал, как работает приложение.

  2. Вопросы — указывают места, где пользователю было недостаточно информации.
  3. Одобрения — показывают места, которые действительно хорошо сработали для пользователя.
  4. Факты — информация, которую вы получили от пользователя во время исследования.

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

Шаг 7. Исправьте ошибки

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

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

Буду рад вашим комментариям и письмам на [email protected]

0
2 комментария
Game Topia

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

Ответить
Развернуть ветку
Anton Stupnev
Автор

Это перевод статьи из блога Humbleteam, полную версию на английском языке вы можете прочитать здесь https://www.humbleteam.com/secrets/0-usability-testing-guide-in-7-steps

Ответить
Развернуть ветку
Читать все 2 комментария
null