Бизнес юзкейс в ит

Бизнес юзкейс в ит

Use Case (вариант использования, ВИ, Прецедент, юскейс) — это сценарная техника описания взаимодействия. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни.

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

  • покупка товара в магазине (Покупатель-Продавец),
  • отправка письма по электронной почте (Адресант-Почтовый клиент),
  • запрос страницы браузером (Браузер-Web-сервер).

В разработке ПО эту технику часто применяют для проектирования и описания взаимодействия пользователя и системы, поэтому название Use Case часто воспринимает как синоним требования человека-пользователя к решению определенной задачи в системе. В статье мы будем рассматривать использование Use Case для описания взаимодействия пользователя с системой.
Исторически требования к функционированию системы описывались в виде отдельных функций. Ивар Якобсон в середине 1990-х годов предложил Use Case как альтернативу и дополнение описания функциональности системы. Описание требований к системе не в виде отдельных функций, а в виде описания контекста и последовательности действий пользователя помогает сформировать набор функциональных требований, который будет обеспечивать полноту и неизбыточность требований.

Мы можем сформулировать набор функциональных требований:

FRQ1 Система должна предоставить пользователю возможность ввести код бронирования
FRQ2 Система должна сохранить сведения о регистрации пассажира на рейс
FRQ3 Система должна предоставить пользователю возможность распечатать посадочный талон

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

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

Use Case задаёт формат, в котором все эти важные факторы описываются и учитываются. И перечисленные выше функциональные требования можно объединить в один Use Case, описывающий цель пользователя.

Пример базовой части Use Case.
Регистрация пассажира на рейс

Описание решения задачи пользователя в системе в виде Use Case должно определять:

  • Систему, с которой описывается взаимодействие;
  • Основное действующее лицо: роль пользователя;
  • Цель основного действующего лица;
  • Предусловие;
  • Триггер;
  • Основной поток действий;
  • Результат.

В качестве взаимодействующей системы здесь рассматривается Система регистрации Пассажира на рейс. Именно с ней Пассажир — основное действующее лицо — ведёт диалог и с его помощью достигает своей цели — зарегистрироваться на рейс.

Основной поток действий Use Case описывает успешную последовательность событий, необходимую для достижения конкретной цели основного действующего лица.

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

Триггер — событие, инициирующее начало сценария. Триггером, в общем случае, может быть:

  • действие основного действующего лица;
  • наступление определённого времени времени, например, если действие сценария должно происходить периодически: раз в день, раз в неделю, раз в месяц.

Триггер может предшествовать первому шагу сценария, а может являться первым шагом.

Результат — или «гарантия успеха» — след, который оставляет сценарий. Наличие результата говорит нам, что и Пассажир достиг своей цели.

Этот Use Case пишется для проектирования решения, его потребителем будет команда разработки.

Назначение Use Case для разных участников проекта

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

Рассмотрим преимущество работы с набором Use Case для людей, выполняющих разные роли в проекте.

Use Case для руководителя проекта

Сам по себе Use Case — это естественный способ описывать диалог, он понятен человеку без подготовки, Use Case обычно не содержит деталей реализации и пишется на языке целей пользователей. Поэтому Use Case удобно согласовывать с Заказчиком как «единицу поставки»: элемент планирования работы над системой и сдачи проекта.

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

То, что набор Use Case состоит из меньшего количества элементов — обычно от 5 до 20, — чем набор отдельных функциональных требований, экономит время на согласование проекта с заказчиком, а то, что заказчику понятна бизнес-ценность каждого Use Case, сильно упростит выставление приоритетов между ними.

Use Case для тестировщика

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

Use Case для аналитика и менеджера продукта

Для аналитика и менеджера продукта, как наиболее частых авторов, Use Case это отличный инструмент:

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

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

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

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

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

Например, работа с системами типа «тасктрекер» задается достаточно простыми и стандартными Use Case: «Создать задачу», «Назначить задачу», «Пометить задачу, как выполненную». Однако тасктрекеров существует огромное множество, и это оправдано тем, что в каждом есть свои возможности по заданию жизненных циклов задач, их типов и взаимосвязей. И эту внутреннюю логику работы с задачами нет смысла описывать в виде Use Case.

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

Если эта техника вас заинтересовала, ознакомьтесь с материалами от классиков Use Case:

  • Книга о написании Use Case, которая считается классикой: Алистер Коберн, «Современные методы описания функциональных требований»
  • Современная методика проектирования и гибкого планирования разработки систем с помощью Use Case от основоположника техники, Ивара Якобсона: Use Case 2.0 Essentials Practice

