# Пример

Канонический адрес: https://producthub.live/shape-up/primer
Автор публикации: Product Hub (https://producthub.ru). Опубликовано: 2026-10-13. Обновлено: 2026-10-13.
Книга: Ryan Singer (Райан Сингер), «Shape Up: Stop Running in Circles and Ship Work that Matters», Basecamp, 2019. Оригинал: https://basecamp.com/shapeup

Перевод на русский, часть 1 «Подготовить выполнимый проект», глава 3 «Найти устройство решения». Оглавление: https://producthub.live/shape-up

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

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

![Первое место: счёт](https://producthub.live/assets/books/shape-up/light/p028-01.webp)

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

![Кнопка включения автоплатежа под названием места «Счёт»](https://producthub.live/assets/books/shape-up/light/p028-02.webp)

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

![Связь от кнопки на счёте к настройке автоплатежа](https://producthub.live/assets/books/shape-up/light/p028-03.webp)

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

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

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

![Настройка автоплатежа: данные карты, логотип финансовой организации и переход к подтверждению](https://producthub.live/assets/books/shape-up/light/p029-01.webp)

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

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

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

![Вариант с дополнительным вопросом об оплате текущей задолженности](https://producthub.live/assets/books/shape-up/light/p029-02.webp)

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

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

![Автоплатёж как опция на существующем экране оплаты счёта](https://producthub.live/assets/books/shape-up/light/p030-01.webp)

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

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

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

![Отключение автоплатежа на странице клиента со стороны того, кто выставляет счета](https://producthub.live/assets/books/shape-up/light/p030-02.webp)

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

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

Далее: [Эскизы толстым маркером](https://producthub.live/shape-up/eskizy-tolstym-markerom)