Дракон-схема для разбора сценариев

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

Описание методики

Язык Дракон обладает высокой эргономичностью. Он был изобретен в 1996 году специально для упрощения понимания и легкости считывания схем процессов людьми разных специальностей. В B2B-Center этот язык должен был решать следующие задачи:

• устранять барьеры понимания описания процесса между сотрудниками разных отделов;
• улучшить качество описания сценариев за счет эргономичности схем.

Для глубокого понимания и внедрения в работу мы использовали книгу Владимира Парноджанова «Язык дракон. Краткое описание», где последовательно описаны нюансы применения методики на простых примерах.. Для задач описания сценариев внутри продукта мы используем лишь несколько вариаций блоков, которые представлены на картинке ниже.

Кто, как и когда строит

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

Если описать кратко процесс работы с языком Дракон, то он выглядит так:

1. разбить процесс, который хочешь представить, на этапы. На этапы разбивать обязательно. Только очень простые процессы можно представить без этапов, но у нас в работе их практически нет.
2. на уровне этапа: основной сценарий находится на «шампуре». Шампур — самый простой и очевидный сценарий. Шампур идет строго вниз от входа до выхода из этапа и на него «нанизываются» действия и выборы.
3. далее ответвления уходят вправо по принципу: чем правее, тем сложнее.
4. в конце этапа описывается, к какому следующему этапу переходить. У одного этапа может быть несколько ответвлений.
5. после выхода из этапа движение идет налево по кругу.
6. чтобы схема не выглядела громоздкой, некоторые ветки можно выносить отдельно вне схемы, оставив указатель на вставку с названием ветки.

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

Пример выявления проблем в сценариях

Пример из реального проектирования=)

Разберем сценарий настройки переторжки на дракон-схеме:

При изучении схемы можно заметить, что части сценария повторяются для обоих видов переторжки — очной и заочной.

Это повод дизайнеру подумать: возможно стоит объединить сценарий в этом месте или вообще вынести в отдельную ветку. Например, так:

Соответственно, еще до отрисовки макетов дизайнер понимает, что можно сгруппировать, видит сценарий целиком и может многие нюансы предусмотреть сразу на схеме.

Выводы

Как и в любой методике, не все так однозначно. Вот с какими нюансами мы столкнулись при применении языка Дракон:

1. дракон-схемы не выглядят так презентабельно как, например, цветные chartflow;
2. довольно трудоемкие в процессе создания;
3. в Miro нет шаблона для дракон-схем и некоторых символов;
4. новичкам требуется объяснение правил работы и чтения;
5. не всегда получаются с первого раза. Нужен гуру, который поможет разобраться другим дизайнерам.

В системах со сложной бизнес-логикой дракон-схемы — отличный вариант для разбора сценариев. У команды продукта все «как на ладони», нет скрытых взаимосвязей, вся система раскладывается на мельчайшие винтики.