User story vs Use Case: разбираемся со схемами представления требований

Продолжая обучение начинающих бизнес-аналитиков, сегодня рассмотрим 2 популярные схемы описания требований в Agile-проектах. Читайте далее, чем User story отличается от Use Case, а также как они связаны с UML-диаграммой прецедентов, а также функциональными и нефункциональными требованиями к решению, которые входят в ТЗ по ГОСТ.

Читайте также  Госпошлина за выдачу паспорта в 14 лет

От потребности к решению: виды требований и способы их описания

Напомним, руководство к профессиональному своду знаний по бизнес анализу BABOK®Guide выделяет 3 основных вида требований (бизнес, стейкхолдеров и к решению), а также переходные, актуальные на момент трансформации от текущего состояния (as-is) к желаемому (as-to-be). Подробнее об этом мы говорили в отдельной статье. Аналитик плотно работает со всеми видами требований, последовательно трассируя потребности, проблемы и возможности в требования к решению через бизнес-требования и требования заинтересованных сторон (стейкхолдеров).

Если решением является информационная система или программно-аппаратный комплекс, как это бывает в большинстве случаев, то в техническое задание (ТЗ) на его разработку попадают именно требования к решению: функциональные и нефункциональные. Для этого выделяются соответствующие пункты в стандартах по разработке (ISO/IEC/IEEE 29148:2018, ГОСТ 34.602-89, ГОСТ 19.201-78) и спецификации требований к программному обеспечению (Software Requirements specification, SRS) на основе IEEE/ISO/IEC 29148-2011. На практике формирование такого комплексного ТЗ по всем правилам является длительным и итеративным процессом со множеством циклов согласования между Заказчиком и командой реализации. Поэтому, чтобы лучше понять потребности стейкхолдеров и быстрее начать работу над программным продуктом, бизнес-аналитик описывает требования к системе в виде пользовательских историй (user story), которые кратко формулируют, какие возможности она предоставляет конкретной роли.

Что такое пользовательская история и чем она хороша

Обычно user story создаются по шаблонам возможности или ограничения:

  • должен иметь возможность в с в , чтобы . Например, Администратор клиники должен иметь возможность просмотреть данные о прошлых и запланированных посещениях пациента в течение 3 секунд после определения личности клиента по номеру телефона входящего звонка, чтобы добавить новое или изменить запланированное посещение.
  • должна каждые , чтобы . Например, CRM-система должна отправлять СМС-напоминание клиенту о предстоящем посещении за сутки перед посещением, чтобы он помнил о приеме и пришел вовремя.

Таким образом, формулировка исходных требований стейкхолдеров в виде пользовательских историй соответствует BDD-походу к разработке (Behavior-driven development), позволяя описать ожидания пользователей от проектируемой системы на понятном им языке и определить поведенческие сценарии тестирования для приемочных испытаний. User stories особенно распространены в продуктовой аналитике, но не заменяют собой формальное ТЗ по ГОСТ’ам с перечислением функций системы, о чем мы уже упоминали здесь и здесь. На практике такое представление требований часто встречается в Agile-проектах, особенно на начальном этапе бизнес-анализа при выяснении и уточнении потребностей заинтересованных сторон. Подробнее о том, как разные модели и методологии разработки ПО реализуют принципы Agile и движение по этапам SDLC, читайте в нашей отдельной статье.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
Ближайшая дата курса
Длительность обучения
8 ак.часов
Стоимость обучения
15 000 руб.

Сценарий использования и UML-диаграмма Use Case

Однако, user story – далеко не единственная схема представления требований, хотя именно она больше всего подходит к описанию требований стейкхолдеров. Также для описания функциональных требований, описывающих поведение проектируемой системы в едином смысловом контексте, применяется инструмент сценариев или вариантов ее использования (Use Case). В этом случае функциональные требования к системе представляются в виде набора функций, объединенных по контексту. Например, Use Case «Запланировать посещение клиента в клинику» может включать следующие функции:

  • Просмотреть историю посещений (данные о прошлых и запланированных визитах);
  • Добавить новое посещение;
  • Выбрать посещение;
  • Просмотреть детали (дата, время, место, врач) посещения;
  • Изменить детали будущего посещения;
  • Удалить будущее посещение.

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

