Метасценарии взаимодействий

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

Изначально эта статья была опубликована в моем личном блоге.

Бывает, что при старте проектировании сложной системы мы почти ничего не знаем ни о ней, ни о специфике предметной области, ни о пользователях. Либо даже знаем, но это как-то бессвязно или частно. Но нам нужно как-то начать работу по «съеданию слона», проанализировать и сформировать общее представление о системе.

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

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

Приведу группы метасценариев, о каждым из которых можно рассказать отдельно (но, увы, не буду — вы же тоже не маленькие).

Метасценарии жизненного цикла

Эти относительно простые сценарии определяют то, как мы начинаем и продолжаем (и заканчиваем) взаимодействовать с системой, получая всё больше опыта и, как правило, поднимая планку собственной требовательности.

• Развёртывание новой системы (инсталляция) — не самый основной сценарий, но для сложных систем, особенно программно-аппаратных средств, мы должны подробно проработать этот сценарий, независимо от того, будет делаться он самим пользователем, либо сервисным инженером. Ибо это реальная боль и убытки для всех.
• Освоение новой системы оператором (так называемый онбординг, хотя у меня, прошу прощения, это всё же ассоциируется с посадкой на судно) — понятно, что с любой более-менее сложной системой мы должны познакомить пользователя. И даже с простой — всё равно, вначале мы глядим на условный калькулятор, а не начинаем щелкать на кнопки.
• Накопление и переиспользование опыта — чем дольше мы работаем с системой, тем выше вероятность что мы уже накопили набор каких-то повторяющихся сущностей, шаблонных решений, цепочек рутинных действий и так далее, которые нам не очень хочется всякий раз повторять с нуля. Библиотеки компонентов в Figma, создание наборов фильтров запросов в Jira, возможность сохранить документ как шаблон в Word — это всё про то, чтобы не заставлять нас делать одно и то же.
• Предоставление экспертных фич для ускорения работы — ну, здесь довольно понятно. То что полезно новичку, будет раздражать опытного пользователя. Хоткеи и прочий быстрый клавиатурный ввод, элементы командной строки (см. AutoCAD), автоматизация/скриптование — всё это про поддержку пользователей экспертов
• Кастомизация системы под себя. В масс-маркете возможности кастомизации считаются плохим тоном, но чем сложнее наша система — тем меньше вероятность, что мы удовлетворим всю массу пользователей (как конечных, так и компании-эксплуатанты). Лично меня удивило, что даже авиадиспетчеры настраивают карты и отображения самолётов под себя. Соответственно, нужно предусматривать, чтобы наша система поддерживала такие возможности, как кастомизация рабочих пространств, цепочек бизнес-процессов, группировок сущностей, состава отображаемых данных и так далее. Вроде очевидно, но не всегда хватает ресурсов на это.
• Обмен данными с другими системами, передача результатов работы из системы — например, отправка созданного чертежа на ЧПУ-станок, либо импорт данных о расходе топлива и треков автотранспорта из сторонних автомобильных систем и т.п.
• Обновление системы — не самый пользовательский сценарий (впрочем, привет Кинопоиску), но проектирование опыта как частных, так и серьезных изменений в существующей системе — то что поможет сохранить лояльность (и, важнее, данные и настройки) существующих пользователей.
• Завершение работы с системой (офбординг). Простая, но забываемая часть жизненного цикла. Как удалить все данные? Как утилизировать систему? Как показывать уволившегося или уволенного пользователя? — элементы данного метасценария.

Метасценарии ситуационной осведомленности

Эти сценарии поддерживают понимание пользователя о том, что происходит с объектом автоматизации системы — бизнесом, транспортным объектом, расписанием больницы или инфраструктурой электростанции. Расписывать подробно не буду, но это крайне важные вещи для тех же информационных систем и, особенно, систем управления и мониторинга в реальном времени (типа контрольных центров АЭС, трейдинговых ситем или рабочих мест для станций скорой медпомощи)

• Ознакомление с тем, что произошло с системой и её объектом автоматизации за время отсутствия.
• Понимание, что требует действий, в том числе немедленной реакции.
• Понимание, что потребует реакции в ближайшем или среднесрочном будущем, включая прогнозирование состояния объекта автоматизации и возможных последствий. Визуализация тенденций тоже сюда.
• Работа в нормальном эксплуатационном режиме или при наличии инцидентов — одно дело когда у нас всё хорошо, другое дело, когда наступила нештатная ситуация. Будь это авария и необходимость бороться с её локализацией и устранением последствий (т.н. damage control), либо же к нам ночью в гостиницу завалилась толпа туристов — кто ездил в командировки большими группами, тот поймёт.
• Уведомление пользователя о событиях, если он не взаимодействует в данный момент с системой — также включает отработку отвлечений пользователя, когда он может забыть, что он делал или что что-то требует реакции (например, ситуации множественных отказов).
• Для систем круглосуточной работы (типа судна или центра управления полётом) — передача вахты другому оператору. Например, та же смена пользовательских настроек, визуализация ключевых объектов интереса и т.п.

Аналитические метасценарии

Эта группа сценариев непосредственно про работу с данными. Особенно характерна для информационных систем.

• Поиск нужного объекта и получение подробных сведений о нём. Если в регистратуру пришел новый пациент и нужно понять, есть ли у него медкарта уже или её нужно создать, либо же или если я хочу найти описание конкретного агрегата автомобиля. Разумеется, понимание причин поиска важно для проработки — появилась она за пределами системы, либо же мы переходим из списка действий, требующих реакции.
• Внесение, обновление информации о частном объекте автоматизации — типичная ветка для предыдущего сценария.
• Идентификация других объектов, относящихся к текущему объекту, получение ключевых сведений о них не переходя в детали.

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