В этой статье узнаете, как сфокусироваться на пользователе и создать продукт, который ему действительно нужен.
Представьте себе ситуацию: вы запускаете новый проект. Пусть это будет мобильное приложение, в котором пользователи смогут заказывать доставку продуктов из супермаркетов. Идей много: хочется и фильтрацию товаров сделать, и рекомендации, и push-уведомления о скидках, и возможность отслеживать курьера на карте, и чат с поддержкой, и много чего ещё. Вы садитесь с командой, начинаете обсуждать, какие функции реализовать сначала, какие потом. И тут вы вдруг понимаете, что мнения расходятся, а главное — нет никакой чёткости, кому это вообще нужно и почему?
Вот в такие моменты User Story и является тем инструментом, который помогает не утонуть в болоте идей и абстрактных требований. User Story — это своего рода маленькая история о том, чего хочет добиться реальный человек (пользователь) от вашего продукта. Не программист, не маркетолог, не владелец бизнеса, а именно пользователь — тот, ради кого вся эта работа вообще затевается.
Что такое User Story?
User Story (пользовательская история) — это короткое описание того, какую задачу пользователь хочет решить с помощью продукта и какую ценность он при этом получает. Можно сказать, это небольшая заметка о том, что человек будет делать в вашем приложении или сервисе, и почему для него это важно.
Классический шаблон User Story звучит так:
«Как [роль/тип пользователя], я хочу [действие/функция], чтобы [ценность/результат].»
Например:
«Как покупатель, я хочу фильтровать товары по цене, чтобы быстрее найти подходящие варианты и не тратить время на лишний просмотр.»
В этой короткой фразе есть всё, что нужно:
- Кто: покупатель (то есть мы представляем конкретного человека, который будет использовать продукт).
- Что: фильтровать товары по цене (это действие, которое пользователь хочет сделать).
- Зачем: чтобы быстрее найти нужный товар (вот она ценность, здесь становится понятно, что пользователь экономит время и усилия).
Зачем нужны User Story?
Когда мы начинаем работу над продуктом, у нас, как правило, есть огромный список возможных функций. Без User Story этот список превращается в гору технических требований. Вроде бы понятно, что надо сделать «фильтр по цене», «поиск по названию», «сортировку по популярности», но вот почему это важно, кто этим будет пользоваться и зачем — всё это остаётся невыраженным. Как следствие, команде сложно понять приоритеты, а конечный результат может получиться не таким полезным, каким мог бы быть.
User Story помогает «приземлить» каждую фичу:
- Она связывает требования с конкретной пользовательской потребностью.
- Помогает команде мыслить не категориями «программа должна делать то-то», а категориями «пользователь хочет решить такую-то задачу».
- Даёт всем участникам проекта общее понимание, ради кого и чего они работают.
Благодаря этому, разработчики могут сосредоточиться на решении реальных проблем людей, а не на выполнении абстрактных пунктов из бесконечных спецификаций. Менеджерам становится проще расставить приоритеты, ведь можно задать вопрос: «Окей, у нас есть 10 идей. Какая из них даёт самую большую ценность пользователю?».
Как правильно писать User Story?
Вроде бы всё просто: есть шаблон, вставляй слова и готово. Но на практике встречается много «подводных камней». Чтобы User Story реально помогала, нужно учесть несколько моментов.
1. Определить роль пользователя:
Кто именно ваш пользователь? Покупатель? Зарегистрированный клиент? Гость, который просто зашёл на сайт? Автор контента, который будет писать статьи? Администратор, который будет управлять чем-то?
Чем точнее вы поймёте, для кого эта история, тем лучше. Просто «пользователь» — это слишком расплывчато.
Пример:
«Как зарегистрированный покупатель, я хочу видеть историю моих предыдущих заказов, чтобы при повторном заказе не искать товар заново.»
2. Чётко описать действие:
Что конкретно делает человек в продукте? Фильтрует товары, ищет по ключевому слову, добавляет товар в корзину, редактирует описание, заказывает доставку, создаёт заметку, и так далее. Главное — это должно быть понятное, конкретное действие.
Пример:
«Как читатель новостного портала, я хочу сортировать статьи по дате, чтобы видеть самые свежие новости.»
3. Выделить ценность:
Зачем это нужно? В чём пользу для человека? Ценность — ключевой элемент User Story, отличающий её от простого требования. Без ценности вы просто добавляете функцию ради функции.
Пример:
«Как покупатель, я хочу получить уведомление о скидках на товары в моей корзине, чтобы не пропустить выгодную цену и сэкономить деньги.»
В итоговом варианте User Story получается короткой, но информативной. Это не длинный документ, это скорее напоминание для команды о том, что мы делаем и ради кого.
Примеры хороших User Story
- «Как водитель, я хочу получать уведомление о заторах на маршруте, чтобы вовремя выбрать объездной путь и сэкономить время.»
Здесь сразу понятно: водитель (роль), уведомление о заторах (действие/функция), ценность — экономия времени. - «Как зарегистрированный пользователь интернет-банка, я хочу видеть детальную выписку по транзакциям за последние 3 месяца, чтобы контролировать свои расходы и не выходить за рамки бюджета.»
Ясно, что это за пользователь, что он хочет (выписку по транзакциям) и зачем (контроль расходов). - «Как продавец на онлайн-маркете, я хочу получать статистику по продажам, чтобы понимать, какие товары продаются лучше всего и планировать ассортимент.»
Ценность в понимании ассортимента и оптимизации продаж.
Примеры плохих User Story (и как их исправить)
1. Плохо: «Добавить фильтр по цене.»
Что не так: непонятно, кто это будет использовать и зачем.
Что можно сделать: «Как покупатель, я хочу фильтровать товары по цене, чтобы быстрее найти подходящие варианты и не просматривать ненужный ассортимент.»
2. Плохо: «Как пользователь, я хочу все возможности, чтобы было круто.»
Что не так: слишком общее, непонятно, какие возможности и в чём ценность.
Что можно сделать: вместо этого лучше сделать несколько конкретных историй. Например:
- «Как читатель, я хочу сортировать статьи по популярности, чтобы видеть, что чаще всего читают другие.»
- «Как покупатель, я хочу искать товары по названию, чтобы не тратить время на просмотр категорий.»
3. Плохо: «Как админ, я хочу иметь полный контроль над системой, чтобы всё было хорошо.»
Что не так: «полный контроль» — это слишком широкое понятие, непонятно, что именно нужно.
Что можно сделать: разбейте на отдельные истории:
- «Как администратор, я хочу просматривать список новых пользователей, чтобы отслеживать рост аудитории.»
- «Как администратор, я хочу иметь возможность блокировать пользователей, нарушающих правила, чтобы поддерживать порядок в системе.»
Критерии качества для User Story
Есть несколько принципов, которые помогают понять, что ваша история действительно хороша. Одни из самых популярных критериев объединены в аббревиатуре INVEST:
- Independent (независимая): историю можно реализовать отдельно от других, по возможности.
- Negotiable (обсуждаемая): это не высеченный в камне документ, а основа для диалога и уточнений.
- Valuable (ценная): она должна приносить ценность пользователю. Без ценности — какая в ней нужда?
- Estimable (оцениваемая): вы должны примерно понимать, сколько усилий и времени потребуется на реализацию. Если непонятно, история слишком размыта.
- Small (небольшая): не делайте историю гигантской. Лучше разбить на несколько маленьких, понятных историй.
- Testable (тестируемая): должно быть ясно, как проверить, что история выполнена корректно.
Например, если вы берёте историю «Как покупатель, я хочу сортировать товары по рейтингу, чтобы видеть самые популярные», её легко проверить: сортировка либо работает правильно, либо нет. А если история звучит как «Я хочу, чтобы всё было классно», то её и протестировать невозможно.
Как User Story помогает в работе команды
Когда все требования к продукту описаны в виде User Story, команда начинает говорить на одном языке. Не на сухом техническом диалекте, не на маркетинговом жаргоне, а на понятном, человеческом языке целей и задач пользователей.
Представьте себе, как проходит планирование спринта в Agile-команде, где все задачи — User Story.
- «Сегодня мы возьмём в работу историю о сортировке товаров по цене, чтобы покупатели быстрее находили нужные им товары. Это важно, потому что сейчас они жалуются на неудобный поиск.»
- «Да, согласны. А ещё возьмём историю о просмотре предыдущих заказов, чтобы зарегистрированные пользователи могли повторить покупку без лишних движений.»
В такой атмосфере все понимают, ради чего делается каждая задача. Когда разработчики сомневаются, они задают вопросы не в стиле «какие поля в таблицу добавить?», а «пользователю нужно увидеть последние заказы за какой период?». Коммуникация становится осмысленной, связанной с реальными нуждами.
Менеджеры, глядя на список User Story, могут приоритизировать их: «Сначала сделаем те истории, которые решают наиболее болезненные проблемы пользователя или приносят наибольшую ценность, а уже потом — второстепенные улучшения.»
User Story и ТЗ
Иногда в команде задаются вопросом: а ведь User Story — это очень общая формулировка. Как нам понять технические подробности, когда мы приступим к разработке?
Ответ прост: User Story — это отправная точка. Она не отменяет детализации, макетов, критериев приёмки и технических заданий. Но благодаря User Story вы сначала фокусируетесь на сути — кто, что, зачем. А уже потом, когда команда договаривается, что действительно стоит делать, вы добавляете подробности: может быть, в отдельном документе, может быть, устно на встрече, может быть, в виде критериев приёмки (Acceptance Criteria) прямо в карточке задачи.
Главное — не начинать с глубокой технической спецификации. Сначала поймите суть ценности для пользователя. Если вы видите, что, к примеру, для фильтрации по цене вам нужны дополнительные поля в базе данных, алгоритмы сортировки, то добавьте это как уточнение. Но не надо превращать User Story в технический мануал.
User Story тесно связаны с Agile-философией (Scrum, Kanban и т.д.). В Agile принято разбивать разработку на короткие циклы (спринты), выпускать продукт постепенно и улучшать его на основе обратной связи пользователей. User Story прекрасно вписываются в этот подход, потому что они ориентированы на реальных людей и их потребности.
Когда вы формируете бэклог продукта (список всего, что вы хотите сделать), вы часто будете использовать User Story. Это упрощает планирование и оценку задач, помогает команде быстрее понимать, что нужно сделать в первую очередь, а что может подождать.
Ошибки при работе с User Story
Несмотря на всю простоту концепции, начинающие команды часто допускают ошибки.
- Слишком технические истории:
«Как разработчик, я хочу добавить колонку в таблицу, чтобы система работала.» Это не User Story. Это техническая задача. Пользователь не знает и не хочет знать про колонки в таблице. Если без этого шага нельзя реализовать важную для пользователя историю — укажите его отдельно или сделайте внутреннюю задачу для команды. - Слишком общие и длинные истории:
Если ваша User Story звучит как «Как пользователь, я хочу иметь идеальную систему для всех возможных сценариев, чтобы всегда быть счастливым» — вы ничего не поймёте из этого. Разбейте историю на несколько конкретных шагов. Нужно понимать, что конкретно пользователь хочет сделать, а не «всё и сразу». - Отсутствие ценности:
«Как пользователь, я хочу нажать на кнопку, чтобы нажать на кнопку.» Это бессмысленно. Если нет ценности, история не нужна. Спросите себя: в чём польза для человека?
Резюме по User Story
User Story — это не просто формальный инструмент. Это, по сути, способ думать о продукте с точки зрения людей, которым он нужен. Без User Story вы рискуете скатиться в сухую технику, в которой теряется главное — смысл.
Переходя к формату User Story, вы:
- Ставите в центр внимания человека и его задачи.
- Получаете доступный “язык” для коммуникации в команде.
- Легче выделяете приоритеты.
- Готовите почву для дальнейшей детализации и уточнений, но уже понимая, ради чего они нужны.
В конечном итоге, User Story упрощают жизнь всей команде: от менеджеров до разработчиков, от аналитиков до тестировщиков. Все смотрят на задачу через призму «для кого и зачем?», а не просто выполняют очередной пункт без понимания ценности. Это помогает создавать продукты, которыми люди хотят пользоваться, а не те, что просто соответствуют «списку функций».
User Story Mapping: формируем видение продукта
Представьте, что вы составили длинный перечень пользовательских историй для вашего приложения. Вы знаете, что покупатель хочет фильтровать товары, просматривать отзывы, сохранять корзину, видеть историю заказов и ещё кучу всего. Здорово, что у вас есть такой набор осмысленных историй.
Но теперь другой вызов: как из этих отдельных кусочков сложить целостное представление о продукте? Как понять, какой у пользователя будет маршрут, в каком порядке он пользуется функциями и что является основным скелетом продукта, а что — дополнительными «украшениями»?
Именно для этого и используется user story mapping.
Это метод визуализации вашего продукта в виде карты, на которой истории раскладываются не просто списком, а в соответствии с последовательностью действий пользователя и приоритетами. Если user story — это кирпичики, то user story mapping — это план того, как эти кирпичики сложить в удобное здание.
Что такое User Story Mapping?
User story mapping — это способ упорядочить user stories в виде карты, отражающей путь пользователя от начала и до достижения цели в вашем продукте.
Представьте, что вы чертите горизонтальную линию (или, лучше сказать, «хребет»), на которой отмечаете ключевые шаги пользовательского сценария. Под каждым шагом вы раскладываете соответствующие user stories — те функции и возможности, которые позволяют пользователю успешно пройти этот этап.
В итоге получается что-то вроде карты, где сверху вниз можно видеть слои приоритетов (самое важное — в верхней части, дополнительные и менее критичные вещи — ниже), а слева направо — ключевые шаги, которые пользователь совершает последовательно.
Таким образом, user story mapping помогает ответить на вопросы:
- Как выглядит путь пользователя?
- Какие шаги являются основными для достижения цели?
- Какие истории критичны для минимального работающего продукта (MVP), а какие можно добавить позже?
Зачем это?
Есть несколько причин, почему команды прибегают к user story mapping, вместо того чтобы просто хранить все истории списком:
- Целостное понимание продукта:
Вместо того чтобы иметь набор разрозненных историй, вы видите общую картину. Каждая история вписана в более широкий контекст пользовательского пути. Это помогает избежать ситуации, когда команда делает много мелких фич, но упускает важный шаг, без которого пользователь не достигнет цели. - Определение приоритетов и MVP:
Когда вы видите карту целиком, вы легко выделяете тот минимальный набор историй, который надо реализовать в первую очередь, чтобы продукт уже начал приносить пользу. Этот верхний слой и есть ваш минимум жизнеспособного продукта (MVP). Всё остальное можно оставить «на потом» и постепенно добавлять по мере необходимости. - Легче объяснить продукт команде и стейкхолдерам:
Карта понятна и визуальна. Она проще для восприятия, чем простыня текстовых требований. Покажите карту инвестору или новому члену команды, и он быстро поймёт, как устроен пользовательский сценарий и что на самом деле важно. - Упрощение планирования и адаптации:
Добавляя или меняя местами истории на карте, вы оперативно реагируете на новые идеи, изменения в бизнес-стратегии или обратную связь от реальных пользователей. Карта гибка и поддаётся модификации без боли.
Как построить User Story Map?
Давайте разберём пошагово:
- Определите Backbone (основной сценарий продукта):
Начните с попытки описать сценарий использования продукта. Если у вас интернет-магазин, это может быть цепочка шагов: «Поиск товара» → «Просмотр деталей» → «Добавление в корзину» → «Оплата» → «Подтверждение заказа». Для приложения по доставке еды: «Выбор ресторана» → «Поиск блюда» → «Добавление в корзину» → «Оплата» → «Отслеживание заказа».
Этот сценарий размещается горизонтально. Это и есть ваш каркас. - Раскладка user stories под каждым шагом:
Теперь под каждым шагом вы начинаете вывешивать user stories, которые относятся к этому этапу. Например, под «Поиск товара» могут быть истории вроде:
- «Как покупатель, я хочу фильтровать товары по цене, чтобы не тратить время на ненужные варианты.»
- «Как покупатель, я хочу искать товары по названию, чтобы быстро находить конкретный продукт.»
- «Как покупатель, я хочу просматривать категории, чтобы ориентироваться в ассортименте.»
И так под каждый шаг раскладываете соответствующие истории.
3. Приоритизация по вертикали:
Когда все истории разложены, вы упорядочиваете их по важности сверху вниз. Самые критичные для начального продукта идут наверх. Менее важные — вниз. Верхняя «строка» историй под каждым шагом образует тот набор, который нужен, чтобы продукт заработал и давал ценность пользователю с самого начала. Это и будет ваш MVP.
4. Оценка целостности и полноты:
Когда у вас есть карта, сделайте шаг назад и посмотрите на неё целиком. Видите ли вы связный путь? Есть ли критические пробелы? Может быть, какой-то шаг без историй, или наоборот, слишком много историй на каком-то этапе, а на другом — пусто? Обсуждайте это с командой.
5. Уточнение и адаптация:
User story map — живой инструмент. По мере того, как вы получаете обратную связь от пользователей, узнаёте новые детали или меняются приоритеты бизнеса, вы можете корректировать карту, перемещать истории, удалять одни и добавлять другие. Эта гибкость — ключевое преимущество.
Пример
Допустим, вы делаете приложение для заказа такси.
Backbone (сценарий):
- Открыть приложение
- Выбрать точку отправления
- Выбрать точку назначения
- Выбрать тип такси (эконом, комфорт, бизнес)
- Подтвердить заказ
- Отслеживать машину
- Оплатить поездку
Под «Выбрать точку отправления» вы разложите истории:
- «Как пассажир, я хочу автоматически определять свою геопозицию, чтобы не вводить адрес вручную.»
- «Как пассажир, я хочу выбирать адрес из списка недавних мест, чтобы быстрее начать заказ.»
- «Как пассажир, я хочу вводить адрес вручную, чтобы уточнить место, если геопозиция неточна.»
Далее вы приоритизируете: возможно, автоопределение геопозиции — критичная функция для старта, а выбор из списка недавних мест можно добавить позже.
Смотрим всю карту: есть основные шаги, есть набор историй под каждым шагом. Сверху — то, без чего приложение не имеет смысла (например, определение геопозиции и возможность ввести адрес). Ниже — дополнительные улучшения (история недавних мест).
Ошибки в User Story Mapping
- Смешивание разных ролей и сценариев в один поток:
Допустим, у вас есть роли «покупатель» и «администратор». Не стоит сливать их истории в одну карту. Лучше сделать две карты или чётко разделить сценарии. Иначе вы получите хаос и потеряете стройную логику пользовательского пути. - Отсутствие приоритизации:
Если вы просто свалили все истории в кучу под каждым шагом, не расставив по важности, вы не получите преимущество user story mapping. Главный смысл — понять, что надо сделать в первую очередь, а что подождёт. - Слишком детализированные технические истории:
User story mapping — это всё же инструмент для понимания ценности и пользовательского пути. Оставьте детали о том, как именно реализовать фильтр или интеграцию с платежной системой, для других артефактов. На карте вы должны фокусироваться на пользовательских действиях и ценности. - Путаница в основном сценарии:
Backbone должен отражать ключевой сценарий достижения цели пользователем. Если вы намешаете туда несвязанные шаги, карта станет непонятной. Тщательно определите главный маршрут, по которому идёт пользователь, и разложите истории под ним.
User Story Mapping - процессный инструмент
Один из главных плюсов user story mapping в том, что это не разовая процедура. Это живой документ (а точнее, визуальная модель), к которому вы будете возвращаться по мере развития продукта.
- Запустили первую версию продукта с минимальным набором историй? Отлично. Посмотрите на карту: какие дополнительные функции теперь кажутся важными, а какие нет. Возможно, вы получили обратную связь от реальных пользователей, и стало ясно, что фильтр по цене нужен не так срочно, зато очень важна возможность сортировки по рейтингу.
- Команда меняется или появляются новые участники? Показать им карту — быстрый способ ввести людей в курс дела. Они увидят логику продукта, а не просто длинный backlog.
- Бизнес-приоритеты меняются? Возвращайтесь к карте, меняйте местами истории, убирайте те, что потеряли актуальность, и добавляйте новые. Гибкость карты позволяет быстро подстраиваться под новые реалии.
User story mapping также чудесно вписывается в agile-подходы, такие как Scrum или Kanban. В Scrum вы можете использовать карту для формирования бэклога спринтов, выделяя верхние истории для ближайшей работы. В Kanban вы можете браться за самые верхние (приоритетные) истории из карты по мере появления свободных ресурсов.
Карты хорошо работают и на этапе discovery (когда вы только исследуете идею продукта), и на этапе delivery (когда вы уже пилите фичи для следующих релизов). Это универсальный инструмент, который помогает оставаться сфокусированными на нуждах пользователя, а не тонуть в технической рутине.
- Часто user story mapping делают физически: берут большую доску, фломастеры и стикеры. У каждого шага — своя колонка, под ней стикеры-истории. Так всё видно сразу. Если команда распределённая, можно использовать онлайн-инструменты (Miro, FigJam, Mural), которые позволяют делать то же самое виртуально.
- Не бойтесь переформулировать историю или перемещать её между шагами. Это не статичный документ. Важна сама концепция видимости пути пользователя.
- Если у вас сложный продукт с несколькими большими пользовательскими сценариями, можно сделать несколько карт — по одной на каждый ключевой сценарий. Не пытайтесь втиснуть всё в одну карту, если это ухудшает понятность.
User story mapping — это ещё один инструмент в арсенале команд, которые хотят создавать продукты, востребованные людьми. Если user story помогают понять, для кого и зачем вы делаете фичу, то user story mapping помогает увидеть всю картину целиком: путь пользователя, приоритеты, MVP и план развития продукта по шагам.
Используя user story mapping, вы сможете:
- Быстрее вычленять действительно важные функции и определять MVP.
- Легко визуализировать и объяснить продукт, как команде, так и стейкхолдерам.
- Гибко реагировать на изменения и новые требования, не теряя понимания общей логики.
- Создавать действительно удобные и полезные продукты, в которых пользователь не потеряется, а плавно пройдёт от первого шага до достижения своей цели.
Еще больше контента в сфере IT - в нашем ТГ-канале:
t.me/openstudyit