Стратегия · 12 марта 2026 г. · 2 мин

Почему продукту нужна архитектура до первого экрана

Как сократить переделки и сохранить смысл между дизайном и разработкой.

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

Команды часто начинают с визуала: герой, сетка, анимация. Потом выясняется, что оффер другой, роли не те, а сценарии пользователя не сходятся с навигацией. Дизайн перерисовывают, код выкидывают, запуск сдвигается. Это не «итерации». Это отсутствие архитектуры.

Что мы фиксируем до макета

До Figma нужна короткая, но жёсткая рамка:

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

Без этого экран становится декорацией. С этим — контрактом. Дизайнер и инженер спорят уже не о вкусе, а о том, держит ли интерфейс смысл.

Где обычно теряется смысл

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

Архитектура до первого экрана — это общий словарь. Если в продукте есть «разбор», «сборка» и «релиз», эти слова должны жить в навигации, в админке и в аналитике одинаково.

Как мы это делаем

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

Если команда пропускает этот слой, она платит позже: двойной версткой, сломанными стейтами, «быстрыми» костылями, которые нельзя выкинуть. Если не пропускает, первый экран начинает работать как обещание, которое продукт способен сдержать.