Главная/ Блог/

Зачем дизайнеру User Story и как их создавать

Зачем дизайнеру User Story и как их создавать

Рассказываем о пользе User Story для дизайнеров, пользователей и бизнеса. На практических примерах показываем, как их писать и на что обратить внимание при их создании.

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

Основные элементы User Story

User Story описывает, кто является пользователем функции, чего он хочет достичь с ее помощью и зачем она ему нужна.

Структура User story: Как (роль пользователя), я хочу (желаемое действие), чтобы (причина).
  • Кто — пользователь или роль, для которой создается функция. Например, покупатель, менеджер или администратор сайта.
  • Что — конкретное действие или цель, которую клиент хочет достичь.
  • Зачем — причина, по которой эта функция важна для пользователя, то есть выгода или ценность.

Примеры User Stories

  • Как пользователь (Кто), я хочу получать напоминания о тренировках (Чего хочу), чтобы не забывать регулярно заниматься спортом (Зачем).
  • Как клиент банка (Кто), я хочу видеть детализированные отчеты по всем моим транзакциям за месяц (Чего хочу), чтобы тщательно отслеживать свои расходы (Зачем).
  • Как покупатель интернет-магазина (Кто), я хочу иметь возможность фильтровать товары по цене (Чего хочу), чтобы быстрее находить те, которые мне подходят в рамках моего бюджета (Зачем).

Критерии INVEST

Чтобы создавать User Stories, которые работают, стоит сверять их с критериями INVEST.

Эта аббревиатура расшифровывается так:

I — Independent (Независимость): не зависит от других историй.

N — Negotiable (Договороспособность): при необходимости ее можно обсуждать и менять.

V — Valuable (Ценность): приносит конкретную ценность пользователю.

E — Estimable (Оцениваемость): команда может понять ее сложность и сроки выполнения.

S — Small (Небольшой): ее можно запустить в короткий срок.

T — Testable (Тестируемость): имеет конкретные критерии успеха и правильной реализации.

Примеры соответствия INVEST

  • Как пользователь интернет-магазина, я хочу видеть доступные способы оплаты, чтобы выбрать удобный для меня вариант.
  • Как клиент мобильного банка, я хочу получать уведомления о списаниях, чтобы контролировать свои расходы.
  • Как пользователь приложения доставки, я хочу видеть примерное время прибытия курьера, чтобы планировать время.
  • Как клиент онлайн-кинотеатра, я хочу сохранять фильмы в избранное, чтобы быстро находить их позже.

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

Как появляется User Story

В течение жизненного цикла User Stories проходят несколько этапов.

Создание и приоритизация

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

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

Пример: пользователи хотят быстрее искать товары в интернет-магазине. История: добавить фильтр по цене. Оценили: потребуется 3 дня. Решили, что сделают ее в следующем спринте.

Разработка и проверка

Команда создает новое решение и проверяет его корректность.

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

Презентация и запуск

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

Пример: команда продемонстрировала заинтересованным сторонам, как работает сортировка по цене. После одобрения функция становится доступна на сайте для всех покупателей.

Создание User Story по шагам

Рассмотрим поэтапно, как создавать User Story.

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

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

Типичные ошибки при создании User Stories

Общие формулировки

Если история написана слишком размыто, будет сложно понять, что именно требуется.

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

Непонятно, что конкретно нужно сделать. Важно уточнить, какие аспекты удобства важны для пользователя.

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

Отсутствие ценности.

Если история описывает технические задачи, но не отвечает на вопрос «Зачем это нужно пользователю?», ее сложно будет связать с конечной целью.

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

Эта история фокусируется на техническом аспекте, не объясняя, какую пользу это принесет пользователю.

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

Слишком большие истории

Такие истории сложно завершить за короткий промежуток времени. Лучше разбивать их на более мелкие задачи.

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

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

Игнорирование мнения пользователей

История должна учитывать то, насколько пользователям нужна функция.

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

Эта история не учитывает мнения пользователей, и может оказаться, что функция чата им не нужна.

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

Неопределенные критерии успеха

История должна включать четкие показатели для оценки результата.

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

Здесь отсутствует конкретика — непонятно, как часто и на какие категории должны приходить уведомления. Команда не знает, каким должен быть результат.

Лучше уточнить: Как покупатель, я хочу получать уведомления о скидках на интересующие меня категории товаров раз в неделю, чтобы не пропустить выгодные предложения.

____

User Stories — простой способ формулировать задачи в разработке. Примеры показывают, что хорошая User Story включает все необходимые элементы (Кто, Чего хочет и Зачем), отвечает критериям INVEST и, главное, помогает делать продукт удобнее для пользователей.

No items found.
No items found.
Бесплатные учебные материалы,
100% пользы и 0% спама
Вы успешно подписались на рассылку!
Первое письмо уже ждет вас на почте.
Обязательно проверьте папку спам!
Oops! Something went wrong while submitting the form.