В среде айтишников к UX/UI-дизайнерам до сих пор существует легкая нотка пренебрежения. Бытует мнение, что дизайнеры интерфейсов — не истинные разработчики. Однако их вклад в развитие продукта ничуть не меньше, чем вклад бэкендеров или DevOps-инженеров. В современном мире коммерческих продуктов, где почти каждый сайт и приложение направлены на получение прибыли, интерфейс, сценарий пользователя и его путь к целевому действию имеют чуть ли не решающее значение.
Задумайтесь: как бы идеально ни был реализован ваш бэкенд и как бы маркетологи ни разрекламировали ваш продукт, если пользователь, зайдя на сайт или в приложение, столкнется с интерфейсом, составленным настолько непонятно, что не сможет совершить целевое действие (к примеру, положить товары в корзину и оформить заказ), — компания просто не получит прибыль.
Сегодня пользователь стал гораздо требовательнее. Вряд ли кто-то из юзеров клюнет на сайт или приложение с интерфейсом из девяностых или начала двухтысячных. Вспомнить хотя бы сайт Amazon образца 1999 года: бэкенд работает, книги заказать можно, все функционирует. Но современный пользователь, оказавшись на таком сайте, скорее всего, сразу его закроет — несмотря на то, что он полностью рабочий.
Вот почему в нынешнее время интерфейс продукта играет критически важную роль. От того, насколько понятно и удобно выстроен пользовательский путь, напрямую зависит успех всего продукта. В этой статье мы разберем такие важные понятия как Use Case, User Story, Conceptual Scenario, Concrete Scenario и UML на понятном примере.
Что такое Use Case?
Use case — это описание набора последовательностей действий системы, включая различные варианты этих последовательностей, в результате которых получается наблюдаемый результат, обладающий ценностью для участника процесса. Большое спасибо, ничего не понятно...
Если говорить проще, use case — это сценарий взаимодействия пользователя с системой, который приводит к конкретному результату.
Важно понимать: результат — это не только успешное выполнение действия. Ошибка, отказ, невозможность завершить процесс — это тоже результат, и он обязательно должен быть описан.
Чтобы понять ценность use case, нужно ненадолго заглянуть в прошлое. Раньше требования к построению системы описывались в виде отдельных функций. Просто список: «функция 1 — вход пользователя, функция 2 — просмотр каталога, функция 3 — оформление заказа». Такой подход был фрагментарным, неструктурированным и часто не давал полного контекста. Именно поэтому в 90-е годы Ивар Якобсон (шведский ученый в области информатики) предложил использовать use case в качестве дополнения к описанию функциональности систем. Вместо перечисления абстрактных функций он предложил описывать контекст и последовательность действий пользователя, что в итоге должно сформировать набор функциональных требований. Такой переворот в мышлении позволил разработчикам, заказчикам, дизайнерам и тестировщикам говорить на одном языке.
Ценность Use Case
Use case нужен не только для описания поведения системы, но и для анализа.
Он позволяет:
- обеспечивать качество и последовательность работы команды (особенно ценен в больших проектах с большой командой, где важно поддерживать систему долгие годы).
- значительно упростить онбординг новых сотрудников и помочь в тестировании, превращаясь в готовый чек-лист проверяемых требований (быстрое вхождение в контекст продукта).
- находить ошибки и слабые места еще до разработки.
- видеть систему как единый процесс, а не набор функций.
- учитывать внутренние правила работы системы, которые влияют на результат не меньше, чем действия пользователя.
Это инструмент, который помогает проектировать систему, а не просто фиксировать требования.
Для кого важен Use Case?
Use case пишут не для себя — хотя и для себя тоже.
— В первую очередь он нужен разработчикам, чтобы они понимали ожидаемое поведение системы.
— Затем — заказчику. У заказчика может не быть технического образования, и ему гораздо легче презентовать продукт через сценарии: «вот пользователь заходит, вот кладет товар в корзину, вот оформляет заказ», чем через сухие спецификации.
— Для тестировщиков use case — это готовые тестируемые требования. Они берут успешный и неуспешный сценарии и проверяют, действительно ли система ведет себя так, как описано.
— Для дизайнеров use case дает понимание пользовательских путей и точек взаимодействия.
А для всей проектной команды он обеспечивает прозрачность задач: каждый видит, как его работа вписывается в общую картину. Итог: качественный use case помогает увидеть возможные ошибки системы еще на этапе проектирования и разработки, а не после релиза — а это колоссальная экономия времени и денег.
Как пишется Use Case на примере оформления заказа
Нет какого-то одного железного фреймворка для написания use case. Каждая компания адаптирует формат под себя. Но есть общие правила, которые работают почти везде. Давайте рассмотрим конкретный сценарий, который напрямую связан с UX/UI: пользователь выбирает товар, кладет его в корзину и оформляет покупку. Вот как может выглядеть use case👇
Действующие лица: пользователь, система
Цель пользователя: оформить заказ
Цель системы: корректно обработать заказ
Успешный сценарий:
- Пользователь открывает главную страницу магазина. Система отображает каталог товаров с фильтрами по категориям, цене и брендам.
- Пользователь выбирает категорию «Беговая обувь» и нажимает на карточку кроссовок модели X. Система открывает страницу товара с описанием, ценой, размерной сеткой и кнопкой «Добавить в корзину».
- Пользователь выбирает размер 37, количество 1 и нажимает «Добавить в корзину». Система добавляет товар в корзину, показывает всплывающее уведомление «Товар добавлен» и обновляет счетчик на иконке корзины.
- Пользователь переходит в корзину и нажимает «Оформить заказ». Система предлагает форму для ввода контактных данных и адреса доставки.
- Пользователь заполняет имя, телефон, адрес, выбирает способ оплаты (картой онлайн) и нажимает «Перейти к оплате».
- Система передает сумму и данные заказа платежному шлюзу. Платежный шлюз открывает защищенную форму для ввода карты.
- Пользователь вводит данные карты и подтверждает оплату. Платежный шлюз возвращает статус «Успешно». Система создает заказ с уникальным номером, отправляет пользователю подтверждение на электронную почту и очищает корзину.
- Результат: пользователь получил подтверждение заказа, система зарегистрировала продажу.
Неуспешные сценарии (альтернативные потоки):
- На шаге 3 товара нет в нужном размере. Система показывает сообщение «Выбранного размера нет в наличии» и не добавляет товар.
- На шаге 6 у пользователя недостаточно средств. Платежный шлюз возвращает ошибку. Система показывает сообщение (ссылка на документ со списком коммуникаций) «Ошибка оплаты. Попробуйте другую карту» и возвращает пользователя на шаг 5.
- На шаге 7 платежный шлюз недоступен. Система выдает сообщение (ссылка на сообщение) «Сервис оплаты временно не работает. Попробуйте позже или выберите оплату при получении». Результат: заказ не оформлен, корзина сохранена.
Общие правила оформления Use Case
При написании use case важно придерживаться нескольких простых, но эффективных правил:
- Фразы лучше формулировать просто и прямо: сначала указывается, кто выполняет действие, затем само действие. Например: «Пользователь вводит логин и пароль. Система проверяет введенные данные».
- Краткость — сестра таланта: описывайте только суть, без лишних деталей.
- Обязательно фиксируйте неуспешные сценарии — именно в них чаще всего скрываются будущие проблемы.
- Все повторяющиеся участки (например, сообщения об ошибках или длинные процедуры) выносите в отдельные документы и ставьте ссылки на них.
- Заведите коммуникационный список — документ со всеми сообщениями, которые система показывает пользователю.
- Используйте глоссарий для терминов.
- Если есть общие бизнес-правила (например, количество неудачных попыток входа, время блокировки, частота обновления данных), их тоже выносят отдельно, чтобы не перегружать use case.
UML-диаграмма и ее роль
Текстовый use case — это основа, но в профессиональной практике его почти всегда дополняют диаграммой. И здесь мы подходим к понятию UML.
UML (Unified Modeling Language) — это унифицированный язык моделирования, который используется для графического описания систем и бизнес-процессов. Он был принят в 1997 году организацией Object Management Group, как стандарт, позволяющий разным специалистам — аналитикам, архитекторам, разработчикам, дизайнерам — понимать друг друга без лишних слов. Он был создан объединенными усилиями трех «отцов»: Гради Буча, Джеймса Рамбо и Ивара Якобсона.
Одним из видов диаграмм UML является диаграмма use case. Она не заменяет текстовый сценарий, а дополняет его, давая общий обзор функциональности на одном листе. На такой диаграмме показывают, кто (актор) взаимодействует с системой и какие именно сценарии (use case) при этом выполняются. Вот как выглядит диаграмма use case для нашего примера с интернет-магазином👇
User Story, Conceptual Scenario и Concrete Scenario: в чем разница
Помимо классического use case, в современной UX и Agile-практике часто используют три близких понятия: user story (пользовательская история), концептуальный сценарий (conceptual scenario) и конкретный сценарий (concrete scenario). Давайте разберем каждое на одном и том же примере — о том, как после успешного оформления заказа система предлагает подборку, которая совершенно не попадает в интересы пользователя.
User story — это короткое описание потребности или боли пользователя на естественном языке. Она не содержит технических деталей. Пример: «После того как я успешно оформила заказ на кроссовки для бега, мне ниже предлагается персонализированная подборка товаров, которые совсем не соответствуют моим предпочтениям. Я только что выбирала кроссовки, а мне предлагают вечернее платье. Зачем мне вечернее платье, если я собираюсь бегать?». В формате Agile User Story это же можно записать короче: «Я, как покупатель, хочу получать релевантные рекомендации после оформления заказа, чтобы видеть товары, связанные с моим последним выбором, а не случайные вещи.»
Conceptual scenario (концептуальный сценарий) — это описание проблемы и возможного решения на высоком уровне, без привязки к конкретному интерфейсу. Он отвечает на вопрос: «В чем суть боли и куда нам двигаться?» Для того же примера: «Пользователи раздражаются, когда после покупки беговых кроссовок им показывают подборку несвязанных товаров — например, вечерние платья или садовые инструменты. Алгоритм рекомендаций не учитывает категорию только что купленного товара. Если мы начнем анализировать последний заказ и предлагать сопутствующие или похожие товары (например, спортивные носки, фитнес-трекеры или беговые шорты), пользователи с большей вероятностью совершат повторную покупку.»
Concrete scenario (конкретный сценарий) — это уже детализированное, почти живое описание того, как решение будет работать в системе, но без жесткой нумерации шагов, как в use case. Он все еще рассказывает историю. Для нашего примера: «После того как пользователь оформил заказ на кроссовки для бега, система перехватывает событие успешного оформления. Она смотрит на категорию купленного товара („Беговая обувь“), затем обращается к правилам сопутствующих товаров: беговые кроссовки обычно покупают вместе со спортивными носками, антиперспирантом и бутылкой для воды. Система формирует блок „Вам также может понадобиться“ из этих позиций. Если пользователь возвращается на главную страницу или открывает письмо с подтверждением заказа, он видит именно такие рекомендации, а не случайные вещи из других категорий».
Таким образом:
- User Story — формулирует потребность.
- Conceptual Scenario — описывает подход к решению.
- Concrete Scenario — описывает конкретную реализацию.
Заключение
В мире, где пользовательский интерфейс фактически решает, получит компания прибыль или нет, грамотно составленный use case становится одним из самых важных инструментов команды.
Надеемся, мы сумели показать: качественные use cases — это не формальность и не лишняя документация. Это то, что позволяет всей команде — от дизайнера до заказчика — видеть продукт глазами пользователя и создавать такие интерфейсы, благодаря которым люди легко совершают целевые действия, а бизнес получает результат.
Подписывайтесь на наши сообщества в Telegram и ВКонтакте — там мы публикуем еще много интересных материалов.