{"id":13571,"url":"\/distributions\/13571\/click?bit=1&hash=d83cff4565300d1a2d0608fa73dd700b196f4b77356ac6255703ca3cdf2503d0","title":"\u041a\u043e\u043b\u043b\u0430\u0431\u044b, \u0440\u0435\u044e\u0437\u044b, \u043a\u043e\u043b\u043b\u0430\u0436\u0438... \u0414\u043b\u044f \u0447\u0435\u0433\u043e \u0432\u0441\u0451 \u044d\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"bf0e0fe0-842c-5899-bb40-4efc00426ccf","isPaidAndBannersEnabled":false}
Сервисы
Red Collar

Как сделать удобный продукт: на примерах разбираем критерии хорошего Use case

Без технической душноты исследуем сценарии «пользователь <—> система». Для продактов, дизайнеров и аналитиков — оставили готовый шаблон

Всем привет! Я Ната, UX/UI дизайнер в Red Collar. В этой статье я расскажу о методологии, которая улучшит коммуникацию внутри команды, а значит и работу над продуктом — Use Case или «юзкейсе», а также поделюсь шаблоном для тех, кто сталкивается с ней впервые.

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

Польза юзкейсов — единое представление о продукте

Если в команде более 5 человек, а проект длится более 3 месяцев, то может возникнуть дискоммуникация. Например:

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

  • в ходе долгих обсуждений внутри команды вы сильно отклонились от первоначальной идеи и точно воспроизвести её не можете;

  • дизайнеры спроектировали функциональность, которая изначально не планировалась;

  • один и тот же кейс в разных местах реализован по-разному, что увеличивает время разработки и усложняет UX;

  • при тестировании пропускаются значительные ошибки;

  • сменился состав команды: к проекту подключились новые участники, а ведущие члены команды ушли.

Сценарии юзкейсов — как игра в теннис между пользователем и системой

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

Методология была разработана в 80-х Иваром Якобсоном. Для всех желающих погрузиться в тему глубже есть бесплатная книга Use-Case 2.0, также другие ссылки по теме оставлю внизу статьи.

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

Юзкейсы существуют в двух равнозначных видах: UML-диаграмма или текстовый документ. По желанию их можно совмещать

«Основной юзкейс» — сценарий успеха: участники + действия + результат + доп. условия

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

Основные элементы юзкейса:

1. Понятный заголовок, желательно, чтобы он содержал результат юзкейса. Пример, «Создание заявки».

2. Действующие лица или участники. Можно выделить такие варианты:

  • «Пользователь и система». Например, при авторизации.
  • «Несколько пользователей и система». Например, если мы описываем общение в чате.

  • «Система и система». Например, если мы описываем внутренние процессы внутри системы.
  • «Несколько систем и система».

3. Описание последовательности действий в виде сценария.

4. Результат, то есть то, к чему должны прийти пользователь или система.

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

Пример простого юзкейса

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

  • контекст использования;
  • откуда происходит переход к юзкейсу;
  • дополнительные условия;
  • триггер;
  • цель;
  • изменения в технологии.

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

Пример развернутого юзкейса с пояснениями

«Альтернативный юзкейс» — сценарий ошибки

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

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

Пример юзкейса с альтернативными сценариями внутри основного

Чеклист для написания юзкейсов

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

Вначале сделайте единый шаблон и заведите словарь

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

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

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

Советы, которые ускорят написание юзкейсов:

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

Так нужен ли вам юзкейс?

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

Всем крутых продуктов!

Ната Нефедьева

Шаблон юзкейса + дополнительные материалы

Подготовила для вас шаблон юзкейса, открыт всем в гуглдоке.


1. Статьи и бесплатные книги о юзкейсах от создателя методологии Ивара Якобсона — даст более полное представление об инструменте «из первых рук» (en)

2. Короткое видео с простым объяснением инструмента от бизнес-аналитика + ссылка в описании к видео на их шаблон юзкейсов (en)

3. Короткое видео о юзкейсах для новичков от UX/UI дизайнер в Siemens (ru)

4. Статья от Usability.gov с краткой информации о юзкейсах и примером их заполнения (en)

5. Статья от системного аналитика, где подробно рассказывается о методологии и опыте ее применения в QIWI (ru)

0
5 комментариев
Анастасия Бузова

материал огонь, спасибо!

Ответить
Развернуть ветку
Саня Фимин

Имхо важно отличать alternative flow приводит к успеху (возможно другому) и exceptional flow - что то пошло не так

Ответить
Развернуть ветку
НК

Здравствуйте, спасибо за статью. А что за пункт "изменения в технологии"? Можно пример какой-то?

Ответить
Развернуть ветку
Red Collar
Автор

Привет! В этом пункте можно описать изменения «под капотом» в коде, например, в обработке данных, если эти изменения влияют на взаимодействие участников юзкейса. Автор добавила пункт в статью для демонстрации, что вы можете в документации указать любой тип информации, который будет полезен для понимания, но это необязательно.

Ответить
Развернуть ветку
Инна Романова

Огромное спасибо за такую подробную статью!

Ответить
Развернуть ветку
Читать все 5 комментариев
null