Как дизайнеру самому задеплоить продукт: от Figma до рабочей ссылки без разработчика

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

Знакомо? И вот тут начинается интересное: значительная часть того, что дизайнер раньше «отдавал в разработку», сегодня можно задеплоить самому. Не код руками, не вёрстку с нуля — а собрать рабочий продукт через связку Figma, AI-генерации, no-code и пары кнопок в облачном хостинге. И получить настоящую ссылку, по которой можно открыть продукт с телефона в метро.

Это не про «дизайнер заменяет разработчика». Это про то, что между макетом и пользователем больше не обязан стоять отдельный человек, если задача того не требует. Лендинг, прототип для теста гипотезы, портфолио, внутренний инструмент, MVP для инвестора — всё это дизайнер может довести до прод-ссылки сам.

## Почему это вообще стало возможным

Раньше «сам задеплоить» означало уметь верстать, настраивать сервер, разбираться с DNS и переменными окружения. Сейчас стек выглядит иначе.

• Макет в Figma можно превратить в код через AI-инструменты или скопировать как готовый компонент.
• Хостинг — это не сервер, а git push (или вообще drag-and-drop папки).
• Домен подключается за 5 минут через интерфейс, а не правкой конфигов.
• Базы данных, авторизация, формы — берутся как сервис, без бэкенда.

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

### Что реалистично задеплоить самому

Не всё подряд. Реалистичная зона ответственности дизайнера сегодня:

• Лендинги и промо-страницы — без вопросов.
• Прототипы для пользовательских тестов с реальными данными.
• Портфолио и личные сайты.
• Простые SaaS-MVP: форма входа, дашборд, CRUD-интерфейс.
• Внутренние инструменты команды (мини-CRM, трекеры, чеклисты).
• Документация, дизайн-системы как сайты.

Что пока стоит оставить разработчикам: сложная бизнес-логика, интеграции с платёжными системами под нагрузкой, всё, где цена ошибки — деньги или персональные данные пользователей.

### Анти-паттерн: «я задеплою прод за выходные»

Самая частая ловушка — переоценить сложность продукта. Дизайнер видит интерфейс из 12 экранов и думает: «соберу за вечер». А потом выясняется, что между экранами 4 — расчёт, который должен совпадать с биллингом, и роли пользователей с разными правами.

Перед тем как браться, ответь себе:

• Это интерфейс или продукт с состоянием?
• Кто отвечает, если данные потеряются?
• Что будет, если завтра придут 1000 пользователей?

Если на любой вопрос нет ясного ответа — это не задача «деплою сам». Это задача «делаю прототип, дальше нужен разработчик».

## Шаг 0: что должно быть в Figma до того как нажимать «экспорт»

Главная причина, по которой автоматический перенос макета в код выходит уродливым — макет не был для этого готов. AI-инструменты и плагины не делают магии. Они работают с тем, что есть в файле.

### Чеклист готовности файла

• Все экраны на Auto Layout, без «голых» фреймов.
• Цвета и шрифты вынесены в стили или переменные, а не вбиты руками.
• Компоненты — это компоненты, а не сгруппированные слои.
• Слои названы по-человечески: card-product, а не Rectangle 482.
• Состояния (hover, active, disabled, empty) собраны в вариантах, а не на разных артбордах.
• Сетка и брейкпоинты обозначены: что происходит на 1440, 768, 375.

### Вопросы для самопроверки перед экспортом

• Если убрать один блок — поедут ли соседние корректно?
• Заменил текст на длинный — карточка не сломалась?
• Открыл макет на телефоне — читается или превратилось в кашу?

Файл, который проходит эти три вопроса, переносится в код почти без боли. Файл, который не проходит — после экспорта потребует столько правок, что проще нанять верстальщика.

### Короткий итог раздела

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

## Шаг 1: выбираем стек под задачу, а не под хайп

Самая дорогая ошибка на старте — выбрать инструмент, потому что про него все пишут. Через неделю выясняется, что для лендинга ты тащишь Next.js с базой данных, а для SaaS-прототипа взял конструктор, в который не лезет авторизация по магической ссылке.

Перед выбором ответь на четыре вопроса:

