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)
- Пользователь начинает импорт перевозчиков.
- Пользователь нажимает импорт перевозчиков через CSV-файл.
- Система дает возможность выбрать файл с компьютера или перетащить его для загрузки.
- Пользователь использует выбор файла с компьютера.
- Пользователь выбирает CSV-файл со списком перевозчиков.
- Система обрабатывает выбранный файл.
- Система проверяет файл на наличие ошибок.
- Система не находит ошибок, препятствующих дальнейшей работе.
- Система выводит предпросмотр данных загруженного файла.
- Система предлагает сопоставить типы данных.
- Пользователь сопоставляет типы данных с теми, что есть в системе.
- Пользователь нажимает импорт.
- Система импортирует данные.
- Система проводит все необходимые проверки.
- Система успешно заканчивает импорт перевозчиков.
- Система показывает обновленный список перевозчиков.
- Система информирует пользователя об успешном завершении задачи.
- Пользователь видит обновленный список перевозчиков.
Отлично, первая версия готова. Заметьте, что сразу обнаруживаются слабые места и нестыковки, которые тут же можно устранить. В итоге спроектированное взаимодействие получается логичным и понятным. Не забывайте помимо действий пользователя описывать действия системы. Отсутствие этого описания - одна из самых частых ошибок.
Use Case можно сопроводить быстро заскетчированными основными экранами - так проще донести до другого человека суть происходящего. Ниже пример таких экранов. Часто можно обойтись просто скетчами в тетрадке, так еще быстрее.
В нашем случае после общения с коллегами был получен следующий результат: все отлично, но сейчас нет смысла делать предпросмотр и сопоставление данных пользователем. Несмотря на то, что импорт стал менее удобным, отказ от части функциональности был оправдан: это дорого и не так важно для продукта.
Что это означает для нас? Объем работы сократился на 30?40%, что довольно ощутимо. Если бы мы сразу начали рисовать дизайн, то потратили бы немало времени впустую, потому что работу в итоге пришлось бы переделывать. А так мы сразу обнаружили расхождение между предложенным и оптимальным решением.
Что дальше
Дальше дорабатываем Basic Flow, исходя из обратной связи, и еще раз обсуждаем его с менеджером продукта.
В результате написание Use Case пройдет несколько итераций. Вспомните метод прогрессивного JPEG: с каждым разом решение должно становиться более качественным. В процессе можно добавлять альтернативные и исключительные сценарии, главное - знать меру и не пытаться покрыть все возможные варианты. Писать Use Case ради Use Case не имеет смысла. Его стоит писать, чтобы решить задачу быстро и эффективно.
Заключение
Если вы еще сомневаетесь, а нужно ли использовать такую штуку в рабочий процесс, кратко обозначу семь причин полюбить Use Case:
- Проектирование интерфейса и опыты взаимодействия происходят быстро и просто.
- Интерфейс получается более понятным и логичным, повышая эффективность работы и обучения.
- Быстро выявляются ошибки спроектированного опыта взаимодействия.
- Более значимые элементы интерфейса легче выносить на верхний уровень.
- Появляется понимание того, что может пойти не так в ходе взаимодействия пользователя с продуктом.
- Use Case помогает дизайнеру объяснить другим участникам команды, как должен вести себя продукт.
- Помогает экономить время на изготовление дизайна, убирая ненужные части продукта.
