Пользовательские истории, то есть краткие описания того, кто, что и зачем делает на сайте, помогают сделать проект полезным и удобным для людей. Главное, правильно их использовать и не создавать «для галочки». На какие особенности работы с User Story стоит обратить внимание заказчикам сайтов, расскажем в статье.
Не «Как?», а «Что?»
Мы уже рассказывали о создании User Story в этой статье: https://m.promoteh.ru/articles/_aview_b536 Поэтому здесь вкратце напомним, что история включает в себя ответы на три вопроса:
- Кто пользователь (покупатель, администратор интернет-магазина, читатель и т.д.)?
- Что ему нужно (найти товар под свои требования, удалять спам, быстро помогать покупателям и т.д.)?
- Зачем это нужно (заказать новую футболку в обеденный перерыв, обслуживать больше покупателей, не пускать в комментарии троллей и рекламщиков и т.д.)?
И видно, что здесь нет вопросов о том, как именно это будет реализовано. То есть нет ни слова про дизайн, программное обеспечение, расположение кнопок и прочие подробности.
Суть создания User Story – описание задачи, которую нужно решить пользователю сайта. Обратите внимание: именно пользователю, а не дизайнеру или программисту. Специалисты найдут решение для задачи, но для начала нужно сформулировать ее с точки зрения реальных посетителей сайта или пользователей приложения.
Разумная детализация
User Story – это не техническое задание. Тем не менее, здесь важно уточнить такие детали:
- Роли и портреты пользователей. Например, товары предлагаются оптом и в розницу. Очевидно, что стоит выделить такие категории покупателей и описать их намерения по отдельности. Также свои задачи будут у консультантов, администраторов сайта, бухгалтеров, отвечающих за товарный учет. Значит, для каждой категории нужно создавать свои истории. Желательно, с учетом специфики целевой аудитории, ее привычек и степени знакомства с интернетом.
- Сценарии пользователей. Это уточнение порядка действий для получения желаемого. Например, отфильтровать товары по заданным критериям для удобства выбора, оформить покупку без регистрации или использовать личный кабинет для быстрых повторных заказов. В зависимости от назначения сайта или приложения, стоит уточнять способы и условия взаимодействия (на ходу, в спокойной обстановке, с компьютера, со смартфона).
- Намерения и ожидания. Вернемся к примеру с оптом и розницей. В первом случае заказчик будет ожидать отдельных условий для оптовиков и форму заявки. Во втором для покупателя важно оформить заказ так же просто, как и в любом другом интернет-магазине. Следовательно, сценарий дополняется просмотром цен и созданием формы заявки, удобной для предварительной оценки заказа на стороне магазина.
При этом, как уже говорилось, технические детали не нужны. Важно описание, исключающее двойные трактовки и достаточное для понимания разработчиками.
Технические детали – специалистам
Еще раз акцентируем на этом внимание, потому что один из этапов работы с User Story – обсуждение историй с разработчиками и дизайнерами. Здесь важны такие нюансы:
- общий язык – нужно исключить двойные трактовки используемых терминов и точно обговорить, кто есть кто в предложенных историях;
- особенности реализации – во время обсуждения специалисты могут задать уточняющие вопросы, ответы на которые способны изменить, дополнить, объединить или раздробить готовые истории;
- приоритеты – специалисты оценят сложность внедрения нужных функций и помогут составить план действий по их постепенному добавлению.
К примеру, при первичной разработке историй пользователей картографического приложения не была учтена скорость изменения карты для передвигающегося человека. Или оптовая закупка предполагалась одномоментным действием. Это очевидные недочеты, но могут быть и более сложные непроработанные сценарии. Поэтому так важен диалог – специалисты, знающие, что и как работает, укажут на то, что может просто не прийти в голову заказчику сайта.
Тестирование и приемка
Еще один важный нюанс – истории, точнее результат их использования при разработке, должны быть оцениваемыми. То есть нужно каким-то способом убедиться, что внедренные функции действительно полезны.
Для этого на этапе создания и обсуждения историй нужно обсудить, что считается достигнутым результатом. Если с добавлением каких-либо форм все более-менее ясно, то оценка других функций может быть не столь очевидной.
Важно сформулировать цели пользователей в каждой истории и смотреть, достижимы ли они в итоге. Грубо говоря, если кнопка просто «висит» на странице, вероятно, она и не нужна. Чтобы избежать таких ситуаций, нужно создавать истории про пользователей, а не «чтобы было». Иначе время и, конечно, деньги, будут потрачены напрасно.
Соответствие общей цели
Наконец, создавая, детализируя и уточняя User Story, нельзя забывать о назначении самого сайта или приложения. В противном случае легко увлечься деталями и потерять основное.
В заключение
User Story – полезный инструмент для проработки пользовательских сценариев поведения на сайте и для продуктивного общения с техническими специалистами. Но они не обязательны, если функциональность сайта проста и совпадает со множеством подобных ресурсов. И, конечно, не способны заменить полноценное техническое задание. Поэтому прежде чем увлекаться созданием историй, стоит подумать, не будет ли достаточно обычного понимания целевой аудитории и целей разработки сайта.
