В разных компаниях и у разных дизайнеров свои фреймворки, опыт и потребности. В русскоязычных источниках дополнительную путаницу вносит перевод user flow, task flow, user scenarios, user journey и даже иногда cjm, как сценариев. Эта заметка не претендует на абсолютную истину — просто делюсь личным опытом.
Сценарий — это путь пользователя из начального состояния к достижению своей цели. Сценарии делятся на основной, дополнительные и экстренные. Основной сценарий — это самый короткий путь до цели. Ответвления от него называются дополнительными сценариями. Есть ещё экстренные — это всякие ошибки.
Насколько подробными и детализированными составлять сценарии зависит от потребностей дизайнера
При обсуждении с заказчиком нового продукта полезно набросать путь пользователя крупными мазками. При проектировании интерфейса дизайнеру нужна более детальная проработка. При исследовании работы пользователей с уже существующим продуктом сценарии могут быть очень подробными, чтобы ничего не упустить.
Как я делаю сценарии
Я составляю сценарии в фигджеме. В некоторых компаниях приняты строгие нотации для сценариев. Мне в работе это не нужно, мне важнее простота и скорость.
Сначала обозначаю точку входа. Можно начать с первого экрана, который видит пользователь, или с первого действия (особенно полезно, когда пользователь выполняет задачу в нескольких приложених): «Стартовый экран», «Открывает вызов такси», «Получил задание от начальника сделать выгрузку» и т.д.
Потом результат — пользователь достиг своей цели, «Получил заказ с едой», «Вызвал такси», «Скачал выгрузку».
Между ними прописываю шаги, которые пользователь должен совершить, чтобы достичь результата кратчайшим способом.
Сценарий всегда пишу от лица пользователя — важно мыслить не экранами, а действиями. То есть не «система выводит попап со справочной информацией», а «пользователь видит справочную информацию». Это позволяет не уйти в придумывание фич на ходу и не привязываться к интерфейсным элементам (например, по ходу проектирования я пойму, что нужен не попап, а подсказка прямо в интерфейсе).
Потом составляю дополнительные сценарии. Например, кратчайший путь авторизации — через смс, но есть и альтернативный через почту. Вот это — дополнительный сценарий. Или при заказе такси пользователь не просто указал точку назначения, а решил почитать про разные тарифы и отошел от основного сценария. Таких ответвлений может быть много.
Потом — экстренные сценарии. Что может пойти не так? Например, не пришёл код подтверждения, отключился интернет в процессе поиска машины, не смог найти необходимую информацию.
Очень важно, чтобы все сценарии куда-то приводили — или к выходу из сценария (например, направляем пользователя в поддержку) или к финальному результату. Не должно быть ситуаций, когда в сценарии ответвление никуда не ведёт. В реальности это значит, что мы бросили пользователя и он не знает, что делать дальше.
Если сценарий получается очень запутанный и сложный, лучше разбить его на несколько маленьких: например, отдельно прописать сценарий авторизации, отдельно заказа еды, отдельно — оставления чаевых. Абсолютно ок, если сценарий будет очень коротким. Это лучше, чем разбираться в слишком сложных схемах.
О пользе сценариев
- Составляя сценарии, вы думаете со стороны пользователя и его потребностей, а не со стороны продукта и разработки. Так делать удобные продукты гораздо проще, а шанс, что новая фича будет слишком сложной или вообще ненужной сильно уменьшится
- Команда и заказчик сразу понимает, о чём вы говорите, а вы понимаете их — синхронизироваться во мнениях со схемой перед глазами намного легче
- Когда видишь сценарий использования продукта, становится понятнее, куда можно внедрить новую фичу
- Имея на руках сценарий очень легко писать гипотезы и задания для юзабилити тестирования
Больше о дизайне пишу в своём телеграм-канале Неразрывный дизайн 🙃
