User Story [пользовательские истории] — это, пожалуй, самая популярная техника для определения рамок функциональности продукта. Работать с историями легко. Но рассказать хорошую историю может быть сложно. Эти 10 советов помогут вам создавать хорошие истории.

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

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

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

Пользовательские истории — это простая методика, которая позволяет двигаться быстро. Это не спецификация, а скорее инструмент совместной работы. Истории никогда не должны отдаваться на откуп команде разработчиков. Напротив, они должны рождаться в процессе обсуждения: Менеджер по продукту (The Product Owner) и команда должны обсуждать истории вместе. Это позволяет фиксировать минимальную необходимую информацию, уменьшать издержки и ускорять процесс.

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

Если вовлечь команду разработки нельзя, подумайте над использованием другой техники для определения функциональности продукта — Use Cases (кейсы использования продукта).

Пишите истории, которые легко понять. Составляйте их простыми и краткими. Избегайте сбивающих с толку и двусмысленных понятий, используйте действительный залог. Фокусируйтесь на том, что важно и убирайте все остальное. Шаблон ниже превращает пользователя или покупателя в персонажа истории и позволяет объяснить его выгоды. Он основан на популярном шаблоне Рейчел Дейви, но я заменил «роль пользователя» на «имя персонажа», чтобы связать историю с релевантным персонажем.

Как <персонаж>,
Я хочу <что?>,
Для того, чтобы <зачем>.

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

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

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

Делите ваши поэмы на более мелкие, детализированные истории, пока они не будут готовы: пока не станут ясными, выполнимыми и измеримыми. Вся команда разработки должна понимать значение истории. История не должна быть слишком большой, должна комфортно помещаться в спринт, должен быть эффективный способ определить и проверить критерий успешного выполнения истории.

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

Пользовательские истории возникли из Экстремального Программирования. А в Экстремальном Программировании говориться о «пользовательских карточках», а не об «историях». Тому есть простая причина: пользовательские истории записывались на бумажных карточках. У этого подхода есть три преимущества. Во-первых, бумажные карточки дешевы и их легко использовать. Во-вторых, это упрощает командную работу: каждый может взять карточку и записать идею. В-третьих, карточки можно легко сгруппировать на столе или стене, чтобы проверить полноту и целостность визуализации зависимостей. Даже если ваши истории хранятся в электронном виде, стоит использовать бумажные карточки, когда вы придумываете новые истории.

Истории хотят сообщить вам информацию. Поэтому не прячьте их на сетевой диск, джунгли корпоративного интранета или в другие дебри. Определите их на видное место. Например, на стену. Это способствует командной работе, создает прозрачность процесса, делает очевидным, если вы добавляете слишком много историй слишком быстро (у вас просто начнет заканчиваться место). Удобный инструмент для поиска, визуализации и организации ваших сценариев — это доска продукта, показанная ниже.

Создание отличного UX (пользовательского опыта) требует больше, чем только истории. Истории помогают определить функциональность продукта, но не подходят для изображения пути пользователя (User Journey) и подготовки визуального дизайна. Поэтому дополняйте истории другими техниками: картами историй, диаграммами, сторибордами, скетчами, макетами.

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

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

Переводчик: Екатерина Герасименко

Дарья Ломова
Ведущий дизайнер Red Collar

Вначале работы я рекомендую абстрагироваться от скетчей и наработок и представить себя на месте пользователя. Например, вы тётечка из целевой аудитории и зашли на сервис впервые. Куда она посмотрит? Что нажмёт? Нужен ли ей поиск? Запишите все её потенциальные хотелки, обсудите с продюсером и внедрите в прототипы.

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

Татьяна Некрасова
Ведущий проектировщик интернет-компании R52.RU

Действительно ли полезны пользовательские истории для разработчиков продукта?

Мы часто сталкиваемся с ситуацией, когда сами разработчики начинают описывать пользовательские сценарии, думая от лица пользователя. При этом программисты зачастую думают о том, как максимально снизить всевозможные проблемы, связанные с работой будущего проекта, и тем самым уменьшить трудоемкость работ по данному проекту в будущем. Дизайнеры стараются использовать самые трендовые «фишки», надеясь, что именно этот проект дополнит их портфолио ещё одной качественной работой. Таким образом главный критерий пользовательского опыта как бы отодвигается на второй план, уступая личным целям разработчиков. Я думаю, что подобный подход является не лучшим с точки зрения конечного пользователя.

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

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

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

Инга Таирова
Заместитель директора по развитию интернет-агентства Bquadro

Я очень надеюсь, что написание User Story войдет в бизнес-обиход в той же мере, что и определение целевой аудитории. Ещё 10 лет назад далеко не все клиенты могли сходу назвать свою ЦА.

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

C User Story такого пока не случилось, хоть это и является продолжением той же мысли. На деле этого не происходит, более того — компания часто не готова к изменениям, даже если становится очевидным конкретная потребность большей части аудитории.

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

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

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

Оригинал: https://www.romanpichler.com/blog/10-tips-writing-good-user-stories/