Превратил идею в продуктовый дизайн и проверенные прототипы.

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

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

Продукт формировался в процессе. Новые решения меняли соседние сценарии. Каждое дополнение нужно было проверять на согласованность со всем остальным.

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

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

Конфиденциальность. Название продукта, механики и бизнес-логика не раскрываются, поэтому в кейсе описан процесс, а не продукт.

Начал с ролей, задач пользователей, анализа аналогов и карт сценариев. Показ строил вокруг трёх сквозных сценариев, а не вокруг обхода функций. Затем проработал вайрфреймы и состояния приложения и веб-сервиса в Figma и собрал из них кликабельные прототипы.

Claude использовал на каждом шаге после макетов. Один агент дорисовывал недостающие экраны и состояния на отдельной странице черновика, не трогая оригиналы. Другие собирали прототип по разделам. Третьи проходили его как разные пользователи со скриншотами каждого шага. Независимый аудит находил пустые состояния с чужими данными, заглушки вместо переходов и наложения на мобильном. Исправления возвращались в макеты, и прототип пересобирался. Решения выбирал и проверял сам.

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

Узлы 01–03 собирают продукт: роли и сценарии, вайрфреймы и состояния, кликабельный прототип. Узел 04 проверяет его прохождением по сценариям; найденное возвращается в узел 02. Узел 05 показывает результат заказчику и подводит к решению.

Подпись к схеме: Рис. 1. От ролей и сценариев до показа заказчику: проверка возвращает правки в макеты.

Пометка на схеме: Источник — Figma

Решение 1. Прототип из кадров, а не из кода

Первый подход: собирать каждый экран прототипа вёрсткой по макету. За два дня один раздел дошёл до 95% сходства, а хвост мелких правок не заканчивался. Я переключился на другой способ: экспорт кадров из Figma и невидимые зоны нажатия поверх них под одним движком состояний. Точность по картинке полная, экран занимает минуты, правка сводится к повторному экспорту.

Принцип: точность нужна там, где по ней что-то строят. Код прототипа никто не переиспользует, потому что разработчик строит интерфейс по Figma.

Компромисс: прототип остаётся картинкой с переходами, а не живым интерфейсом. Для задач показа и проверки сценариев этого достаточно.

Подпись к иллюстрации (необязательна): Рис. 2. Прототип из кадров: макет, экспорт, зоны нажатия, движок состояний.

Решение 2. Один сквозной сюжет и один движок на роли и устройства

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

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

Краевой случай: демонстрационные данные одного пользователя попадали к новому. Для каждого «заполненного» экрана заранее проектировал вариант «пусто» и проверял это автоматически.

Компромисс: заметно больше работы с состояниями на этапе макетов. Зато у переходов нет разрывов, а проверка находит их до встречи.