• Это статика (контент не меняется от пользователя) или приложение с состоянием?
• Нужна ли база данных и логин?
• Будет ли это переходить разработчику, или это конечная точка?
• Какой у тебя реальный навык кода — ноль, читаю и правлю, пишу простое?

Дальше — грубая карта, без религии.

Задача	Что брать	Когда не брать
Лендинг, портфолио, документация	Framer, Webflow, или статика на Vercel/Netlify	Если завтра нужна сложная админка
Прототип с фейковыми данными	Figma Make, v0, Lovable	Если результат пойдёт в прод как есть
MVP с логином и базой	Lovable / Bolt + Supabase	Если в команде уже есть фронт-стек
Внутренний инструмент	Retool, Glide, Softr	Если данные нельзя выносить в SaaS

Главный фильтр — куда это поедет дальше. Прототип на Framer нельзя «доразработать» в боевой продукт, его придётся переписать. Это нормально, если ты об этом знаешь заранее.

## Шаг 2: от макета к коду без катастрофы

AI-генерация из Figma выглядит как магия только в демо. На реальном файле начинается то, ради чего написан Шаг 0.

### Рабочий процесс, который не разваливается

1. Берёшь один экран, не весь проект. Самый показательный, с компонентами и состояниями.
2. Прогоняешь через генератор (Figma Make, Anima, плагин, MCP-коннектор — что выбрал).
3. Открываешь результат и сверяешь не пиксели, а структуру: где Auto Layout превратился в flex, где компонент остался компонентом, где всё расплылось в дивы.
4. Чинишь источник в Figma, если структура поехала. Не правишь код — правишь макет и генеришь заново.
5. Только когда один экран ведёт себя предсказуемо — масштабируешь на остальные.

Если правишь код руками с первого экрана — ты только что нанял себя верстальщиком на проект без оплаты.

### Что обычно ломается

• Длинные тексты вылезают за карточки, потому что в макете высота была зафиксирована.
• Иконки превращаются в png вместо svg, потому что лежали как картинки.
• Тёмная тема не работает, потому что цвета не были переменными.
• На мобиле всё налезает, потому что брейкпоинт был «нарисован», а не задан.

Все четыре проблемы лечатся не в коде, а в Figma. Это и есть главный сдвиг в голове: макет теперь — это исходник, а не картинка для согласования.

## Шаг 3: деплой и домен

Технически это самый простой шаг, и именно поэтому на нём застревают — ждут подвоха.

• Заводишь аккаунт на Vercel или Netlify, подключаешь репозиторий (или перетаскиваешь папку).
• Жмёшь deploy. Получаешь временный домен вида project-x.vercel.app.
• Покупаешь домен у любого регистратора, в настройках хостинга добавляешь его и копируешь DNS-записи к регистратору.
• Ждёшь 10–60 минут. Готово.

### Чеклист «прежде чем дать ссылку кому-то»

• Открыл свою ссылку в режиме инкогнито — всё работает без твоего логина?
• Открыл на телефоне в 4G, не в офисном вайфае?
• Проверил favicon, title страницы и og-картинку для шеринга в мессенджерах?
• Формы реально шлют данные туда, куда обещают, а не в console.log?
• 404 — это нормальная страница, а не белый экран?

## Типичные ошибки на ревью

На внутреннем ревью у задеплоенных дизайнером проектов всплывает один и тот же список:

• Прод выглядит как макет, а ведёт себя как прототип. Кнопки красивые, но половина никуда не ведёт. Лучше выпилить нерабочие, чем оставить.
• Нет ни одного состояния загрузки и ошибки. Всё хорошо, пока интернет хороший.
• Секреты и ключи API лежат в коде фронта. Любой через DevTools их видит.
• Аналитики нет вообще. Ты не узнаешь, работает ли то, что выкатил.
• Нет способа откатиться. Сломал — чинишь в проде на живых пользователях.

### Вопросы для самопроверки перед тем, как показать наружу

• Что увидит пользователь, если сервер ответит ошибкой?
• Где хранятся данные форм и кто к ним имеет доступ?
• Если завтра ты заболеешь — кто-то сможет это поддерживать?
• Что именно ты будешь измерять, чтобы понять, сработало или нет?

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