UML-диаграмма Use Case

Бизнес-логика выполнения каждого прецедента UML-диаграммы Use Case обычно детализируется в диаграммах деятельности, реже в диаграммах последовательности и состояний. Однако, сценарий использования не ограничивается только графической UML-схемой, а также включает текстовое описание по следующей структуре:

  • Имя, в формате глагол-существительное, которое описывает достижимую цель и объяснять смысл сценария.
  • Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием.
  • Актор — действующее лицо, кто-то или что-то вне системы, влияющий на нее или находящийся под её влиянием (человек, устройство, другая система или подсистема).
  • Предусловия, которые должны быть истиной для выполнения сценария.
  • Активатор (триггер) – внешнее, внутреннее или временное событие, инициирующее выполнение сценария.
  • Результат (постусловие) – новый объект или изменение состояния существующего объекта, который показывает, что актор достиг своей цели.
  • Порядок Событий (основной поток) — типичный ход событий как ряд пронумерованных шагов.
  • Альтернативные пути и дополнения use case’а могут содержать вторичные пути или другие сценарии, которые являются вариантами основного.
  • Бизнес-правила для определения результата в зависимости от конкретного запроса к системе, например, входных данных: «Изменение деталей или удаление возможно только для будущих посещений, дата и время которых еще не настали на момент просмотра записи».

Обычно сценарий использования по такой структуре оформляется в виде таблицы. В этом случае UML-диаграмма прецедентов (Use Case) является краткой наглядной схемой текстового представления основных функциональных возможностей взаимодействия с проектируемой системой, без детализации их выполнения. Бизнес-логика каждого прецедента описывается в пунктах сценария «Поток Событий» и «Альтернативный поток». Как это сделать на практике, рассмотрим в следующей статье.

Как и зачем писать Use Cases

Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

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

Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

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

В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.

Текст vs диаграмма/схема

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

  • Такой формат более понятен заказчикам (а они тоже предпочитают читать и согласовывать варианты использования).
  • Текст проще и быстрее отредактировать, чем диаграммы и текст.

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

Кому и в каких случаях нужны сценарии

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

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

— Тестировщику. Почти готовый тест-кейс :-)

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

А также другим участникам процесса.

В каких случаях они нужны:

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

Читайте также  Условия для выдачи трудовой книжки на руки владельца

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

— Если вам нужно описать какую-то часть функциональности, работы пользователя с интерфейсом, etc. в виде сценария. Тогда вы можете взять шаблон юзкейса за основу и использовать его для описания сценария. Например, основу требований к вашему мобильному приложению составляет описание пользовательского интерфейса. Но выполнение некоторых функций имеет много нюансов, которые нужно дополнительно описать при помощи таблички: «действие — отклик системы», или даже совместить такую табличку со сценарием.

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

Успешный сценарий:

Пример 2. Авторизация пользователя:

Успешный сценарий:

Важные моменты

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

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

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

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

— Перечитайте документ со сценариями, перед тем, как отдавать его разработчикам или заказчикам. Лучше даже несколько раз. Всегда находятся моменты, которые можно описать лаконичнее, или выявляются какие-то несоответствия. Или случайные «копипасты». Уважайте время и головы других людей.

— Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».

— Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а — это общее расширение к сценарию, не к конкретному.

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

При написании статьи я использовала материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».

Как и зачем писать Use Cases

Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

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

Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

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

В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.

Текст vs диаграмма/схема

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

  • Такой формат более понятен заказчикам (а они тоже предпочитают читать и согласовывать варианты использования).
  • Текст проще и быстрее отредактировать, чем диаграммы и текст.

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

Кому и в каких случаях нужны сценарии

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

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

— Тестировщику. Почти готовый тест-кейс :-)

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

А также другим участникам процесса.

В каких случаях они нужны:

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

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

— Если вам нужно описать какую-то часть функциональности, работы пользователя с интерфейсом, etc. в виде сценария. Тогда вы можете взять шаблон юзкейса за основу и использовать его для описания сценария. Например, основу требований к вашему мобильному приложению составляет описание пользовательского интерфейса. Но выполнение некоторых функций имеет много нюансов, которые нужно дополнительно описать при помощи таблички: «действие — отклик системы», или даже совместить такую табличку со сценарием.

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

Успешный сценарий:

Пример 2. Авторизация пользователя:

Успешный сценарий:

Важные моменты

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

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

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

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

