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 может содержать следующие элементы:

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

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

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

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

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

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

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

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

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

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

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

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