### Короткий итог

Деплой дизайнером — это не «нажать кнопку», а собрать цепочку: чистый макет → понятный стек под задачу → предсказуемая генерация → честная проверка на проде. Сломанное звено в любом месте превращает всю работу в демо, которое нельзя показать.

## Когда подключается команда: дизайнер деплоит не в вакууме

В одиночку выкатить лендинг или внутренний инструмент — нормальная история. Но как только продукт становится частью основного флоу компании, появляются разработчики, продакт, безопасники, юристы. И тут дизайнер-деплоер либо встраивается в процесс, либо его деплой тихо переезжает на «нормальный» стек, а работа остаётся в виде референса.

### Как договориться с разработчиками заранее

• Покажи стек до того, как начал кодить. Не после. На ревью стека команда либо одобрит, либо предложит свой — и это дешевле, чем переписывать.
• Спроси, где хранится прод-репозиторий и кто имеет доступ к деплою. Если ответ «у Серёжи на компе» — это не команда, это бутылочное горлышко.
• Уточни, что считается за «прод»: основной домен, поддомен, отдельный сервис. Лендинг на поддомене обычно никого не пугает, а вот развёртывание на корневом домене требует согласований.
• Договорись, кто чинит, если упало в выходные. Если никто — выкатывать в пятницу нельзя.

### Анти-паттерн: «я просто покажу, а потом мы перепишем»

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

## AI-инструменты: где они реально помогают, а где создают долг

AI сейчас умеет вытащить из макета приличный React-компонент, переписать его под нужный фреймворк, накидать состояния. Это сильно ускоряет рутину. Проблема в том, что AI охотно генерирует код, который выглядит правильно и работает на одном экране, но разваливается на масштабе.

### Где AI экономит время без долга

• Перевод статичного макета в адаптивную вёрстку одного экрана.
• Генерация типовых компонентов: формы, таблицы, карточки.
• Подбор анимаций и микроинтеракций по описанию.
• Объяснение чужого кода, когда надо понять, что делает кусок из репозитория.

### Где AI создаёт скрытый долг

• Архитектура проекта: AI охотно дублирует логику в десяти местах, потому что не видит весь репозиторий целиком.
• Работа с состоянием и данными: сгенерированный код часто хранит всё в локальных стейтах, и при росте флоу это превращается в кашу.
• Безопасность: AI спокойно подставит твой ключ в публичный код, если ты его сам туда вписал в промпте.
• Доступность: сгенерированная вёрстка редко проходит проверку по контрасту, фокусу, ARIA — это надо чинить руками.

### Правило для MCP-коннекторов и Figma-плагинов

Чем плотнее AI интегрирован с макетом, тем важнее чистота макета. Если на вход идёт хаос из абсолютных позиций и сгруппированных слоёв с именами Group 47, на выходе будет хаос в коде. MCP не магия, он усиливает то, что уже есть в Figma.

## Как проверять качество перед тем, как защищать решение

Прежде чем нести ссылку на ревью команде, прогони её сам по короткому списку. Это не про перфекционизм, это про то, чтобы не получить разнос на встрече по предсказуемым вещам.

• Lighthouse в Chrome: Performance, Accessibility, Best Practices, SEO. Цифры не обязаны быть зелёными везде, но ты должен понимать, почему они не зелёные.
• Прошёл флоу с клавиатуры, без мыши. Если фокус теряется или модалка не закрывается по Esc — это баг.
• Проверил с выключенным JS хотя бы первый экран. Не должно быть полностью белой страницы.
• Открыл в Safari, не только в Chrome. Половина багов с вёрсткой живёт именно там.
• Замерил вес страницы. Если первый экран весит как фильм, надо чинить картинки и шрифты.
• Проверил, что аналитика реально шлёт события, а не молчит.

## Как объяснять решение команде

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

### Структура объяснения, которая работает

1. Задача и срок. «Нужен лендинг под запуск через две недели, разработчики заняты основным продуктом».
2. Что рассматривали. Коротко: Framer, Webflow, кодовый стек. Почему выбрали именно этот.
3. Границы решения. Что этот деплой умеет, а что нет. До какого момента он живёт в текущем виде.
4. План передачи. Кто и когда забирает это в основной репозиторий, если продукт взлетит.
5. Риски и как они закрыты. Секреты, бэкапы, аналитика, откат.

