Проблема
Мы много времени тратим на обсуждение второстепенных элементов интерфейса, обсуждение внешнего вида, клиент аргументирует свои пожелания на основании личного опыта.
Решение
Data-Driven Design — это проектирование продукта на основе данных: исследований, тестов, проверки гипотез.
Выгода клиенту
- Больше никаких действий наугад в ущерб бюджету проекта.
- Отказ от философии «Мы ничего не можем гарантировать. Давайте попробуем, как дизайнер предложил, а там посмотрим», не соответствущей интересам бизнеса.
- Обоснованный дизайн вместо интуитивного.
Выгода нам
- Меньше необоснованных правок, исключение вкусовщины. Совместные усилия концентрируются на том, чтобы построить лучший сервис.
- Каждое решение обосновано данными, а значит, нет нужды отстаивать позицию агентства.
Далее я поясняю как организовывать процесс тестирования, если нужно больше информации про DDD, аналитику, метрики, то с удовольствием расскажу.
Ключевые этапы тестирования
- Правильно сформулировать задания
- Обозначить критерии успешности/ошибок
- Подготовить список дополнительных вопросов
- Перенести всё в протокол для теста (чтобы вести заметки)
Постановка вопроса
Неправильно:
Как создать продукт?
Правильно:
Ты системный администратор интернет-магазина. Вы переезжаете на новую площадку и тебе необходимо подготовить облачный сервер. Ты зарегистрировался в системе и готов к работе. Теперь, пожалуйста, создай и настрой новый продукт "Виртуальный сервер".
Всегда необходимо пояснять контекст тестирования. Обязательно необходимо заранее ответить на вопросы испытуемого "Кто я?" и "Что я здесь делаю?".
У пользователя всегда будет какой-то бэкграунд: уже знаком с интерфейсом, знаком с подобными сервисами, много провдит времени в интернете, читал как работают подобные штуки.
Показатели
- Эффективность (выполнил/не выполнил)
- Продуктивность (время)
- Удовлетовренность (шкала Альберта и Диксона)
- Эмоциональный комфорт (System Usability Scale)
- Другие маркетинговые методы по оценке удовлетворенности (например, семантический дифференциал)
Показателей может быть много, но нам надо начать хотя бы с первых трёх.
Эффективность и продуктивность — это понятно. Как оценивать удовлетворенность: после озвучивания задания (до выполнения), необходимо попросить юзера оценить предполагаемую сложность задания от 1 до 5 (1 очень легко, 5 очень сложно). После выполнения задания необходимо снова попросить оценить насколько сложно было. Если вначале было 5, а потом 2, значит интерфейс был хороший и юзеру казалось, что задания будет сложное, а выолнил его он достаточно легко.
Дополнительные вопросы
Они могут быть разными, но надо их заранее составить:
- Что понравилось, что не понравилось?
- Что бы вы улучшили?
- И т.д.
Протокол
Для каждого тестируемого нужно завести лист, в который будут заноситься все данные: его показатели, ответы на вопросы, заметки по ходу тестирования...
Как себя вести с испытуемым
- Надо ему обязательно сказать, что тестируют не его, а интерфейс. Это расслабляет человека, он не чувствует себя подопытной крысой.
- Нельзя подсказывать. Но можно задавать наводящие вопросы.
- Нельзя спорить. Если испытуемый говорит что-то неадекватное, просит перекрасить весь интерфейс и подчеркнуть все ссылки, нужно выслушать и записать.
- Нельзя перебивать.
Что взять с собой
- Ноутбук с интерфейсом
- Секундомер
- Блокнот
- Видео, аудиозапись.
- Помощника
Дополнительно
- Нет нужды проверять каждый чих. Давно известно, что подписанные иконки, лучше не подписанных, а подписи без иконок еще лучше. (кроме самых однозначных, типа иконки геопозиции или профиля)
- Также можно погуглить проверки каких-то гепотез, чтобы не тратить на это время. Например, давно проверено удобство нижней навигации на смартфонах. (это я показывал вам с Игорем, когда мы еще работали над GoOcean)
