Всем привет! Я Ната, UX/UI дизайнер в Red Collar. В этой статье я расскажу о методологии, которая улучшит коммуникацию внутри команды, а значит и работу над продуктом — Use Case или «юзкейсе», а также поделюсь шаблоном для тех, кто сталкивается с ней впервые.
В идеальном мире юзкейсы составляет системный аналитик на основе правил, сформулированных бизнес-аналитиком после общения с заказчиком. В реальном мире таких позиций в команде может не быть из-за ограничений по времени и бюджету, но проблема передачи знаний внутри команды на проекте остается. В таких случаях писать юзкейс может дизайнер, тестировщик, продакт и другие люди.
Польза юзкейсов — единое представление о продукте
Если в команде более 5 человек, а проект длится более 3 месяцев, то может возникнуть дискоммуникация. Например:
- разработчики неправильно поняли сценарий взаимодействия и реализовали фичу не так, как планировалось;
- в ходе долгих обсуждений внутри команды вы сильно отклонились от первоначальной идеи и точно воспроизвести её не можете;
- дизайнеры спроектировали функциональность, которая изначально не планировалась;
- один и тот же кейс в разных местах реализован по-разному, что увеличивает время разработки и усложняет UX;
- при тестировании пропускаются значительные ошибки;
- сменился состав команды: к проекту подключились новые участники, а ведущие члены команды ушли.
Сценарии юзкейсов — как игра в теннис между пользователем и системой
Пишем сценарий для своего фильма
Use Case — это описание взаимодействия с системой в виде последовательности действий для достижения конкретного результата. По сути, это метамодель, которая иллюстрирует не саму систему, а набор функциональных требований к ней.
Методология была разработана в 80-х Иваром Якобсоном. Для всех желающих погрузиться в тему глубже есть бесплатная книга Use-Case 2.0, также другие ссылки по теме оставлю внизу статьи.
Для наглядности юзкейс можно сравнить с игрой в теннис, где один игрок это пользователь, другой — система. Удар ракеткой это действие, которое совершает пользователь, после чего мяч переходит системе, и далее система ему отвечает. Разница только в том, что в юзкейсе пользователь или система могут подряд совершить несколько действий.
Юзкейсы существуют в двух равнозначных видах: UML-диаграмма или текстовый документ. По желанию их можно совмещать
«Основной юзкейс» — сценарий успеха: участники + действия + результат + доп. условия
Единого формата для написания юзкейсов не существует. Каждая компания сама определяет для себя формат и уровень детализации. Опишу основной принцип написания.
Основные элементы юзкейса:
1. Понятный заголовок, желательно, чтобы он содержал результат юзкейса. Пример, «Создание заявки».
2. Действующие лица или участники. Можно выделить такие варианты:
- «Пользователь и система». Например, при авторизации.
- «Несколько пользователей и система». Например, если мы описываем общение в чате.
- «Система и система». Например, если мы описываем внутренние процессы внутри системы.
- «Несколько систем и система».
3. Описание последовательности действий в виде сценария.
КАК НАПИСАТЬ СЦЕНАРИЙ ДЛЯ ВИДЕО НА YOUTUBE. Как мы пишем сценарии и делаем видео интересными!
4. Результат, то есть то, к чему должны прийти пользователь или система.
Ниже показан простой вариант юзкейса на примере регистрации. В нем есть все основные элементы. Также добавлена нумерация шагов, чтобы проще было ссылаться на конкретный шаг в коммуникации.
Пример простого юзкейса
Выглядит понятно, но в реальности кейсы могут оказаться сложнее, поэтому к юзкейсу добавляют дополнительную уточняющую информацию:
- контекст использования;
- откуда происходит переход к юзкейсу;
- дополнительные условия;
- триггер;
- цель;
- изменения в технологии.
В описание юзкейса могут добавлять перечисление инпутов (полей ввода), если это необходимо для понимания сценария.
Пример развернутого юзкейса с пояснениями
«Альтернативный юзкейс» — сценарий ошибки
Рассмотрели вид основных сценариев юзкейсов, а что если возникла ошибка или пользователь столкнулся со сложностями? Для этого создается альтернативный юзкейс: когда результат основного не был достигнут. Например, пользователь не смог зарегистрироваться, так как имя уже занято или с указанной почты уже создана учетная запись.
Альтернативные юзкейсы прописывают отдельно, в нашем случае будет создана отдельная таблица, но если сценарий короткий, то мы описываем его в рамках основного юзкейса. Пример ниже.
Пример юзкейса с альтернативными сценариями внутри основного
Чеклист для написания юзкейсов
Разобрались, что юзкейс нам нужен в первую очередь для улучшения коммуникации внутри команды при разработке продукта. Теперь вы можете легко его написать, но важно, чтобы его также было легко читать. Ниже найдете критерии, которые помогут вам написать легкий для восприятия юзкейс.
Вначале сделайте единый шаблон и заведите словарь
В идеале юзкейсы пишутся на этапе проектирования, при планировании фичей или продукта в целом, но бывает так, что необходимость в юзкейсах обнаруживается позже, когда дизайн готов, а часть продукта уже вышла в прод.
Если вы на начальной стадии проекта, рекомендую начать с составления пути пользователя, а позже переходить к юзкейсам.
Если у вас уже готов дизайн, то перед написанием юзкейсов внимательно изучите все материалы, составьте список разделов и взаимодействий с ними в связке с продактом, дизайнером и другими лицами, участвовавшими в планировании и проектировании продукта.
Советы, которые ускорят написание юзкейсов:
- Создайте один шаблон для всех юзкейсов на проекте. Не страшно, если он будет видоизменяться со временем. Главное, чтобы не приходилось для каждого юзкейса придумывать уникальный формат, так как их будет сложно писать и еще сложнее читать.
- Создайте словарь терминов. Если внутри вашей команды активно используется определенная терминология или вы работаете над узкоспециализированным продуктом, создайте словарь с расшифровкой терминов и ссылайтесь на него при написании юзкейса.
Так нужен ли вам юзкейс?
Важно понимать, что юзкейс — это инструмент, а цель любого инструмента — упростить и улучшить работу. Если после внедрения юзкейсов в проект вы не видите изменений, а ресурсы расходуются все больше на ведение документации, то, вероятно, вам стоит пересмотреть процесс ведения документации и протестировать другие инструменты, например, User Story.
Всем крутых продуктов!
Шаблон юзкейса + дополнительные материалы
Подготовила для вас шаблон юзкейса, открыт всем в гуглдоке.
1. Статьи и бесплатные книги о юзкейсах от создателя методологии Ивара Якобсона — даст более полное представление об инструменте «из первых рук» (en)
2. Короткое видео с простым объяснением инструмента от бизнес-аналитика + ссылка в описании к видео на их шаблон юзкейсов (en)
3. Короткое видео о юзкейсах для новичков от UX/UI дизайнер в Siemens (ru)
4. Статья от Usability.gov с краткой информации о юзкейсах и примером их заполнения (en)
5. Статья от системного аналитика, где подробно рассказывается о методологии и опыте ее применения в QIWI (ru)
Источник: vc.ru
Примеры и сценарии скриптов Office
В этом разделе содержатся решения для автоматизации на основе сценариев Office , которые помогают конечным пользователям выполнять автоматизацию повседневных задач. Он содержит реалистичные сценарии, с которыми сталкиваются бизнес-пользователи, и предоставляет подробные решения, а также пошаговые обучающие видеосвязи.
Для каждого из проектов, приведенных в разделе Основные сведения и Дополнительные сведения, ознакомьтесь с исходным кодом, пошаговые видео на YouTube и многое другое.
В разделе Сценарии мы включили несколько более крупных примеров сценариев, демонстрирующих реальные варианты использования.
Заметки консультанта
Советы для написания хороших сценариев использования
Posted by Shamrai Alexander на 2 марта, 2011
James Heumann, Requirements Evangelist,
IBM Rational Software
Что такое сценарий использования (и что не является им)
Сценарии использования – это программные требования, которые определяют функциональность
Ссылки позволяют пользователям восстановить всю историю
Введение
Написание хороших сценариев использования в большей степени искусство, чем наука. И, как в любом искусстве, нет абсолютных правил для создания ваших шедевров. В конечном счете, сценарии использования четко предоставляют подробную информацию для очень широкой аудитории и достижения целей создания успешных проектов разработки.
Ивар Якобсон ввел сценарии использования. Мария Эриксон работала с Якобсоном и была соавтором одной из его книг. Курт Биттнер и Ян Спенс также написали популярную книгу по использованию сценариев использования.
Эти пионеры и многие другие люди в IBM, которые имеют многолетний опыт работы с заказчиками в разработке хороших сценариев использования, внесли свой вклад в технологии, описанные в этой статье. Дать хороший сценарий использования не легко, но, к счастью, наш опыт может быть Вашим руководством. Концепций и принципы, собранные здесь, представляют опыт многих людей в IBM, и они образуют основу проверенных передовых методов. Многие советы, приведенные в данном документе, являются частью методологии IBM Rational® Unified Process® (RUP®), другие являются новыми и не представлены в RUP.
Что такое сценарий использования (и что не является им)
Вариант использования – это спецификации набора действий, выполняемых системой, который дает заметный результат, который, как правило, значим для одного или нескольких субъектов или других заинтересованных сторон системы (UML 2).
Сценарии использования – это программные требования, которые определяют функциональность
Люди часто говорят о требованиях и сценариях использования, подразумевая, что это разные вещи. Прецеденты просто другой способ для организации функциональных требований; они по-прежнему требованиям. Традиционно требования описывают функциональность системы, используя длинный список с выражением «должен», иногда их тысячи. Целью создания сценариев использования является преобразование этих многих выражений на более мелкие группы, которые обеспечивают наблюдаемое значение и контекст, организованные с точки зрения пользователя.
Совет: Не забывайте о диаграммах
Совет: Люди-субъекты являются наиболее важным элементом
Рисованные фигуры, применяемые в диаграммах сценариев использования, называются субъектами. Они показывают, любое лицо (или роль), другие системы или, возможно, даже устройство, которое находятся за пределами разрабатываемой системы, но взаимодействуют с ней. Люди-субъекты представляют наиболее интересные и сложные взаимодействия для большинства систем, а также взаимодействие человека и системы, где реальная значимость сценария использования вступает в перспективе. Функциональность, вложенная в сценарий использования, поможет субъектам делать свою работу или задачу существенно лучше.
Совет: Идите за потоком
Хорошие сценарии использования не только абзацы понятного и краткого текста. Они имеют структуру, которая определяет, как части сценариев использования сочетаются друг с другом. И они могут быть структурированы разными способами, которые называются стилем сценария использования.
Ссылки позволяют пользователям восстановить всю историю
Хорошая практика разбивать на модули сценарий использования, разделив его на несколько потоков. Но чтобы быть в состоянии рассказать всю историю, Вы также должны иметь какой-то способ сложить кусочки снова вместе, чтобы проиллюстрировать конкретные непрерывные сценарии. Это достигается с помощью ссылок, которые по существу определяют начало и конец альтернативного потока, ссылаясь на конкретный шаг в основной поток или иной альтернативный поток (см. рисунок 3). Создание легко понимаемого сценария использования требует последовательной техники с использованием ссылок.
Совет: Помещайте ссылки в альтернативных потоках, а не основных потоках
Основной поток показывает, что происходит, когда все в сценарии использования идет правильно и субъект движется к своей цели. Он включает в себя упорядоченное по времени множество шагов (событий), которое объясняет, что система делает и то, что субъект делает для того, чтобы выполнить сценарий использования. Ссылки – это простые операторы, которые указывают о том, где поток начинается, как и где он заканчивается.
Совет: Сценарии описывают полную историю
Совет: Будьте осторожны с операторами «если»
Совет: Укажите выбор для субъекта
Субъекты часто делают выбор в сценарии использовании. Рассмотрим пример системы регистрации университета определенного в сценарии использования «Регистрация на курсы». В этом примере шаг главного потока может спросить субъекта: 1) создать график, 2) изменить график и 3) удалить график.
Часто авторы сценария использования пытаются использовать оператор «если», чтобы показать, субъект делает выбор, но по причинам, указанным выше, это может быть не лучшая идея. Лучшей альтернативой для того, чтобы все возможности выборы субъекта были перечислены в соответствующем месте и был один выбранный вариант, направляющий в текущий поток, а другие рассматривались в альтернативных потоках. Этот метод сохраняет каждый поток простым и снижает ветвления.
Совет: Убирайте СЧОУ
Часто мы замечаем, что авторы дают субъектам выбирать путем создания отдельных сценариев использования для каждого варианта. Это заманчивое решение, но и опасное. Опасность заключается в необходимости управлять экспоненциальной сложностью, которую часто создается в результате излишне повторяющихся моделей поведения и, в конечном счете, сценариев использования с минимальной значимостью.
Вместо этого, попробуйте сосредоточиться на вещах, которые субъект действительно хочет сделать, что, как правило, не в действиях создание, чтение, обновление и удаление (СЧОУ).
В нашем примере системы регистрации университета, есть варианты для 1) создания графика, 2) изменения графика и 3) удаления графика. Все они находятся в сценарии использования «Регистрация на курсы», поскольку студент не заботится о создании и изменении графиков; студент хочет только зарегистрироваться. Выбор легкого пути и составление списка всех деятельностей СЧОУ в результате даст в три или в четыре раза больше сценариев использования, чем необходимо и может быстро сделать процесс сложным и трудно управляемым.
Совет: Последовательность событий может быть опциональной
Совет: Используйте правильный уровень детализации
Один из наиболее часто задаваемых вопросов: «На сколько детально описывать сценарий использования?» Помните, что сценарий использования – это требования. Это не документация по проектированию, и они, конечно, не проект пользовательского интерфейса. Сценарии использования никогда не должны ссылаться на элементы пользовательского интерфейса, такие как домашние страницы, экраны входа или нажатие кнопки.
Кроме того, следует избегать архитектурной детализации. Например, в примере регистрации на курсы, выражение «график сохраняется в базе данных SQL Server» не должно быть в сценарии использования. Часть о сохранении графика необходима, но то где он сохраняется является архитектурной деталью, которая должна быть изменена позже, если администратор базы данных решит, что график должен быть сохранен в другой базе данных.
Совет: Поставьте себя на место субъекта
При хорошем описании и последовательном подходе, сценарии использования могут быть отличным инструментом для описания требований таким образом, который вполне понятен для пользователей и заинтересованных сторон и, в то же время, готов к использованию в команде разработки. Но качество и согласованность может быть достигнута только при наличии согласования структуры сценария использования и процессов. Итак, последний совет: Документируйте решения Ваши и Вашей организации, сделанные на предмет того, как писать хорошие сценарии использования. Создайте документ руководство по стилю сценария использования или презентацию, обеспечьте авторов большим количеством примеров хороших сценариев использования и затем следуйте установленным руководящим принципам.
Как только все усилия, вложенные в сценарий использования, будут (надеюсь) отплачивать успешным проектом разработки, усилия, вложенные в создание стандартных практик, и следование этим советом могут привести к более эффективным сценариям использования, которые ценятся всеми сторонами, вовлеченными в процесс.
Дополнительная информация
Чтобы узнать больше о том, как писать эффективные сценарии использования и как IBM Rational Software может помочь, пожалуйста, обращайтесь к представителю компании или бизнес-партнеру IBM или посетите:
Источник: ashamray.wordpress.com