Многие привыкли к тому, что юзабилити-тестирование - это долго, дорого и о... очень долго и дорого.
Потому что нужно работающее приложение, нужно искать респондентов и другие 100 причин.
Отчасти это так и поэтому многие проекты тестируют свой продукт на живых людях только раз в n итераций (хорошо, если это число не десятичного порядка).
А можно ли каждый спринт проводить тестирование с пользователями, да еще и успевать вносить изменения до релиза?
В этой короткой речи я поделюсь советами о том, как выстроить процесс проектирования и тестирования на пользователях в течении одного спринта.

Доклад, основанный на реальных событиях, построен в форме рассказа-комикса и повествует о том, в какую ситуацию попадает и с какими трудностями сталкивается закостенелый проектировщик интерфейсов Семен, перейдя в продуктовую agile-команду. Каждый жизненный урок он заносит в свой блокнот, который позже называет «Грабли Семена».

Краткое содержание рассказа.

Проработав долгое время в крупной юзабилити-лаборатории, Семена потянуло на «вольные хлеба». Его друзья запустили несколько стартапов, водили его на различные «тусовки», и Семену так захотелось поучаствовать в каком-нибудь стартапе, что он решил уйти с текущего места работы. Набив портфолио крупными проектами и звучными именами, он отправился на собеседования. Там же от своего будущего менеджера проекта он услышал волшебные и новые для него слова «agile» и «scrum».

Почитав перед выходом на работу «best practises» о том, как нужно внедрять UX в agile-процесс (нулевая итерация, проектирование на несколько итераций вперед и т.д.), он с радостью выходит на работу. Но в первый же день сталкивается с ситуациями, к которым не был готов:
- Сжатые и фиксированные сроки. Спринт длится всего две недели. Первые идеи и наброски нужны уже сегодня, а готовый к реализации вариант (для разработчиков) к концу недели. К следующей среде уже нужен работающий функционал, чтобы QA-команде начать его проверять;
- Утверждение идей. Семен привык показывать результат своей работы только когда практически все готово (а это всегда занимает много времени);
- Описание поведения функционала. Семен привык описывать все возможные мелочи в поведении продукта (т.к. дьявол кроется в деталях), но для команды «Работающий продукт важнее исчерпывающей документации». Как теперь фиксировать и передавать требования о поведении продукта разработчикам, тестировщикам, маркетологам?;
- Командное взаимодействие. Разработчикам нужен готовый макет с итоговым дизайном. Дизайнеру нужны мокапы с утвержденными текстами от маркетологов. Но маркетологи не понимают грубых мокапов, им нужны объяснения «что, где, когда».… Какой-то замкнутый круг;
- Юзабилити-тестирование. Где найти время на него и когда исправлять ошибки?