Use Case в дизайні приклад застосування сценаріїв користувача від стартапу Trucker Path
Микола Ковалюнас, дизайнер продукту в компанії-розробнику додатку для далекобійників Trucker Path, написав для vc.ru колонку про те, як застосовувати сценарії користувача в робочому процесі.
Кожен бізнес спочатку спрямований на вирішення будь-якої задачі. В ІТ-індустрії, де користувач часто взаємодіє з продуктом через інтерфейс, дизайн є провідником та вирішенням проблеми користувача. Продуктовий дизайнер займається тим, що шукає ефективне рішення та намагається забезпечити хороший досвід взаємодії.
Саме 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.
На щастя, практично не завжди потрібно використовувати всі пункти. Все залежить від того, навіщо і кого ви пишете.
Пишемо Use Case
Насправді приклад взято з реального досвіду. У Trucker Path я мав завдання імпортувати список перевізників за допомогою CSV. Приступимо.
Як бачите, ми використовували далеко не всі складові Use Case, що цілком нормально. Тепер напишемо послідовність кроків для Basic Flow.
Basic Flow (B1)
Чудово, перша версія готова. Зауважте, що відразу виявляються слабкі місця та нестиковки, які відразу можна усунути. У результаті спроектована взаємодія виходить логічною та зрозумілою. Не забувайте, крім дій користувача, описувати дії системи. Відсутність цього опису – одна з найчастіших помилок.
Use Case можна супроводити швидко заскетчованими основними екранами - так простіше донести до іншої людини суть того, що відбувається. Нижче наведено приклад таких екранів. Часто можна обійтися просто скетчами в зошиті, так щешвидше.
Тепер найважливіше. Те, що вийшло, необхідно обговорити з менеджером товару. Ідеально, якщо є можливість зробити це особисто. Іноді буває корисно запросити ще й когось із команди інженерів. Основна мета – отримати зворотний зв'язок, обговорити деталі рішення, подивитися, наскільки ідея є життєздатною для реалізації. Втягнувши в роботу менеджера товару, ми отримуємо вже частково узгоджене рішення. А отже, надалі на нас чекає менше непередбачених змін.
Що це означає для нас? Обсяг роботи скоротився на 30-40%, що досить відчутно. Якби ми одразу почали малювати дизайн, то витратили б чимало часу, тому що роботу в результаті довелося б переробляти. А так ми одразу виявили розбіжність між запропонованим та оптимальним рішенням.
Що далі
Далі допрацьовуємо Basic Flow, виходячи із зворотного зв'язку, і ще раз обговорюємо його з менеджером продукту.
В результаті написання Use Case пройде декілька ітерацій. Згадайте метод прогресивного JPEG: з кожним разом рішення має ставати якіснішим. У процесі можна додавати альтернативні та виняткові сценарії, головне знати міру і не намагатися покрити всі можливі варіанти. Писати Use Case заради Use Case не має сенсу. Його варто писати, щоб вирішити завдання швидко та ефективно.
Висновок
Якщо ви ще сумніваєтеся, чи потрібно використовувати таку штуку в робочий процес, коротко позначу сім причин полюбити Use Case:
- Проектування інтерфейсу та досліди взаємодії відбуваються швидко та просто.
- Інтерфейс виходить більш зрозумілим та логічним, підвищуючи ефективність роботи та навчання.
- Швидко виявляються помилки спроектованого досвіду взаємодії.
- Найбільш значущі елементи інтерфейсулегше виносити верхній рівень.
- З'являється розуміння того, що може піти не так під час взаємодії користувача з продуктом.
- Use Case допомагає дизайнеру пояснити іншим учасникам команди, як повинен поводитися продукт.
- Допомагає економити час виготовлення дизайну, прибираючи непотрібні частини продукту.