### Вопросы, к которым стоит готовиться

• Что произойдёт, если ты уйдёшь в отпуск, а сайт упадёт?
• Где лежат данные пользователей и под каким соглашением?
• Сколько это стоит в месяц и кто платит за хостинг и домен?
• Если завтра нагрузка вырастет в десять раз — что сломается первым?

Если на эти вопросы у тебя есть короткий ответ — деплой воспринимается как инженерное решение, а не как самодеятельность. Если нет — команда права, что переживает.

### Короткий итог

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

## Финальный чеклист: от Figma до живой ссылки

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

### До деплоя

• В Figma слои названы по-человечески, автолейаут на ключевых секциях, компоненты вынесены, а не скопированы пять раз.
• Есть отдельная dev-ветка или превью-окружение, мастер не катается напрямую с ноутбука.
• Все ключи, токены и пароли лежат в переменных окружения хостинга, а не в коде и не в репозитории.
• Картинки сжаты, шрифты подгружаются с font-display: swap или аналогом, первый экран не тянет мегабайты.
• Метатеги, favicon, OG-картинка проверены через превью соцсетей, а не «потом доделаем».
• Есть страница 404 и понятное поведение при пустых состояниях.

### В момент деплоя

• Домен подключён, HTTPS работает, редирект с www на без-www (или наоборот) настроен один раз и навсегда.
• Прод и превью-окружения визуально отличаются — хотя бы баннером, чтобы никто не правил «прод как песочницу».
• Откат до прошлой версии делается одной кнопкой, и ты это проверил, а не просто прочитал в доках.

### После деплоя

• Аналитика шлёт реальные события, а не нули. Проверено в режиме инкогнито.
• Формы доходят до получателя: письмо, Telegram-бот, CRM — что бы там ни было.
• Есть бэкап контента и БД, и ты знаешь, где он лежит.
• В календаре стоит напоминание о продлении домена и сертификата.

## Анти-паттерны, которые ломают даже хороший макет

### «Я задеплою, а доступность потом»

«Потом» не наступает. Если изначально не заложить нормальные контрасты, фокус-стили и семантику, переделывать придётся весь шаблон. Доступность дешевле на старте, чем поверх готового сайта.

### Хостинг на личном аккаунте

Сайт компании висит на твоём личном GitHub и твоей личной карте в Vercel. Уходишь в отпуск — никто не может ничего поправить. Уходишь из команды — начинается квест с восстановлением доступов. Любой прод должен жить на организационном аккаунте с двумя владельцами.

### Один человек знает всю магию

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

### Бесконечный «временный» лендинг

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

### Деплой без аналитики

Сайт работает, но ты не знаешь, сколько людей до него доходит, откуда и где отваливаются. Через месяц у тебя нет данных, чтобы защитить ни редизайн, ни сам факт существования страницы.

## Вопросы для ревью самому себе

Перед тем как закрыть задачу, прогони по списку. Если на любой вопрос ответ «надо подумать» — задача ещё не закрыта.

• Что увидит человек, открывший сайт с медленного мобильного интернета на пятилетнем телефоне?
• Если убрать тебя из проекта на месяц, кто и по какой инструкции выкатит правку в шапке?
• Какие три метрики ты будешь смотреть через неделю, чтобы понять, работает ли это вообще?
• Что сломается в первую очередь: вёрстка, формы, аналитика, домен, оплата? Есть ли у каждого пункта ответственный?
• Если завтра придёт юрист и спросит про cookies, согласия и хранение данных — ты знаешь, что показать?

## Короткий практический итог

Деплой дизайнером — это не «обошёлся без разработчиков», а «взял на себя инженерную ответственность за конкретный кусок продукта». Всё остальное — следствие. Инструмент выбирается под задачу и срок жизни, чеклист закрывает предсказуемые риски, анти-паттерны ловятся до того, как становятся легаси, а команда получает не «сайт от дизайнера», а понятное решение с границами, владельцем и планом передачи. Это и есть разница между разовым подвигом и нормальной рабочей практикой.