Use Case в дизайне: пример применения пользовательских сценариев от стартапа Trucker Path Статьи редакции

Николай Ковалюнас, дизайнер продукта в компании-разработчике приложения для дальнобойщиков Trucker Path, написал для vc.ru колонку о том, как применять пользовательские сценарии в рабочем процессе.

Допустим, вы продуктовый дизайнер и к вам приходит задача: нужно спроектировать импорт перевозчиков в приложение посредством CSV-файла. Задача снабжена более или менее вменяемым описанием и даже есть структура файла с примером. В общем, ничто не мешает приступить к работе. Первое, что приходит в голову, — открыть тетрадь для скетчирования, Sketch, или Photoshop, или, может, редактор кода, и начать накидывать экраны. Но нет. Здесь необходим Use Case. Что это? Давайте разберемся.

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

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

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

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

В зависимости от сложности и детализированности Use Case может содержать следующие элементы:

• Название (Name) — название Use Case: короткое, понятное, отражающее суть.
• Краткое описание (Brief Description) — текст, описывающий данный Use Case.
• Участники (Actors) — список участников взаимодействия. Часто состоит из одного человека.
• Предусловия (Preconditions) — условия, которые должны быть выполнены перед началом реализации данного Use Case.
• Триггер (Trigger) — событие или условие, которое заставляет пользователя приступить к выполнению Use Case.
• Базовый сценарий (Basic Flow) — последовательность действий, которые выполняет участник для успешного достижения цели. Также может называться Normal Flow, Primary Scenario и Happy Path.
• Альтернативные сценарии (Alternative Flows) — описание альтернативных сценариев выполнения Use Case. Важное условие альтернативных сценариев — участник в итоге успешно достигает цели.
• Исключительные сценарии (Exceptional Flows) — все, что может привести участника к невыполнению Use Case.
• Постусловие (Post Conditions) — результат после выполнения Use Case.

К счастью, на практике не всегда нужно использовать все пункты. Всё зависит от того, для чего и кого вы его пишете.

Итак, возвращаемся к нашей задаче. Открываем обычный текстовый редактор. Очень неплох iA Writer, но сгодится любой. Я, например, использую Google Docs — им удобно делиться с коллегами.

На самом деле, пример взят из реального опыта. В Trucker Path у меня была задача на импорт списка перевозчиков посредством CSV. Приступим.

Как видите, мы использовали далеко не все составляющие Use Case, что вполне нормально. Теперь напишем последовательность шагов для Basic Flow.

1. Пользователь начинает импорт перевозчиков.
2. Пользователь нажимает импорт перевозчиков через CSV-файл.
3. Система дает возможность выбрать файл с компьютера или перетащить его для загрузки.
4. Пользователь использует выбор файла с компьютера.
5. Пользователь выбирает CSV-файл со списком перевозчиков.
6. Система обрабатывает выбранный файл.
7. Система проверяет файл на наличие ошибок.
8. Система не находит ошибок, препятствующих дальнейшей работе.
9. Система выводит предпросмотр данных загруженного файла.
10. Система предлагает сопоставить типы данных.
11. Пользователь сопоставляет типы данных с теми, что есть в системе.
12. Пользователь нажимает импорт.
13. Система импортирует данные.
14. Система проводит все необходимые проверки.
15. Система успешно заканчивает импорт перевозчиков.
16. Система показывает обновленный список перевозчиков.
17. Система информирует пользователя об успешном завершении задачи.
18. Пользователь видит обновленный список перевозчиков.

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

Use Case можно сопроводить быстро заскетчированными основными экранами — так проще донести до другого человека суть происходящего. Ниже пример таких экранов. Часто можно обойтись просто скетчами в тетрадке, так ещё быстрее.

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

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

Что это означает для нас? Объем работы сократился на 30−40%, что довольно ощутимо. Если бы мы сразу начали рисовать дизайн, то потратили бы немало времени впустую, потому что работу в итоге пришлось бы переделывать. А так мы сразу обнаружили расхождение между предложенным и оптимальным решением.

Дальше дорабатываем Basic Flow, исходя из обратной связи, и ещё раз обсуждаем его с менеджером продукта.

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

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

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