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

В зависимости от сложности и детализированности 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 - им удобно делиться с коллегами.

Пишем Use Case

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

Название (Name)	Импорт списка перевозчиков посредством CSV
Главный участник (Main actor)	Пользователь системы
Триггер (Trigger)	Пользователь решает перенести объемный список перевозчиков в систему из внешнего источника. Пользователь заходит в раздел перевозчиков и начинает импорт.
Результат (Post Conditions)	Перевозчики из списка добавлены и сохранены в системе. Пользователь понимает, что список успешно перенесен в систему.

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

Basic Flow (B1)

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 помогает дизайнеру объяснить другим участникам команды, как должен вести себя продукт.
• Помогает экономить время на изготовление дизайна, убирая ненужные части продукта.