Пример

Предположим, наш продукт — инструмент для выставления счетов. Мы рассматриваем новую функцию Autopay — автоплатёж, — чтобы клиенты наших клиентов могли автоматически оплачивать будущие счета.

Как включить автоплатёж? Что для этого требуется? Можно выбрать начальную точку: клиент открыл счёт. Это наше первое место. Рисуем его: пишем название и подчёркиваем.

Мы думаем, что на счёт можно добавить новую кнопку Turn on Autopay — «Включить автоплатёж». Это возможность действия. Возможности действия располагаются под чертой: так мы показываем, что они доступны в этом месте.

Куда ведёт эта кнопка? В какое-то место настройки автоплатежа. Нам не нужно уточнять, отдельный это экран, всплывающее модальное окно или что-то ещё. С точки зрения того, что с чем связано, — топологии — это одно и то же. Проведём соединительную линию от кнопки к экрану Set up Autopay — «Настроить автоплатёж».

Теперь можно обсудить, что должно быть на этом экране. Запрашиваем ли мы здесь данные кредитной карты? Может быть, карта уже сохранена? А как насчёт ACH или других способов оплаты?

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

Обдумав всё, мы решаем запросить здесь данные кредитной карты и показать логотип финансовой организации — это особенность предметной области именно этого продукта.

Всё достаточно просто. Но постойте: исходный счёт мы оплатили или нет? Хм. Теперь у нас появились вопросы и к функциональности, и к интерфейсу. Что на самом деле делает включение автоплатежа? Оно относится только к будущим счетам или первый платёж через Autopay оплачивает и текущий счёт? И где мы объясняем это поведение? Всего несколько слов и стрелок на схеме взаимодействия вызывают всё более глубокие вопросы и обсуждения.

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

Можно добавить опцию на экран настройки…

Но теперь мы усложняем обязанности экрана подтверждения. Если пользователь оплачивает задолженность сейчас, нужно будет показать квитанцию. Должен ли экран подтверждения содержать условие, при котором он иногда показывает квитанцию с суммой только что совершённого платежа?

А если выбрать совсем другой подход? Начинать не со счёта, а предлагать автоплатёж при совершении платежа. Тогда не возникает неоднозначности: понятно, оплачивается ли текущая сумма. На существующую страницу подтверждения оплаты можно добавить отдельное уведомление «Автоплатёж включён».

Рисуя эту схему, мы вспомнили, что существующая форма оплаты поддерживает не только кредитные карты, но и ACH. Мы обсуждаем это и подтверждаем: ACH тоже можно использовать.

А что происходит после включения автоплатежа? Как клиент его выключает? До сих пор у многих клиентов в системе не было имён пользователей и паролей. Для оплаты каждого отдельного счёта они переходили по ссылкам с токенами доступа. Можно было бы естественным образом предположить: раз у клиента появляется что-то вроде автоплатежа, теперь ему нужны имя пользователя, пароль и отдельное место, где всем этим можно управлять.

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

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

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