Начните не с формата
Команда часто приходит с готовым словом: нужен сайт, приложение или личный кабинет. Но сначала полезнее описать изменение, которое должно произойти после запуска.
Если человеку достаточно понять предложение и оставить заявку — это одна архитектура. Если он возвращается, хранит данные и выполняет работу — уже другая.
Один проект может сочетать несколько слоёв. Публичный сайт объясняет ценность и собирает спрос, а закрытый сервис помогает клиенту выполнить действие. Их не обязательно сводить к одному шаблону, но контент, данные и переход между слоями должны проектироваться вместе.
Запишите конечное действие простым глаголом: выбрать, рассчитать, согласовать, оплатить, назначить или проконтролировать. Так название формата перестаёт управлять решением, а команда видит реальную работу пользователя.
Три контрольных вопроса
Есть ли у пользователя состояние, которое нужно сохранять? Нужны ли разные роли и права? Возникает ли регулярный рабочий цикл? Чем больше ответов «да», тем ближе задача к продукту или платформе.
Сайт может быть большим и сложным, но его ядро — коммуникация. Ядро сервиса — действие. Ядро платформы — координация нескольких участников и данных.
Следом проверьте цену ошибки. Неправильная подпись на лендинге исправляется редактором, а неверный статус заявки может остановить процесс нескольких отделов. Чем выше цена ошибки, тем важнее журнал изменений, права доступа и негативные сценарии.
Отдельно посчитайте владельцев данных. Если карточку объекта обновляет одна редакция, достаточно понятной CMS. Если состояние меняют клиент, оператор, партнёр и интеграция, понадобится ролевая модель и единые правила переходов.
Как не переплатить за неопределённость
До визуального дизайна зафиксируйте карту ролей, ключевой сценарий и минимальный набор данных. Это позволяет честно сравнить варианты реализации и не прятать архитектурные риски внутри красивого прототипа.
Разделите обязательный первый маршрут и функции развития. MVP — не урезанная версия всего продукта, а минимальная цепочка, в которой пользователь получает ценность, а команда — сигнал для следующего решения.
Оценку лучше строить диапазоном и явно перечислять допущения. Если состав интеграции или качество исходных данных ещё неизвестны, сначала нужен технический spike либо discovery, а не точная смета с ложной уверенностью.
На выходе должен появиться короткий документ: цель, роли, ключевое действие, данные, границы первой версии, риски и критерии приёмки. Этого достаточно, чтобы осознанно выбрать сайт, сервис, платформу или их сочетание.
Формат проекта выбирают по действиям, данным и ролям пользователя — не по привычному названию из первого брифа.