Лого vc.ru

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

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

Присылайте колонки, соответствующие требованиям редакции, на secret@vc.ru

Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

Полезная памятка, спасибо!

0

Глава из книги "UX-дизайн для малышей"

0

Продолжение будет?

0

Спасибо за статью. Уверен, что метод действенный. Хотя я, если честно, думал,что спецы в этой сфере пользовались им как само собой разумееющееся.

0

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

0

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
Антон Тихомиров

Нет, ну как-бы типа сам факт не радует что за мной следят. Вот буду я со своей девушкой выбирать ей нижнее белье, предварительно обсуждая его в переписке. Вроде все законно, недавно 18 ей исполнилось, ничего запретного не обсуждаем. Но блин, как-то не очень греет мысль, что мы с ней под колпаком. Суть, думаю, понятно донес...

Дуров и Сноуден поспорили о защищённости Telegram и WhatsApp
0
Andrey Harchenko

Вот всё вроде бы хорошо и правильно. С некоторым уточнением - есть задачи по объему-сроку, ну условно сложить 20000 кирпичей или сверстать 200 однотипных шаблонов. И есть задачи по сложности - например реализовать систему с нуля или отловить баг, там сложно определить и объем и срок. В первом случае можно действительно распределить так работу, чтоб не класть кирпичи с шаблонами по 10-12 часов в день и не умотаться через неделю. Во втором случае, если работать только, когда есть "вдохновение и настроение" можно легко дни превратить в недели, недели в месяцы, месяцы в годы, и работать это будет только, если сроки позволяют when is done.

«В выгорании виноваты сотрудники»: исполнительный директор Basecamp о признаках культуры трудоголизма
0
Евгений

В чем противоречивость?В первом пункте говорится,о том что работа не должна раздражать,во-втором,что вместо того чтобы писать глупые комментарии на VC,заняться чем-то полезным

«10 карьерных ошибок, которые я мечтал бы не совершать»
0
Вячеслав Кирьянов

Интересная задумка.

Beepka — сервис SMS-уведомлений об эвакуации автомобилей
0
Сергей Никитин

WhatsApp, Telegram, Viber, Allo привязываются к номеру телефона. Достаточно знать этот номер. Или вопрос не в этом?

Google рассказала о работе над сервисом для чтения сообщений без установки мессенджеров
0
Показать еще