Что такое user story? Для чего она нужна? И как “рассказать” правильную историю?

Началось это еще лет эдак 8 назад, когда я учился в институте… Стоял прекрасный солнечный день, солнышко светило в окошко, а настроение приближающегося лета питало мои надежды на скорое завершение учебного дня. Так…стоп, не об этом история, попробуем еще раз.

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

Чтобы понять, как лучше решить ту или иную “боль” вы должны представлять себе сценарий или ситуацию, в которой находится человек с определенной потребностью. Вот тут и появляется история пользователя.

Что такое история пользователя (user story)

User story (или история пользователя) – это метод описания продукта или функциональности через ситуацию из жизни реального пользователя. Простыми словами, ситуация, в которой будущий продукт или функциональность решает задачу конкретной целевой аудитории.

User story это

Изначально данный термин появился в гибких методологиях разработки. Метод ориентирован на конкретную пользу, которую принесет новый продукт или функциональность. Приоритезация задач строится по-принципу от наиболее к наименее полезным доработкам. Таким образом происходит процесс “наращивания полезности”.

Если раньше у вас был сервис, где просто можно было загрузить фото, которое увидят другие, то теперь появится возможность оставлять комментарии. Этот функционал несет дополнительную пользу для вашего основного продукта и самое главное для пользователя. Ведь, согласитесь, неплохо посмотреть фото своих друзей, да еще и комментарий оставить, не так ли?

Какие задачи решает user story

  • описывает потребности пользователя/ей или типа пользователя/ей
  • помогает разбить потребности на конкретные задачи для разработки
  • оценивает ресурсы, которые потребуются на разработку
  • позволяет лучше приоритезировать задачи в общем плане развития продукта (или roadmap)
  • дает возможность другим участникам команды лучше понять контекст задачи
  • является основой для проведения тестирования с реальными пользователями
  • и многое другое

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

Как писать user story

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

Я как <тип пользователя>, хочу <действие>, потому что <причина>

По существу, чтобы заполнить форму, вам необходимо:

  • определить тот тип пользователей, который вас интересует (как правило, это ваша целевая аудитория)
  • понять те действия, которые нужны пользователям
  • выяснить почему именно эти действия нужны

Конечно, user story вы можете сочинить и сами, но вот вопрос, зачем? Так как главная задача метода, это решить самые наболевшие проблемы, то для начала вам необходимо их определить,  а потом уже сформировать user story. Предлагаю небольшую схему того, как должна создаваться история пользователя.

User story процесс создания

Все начинается с исследований, вы изучаете свою целевую аудиторию и пытаетесь вытащить ее потребности. Как правило, это могут быть интервью, опросы, фокус группы и прочее. Очень важно в процессе сбора информации приоритезировать полученные потребности.

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

Давайте перейдем к конкретным примерам и поймем как же это работает.

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

Пример истории пользователя: эмоджи

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

Понимаю, как тяжело это представить…

И вот все бы ничего, да видите вы, что время, которое проводят пользователя а вашей платформе, начинает сокращаться. Если раньше в среднем за день человек проводил у вас час, то сейчас это уже 52 минуты. “В чем дело?”, – подумаете вы. Проведете опрос, поговорите с пользователями, в конце концов спросите совет у друзей и тут станет понятно, что пользователям стало скучно, хочется чего-то новенького.

Вас посещает идея, что неплохо бы удивить их чем-нибудь. Вы формируете историю пользователя:

Я как пользователь социальных сетей, хочу чего-то новенького, так как мне скучно.

Поштурмили немного с командой и придумали эмоджи (смайлы или эмоциональные реакции). Докрутили немного user story:

Я как пользователь социальных сетей, хочу эмоджи, так как мне скучно.

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

Если историй много

Если история пользователя у вас не одна (а это скорее всего так), то вы расставляете приоритеты между ними и берете в работу “самую наболевшую” у пользователей, а после переходите к следующей. Таким образом на первом плане у вас стоит всегда интерес пользователя и каждая следующая функциональность выпущенная в релизе, будет востребована.

История пользователя приоритеты

Все истории пользователи, как правило, помещаются на некие доски (физические или электронные), по которым идет планирование работ. Если говорить про гибкие методологии, то привязка может идти к релизам функционала. Вы сами определяете, какие задачи попадут в ближайший релиз, а какие уйдут в следующий. Вот как приблизительно могут выглядеть доски с историями пользователей.

История пользователя

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

Не забудьте про измерения

Вы приступили к написанию истории пользователя, которая должна решить чью-то “боль”. Но как понять, что “боль” решилась? Наверняка необходимо как-то оценить эффект от того, что вы сделаете? Вопрос: “Как?”. Для этого используйте критерии приемки.

Критерии приемки – показатели, которые будут подтверждать результат ваших трудов.

Вернемся к примеру с эмоджи: если вы считаете, что создание эмоджи, поможет сильнее увлечь пользователей социальной сети, то нужно как-то померить эффект. Мы можем измерить среднее время на сайте за день и посмотреть, увеличится ли оно и на сколько, после того, как мы запустим эти долгожданные смайлы.

Два основных вопроса для критериев приемки:

  • Какие показатели будем измерять, чтобы померить эффект от новой фишки?
  • Какие показатели считать успешными, а какие нет?

Маленький секрет

Будь то разработка на гибких методологиях или же маркетинговое исследование, в результате которого появились истории пользователя, вам обязательно потребуется тесный контакт с реальными пользователями. Команда, которая делает что-то для определенных людей, должна периодически общаться с этими людьми. Узнавайте у своих пользователей, правильно ли вы поняли их боль, делайте customer development и оттачивайте свой функционал до блеска. В противном случае, вы просто один раз снимите данные с пользователей, “запилите” что-то, а в итоге это будет никому не нужно.

Закругляемся

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

Алексей А.


Читайте также:

Кстати, я уже давно веду авторские семинары по управлению IT продуктами, если интересно, посмотреть их можно тут.


Интересный ролик от компании Under Armor, атмосферное и заряженное видео.