— Перечитайте документ со сценариями, перед тем, как отдавать его разработчикам или заказчикам. Лучше даже несколько раз. Всегда находятся моменты, которые можно описать лаконичнее, или выявляются какие-то несоответствия. Или случайные «копипасты». Уважайте время и головы других людей.

— Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».

— Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а — это общее расширение к сценарию, не к конкретному.

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

При написании статьи я использовала материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».

Юзеркейсы: что это такое и как их писать, чтобы вам поверили

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

Читайте также  Сколько получают опекуны в месяц

Это история от первого лица, герой которой рассказывает о своем опыте покупки и использования каких угодно продуктов или услуг – начиная от кредитных карт, заканчивая онлайн-кинотеатрами и квартирой от конкретного застройщика. Что делать, если у вас нет такого опыта? Это не проблема и нет, обманывать никого не придется. Для убедительного и честного текста нужно будет только собрать «жирную» фактуру.

Опишите собственный опыт, если вы уже пользовались или пользуетесь тем самым товаром. Если же сервис или продукт вам не знакомы, обязательно попросите прислать его на тест или предоставить промо-доступ на несколько дней. С некоторыми темами, например кредитов и недвижимости, дела обстоят сложнее, но и о них я позже расскажу.

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

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

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

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

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

Примерно вот так:

Позвоните в компанию под видом клиента. У того же ЖК на сайте указана возможность онлайн-бронирования квартир: описано, как это сделать, ниже – форма, но непонятно, что именно это дает покупателю (то есть нашему читателю). Такие детали обязательно стоит уточнять и объяснять в тексте.

Вот как это подали мы в статье от лица Паши, руководителя отдела разработки в одной крупной IT-компании:

Не забывайте подписывать картинки и скриншоты — да, вообще все, даже самые, казалось бы, очевидные. Это дополнительный и важный способ коммуникации с читателем.

Объясняйте, почему герой принимает то или иное решение. Здесь я говорю о сторонних вещах, которые тоже нужно пояснить. Помните, я искала плюсы ЖК? Так вот, нашелся еще один на очередном форуме по недвижимости.

Вот так было бы плохо:

А вот так уже хорошо:

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

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

А вот так хорошо:

Здесь я упростила слова и добавила боли в мире читателя – про тот же мусорный бак и удаленку.

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

Подумайте над акцентом в начале. Можно сделать автора центральным героем, а можно пойти от проблемы читателя и только потом представить героя. Если вы ставите автора в центре повествования в какой-то серьезной теме, сначала нужно подкрепить его авторитет. Например, вот так мы начали один из юзеркейсов для сервиса Финолог:

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

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

Придумывайте заголовок после того, как написали текст. Не пытайтесь глядя на пустой белый экран сразу придумать привлекательный заголовок — получится «без жизни» и, скорее всего, без важной конкретики. Сначала напишите разные УТП, потом приплюсуйте к ним эмоциональные акценты и интригу. Вообще лучше максимально уходить от метафорических заголовков, которые без контекста не понятны. Заголовок типа «Занимательная история» при беглом просмотре читателю ничего не говорит — он в интернете за день видит примерно 5–10 занимательных историй. Почему именно эта должна его заинтересовать?

Вот неплохие варианты заголовков:

  1. Теперь мой подъезд похож на лобби в отеле: как я купил квартиру в ЖК «Красавчик»
  2. Почему я решил купить квартиру в квартале Новый: стиль лофт, подземный паркинг, видеонаблюдение, парк и…
  3. Наконец-то я нашел ЖК, в котором мне хочется жить: я просто следовал своему чек-листу и интуиции

Здесь многое зависит от специфики текста, но если есть возможность и желание сделать юзеркейс более качественным, то вот, что можно сделать:

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

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

Будьте героем сами. Здесь поможет муж, жена, штатив, коллега или собственная вытянутая рука.

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

Кстати, вот что значит скатываться в трешак:

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

фото сделаны при плохом освещении, все в шумах;

  • экраны ноутбука и телефона засвечены – непонятно, что там за приложение или сервис;
  • почти все фото одинаковые;
  • фон слишком специфичный — пистолеты и медвежья шкура на стене – все-таки too much.
  • А вот хорошие примеры нескольких самостоятельных фото для этого же юзеркейса, но уже от лица девушки (меня).

    Понравилась статья? Поделиться с друзьями:
    Добавить комментарий

    ;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: