Claude Code /design: рисуем как Figma, только быстрее

Новый слэш-команда /design в Claude Code собирает макеты не медленнее, чем ты устанешь их описывать.

Что умеет

• Три варианта макета одновременно (генерирует параллельно)
• Редактирование через панель свойств (цвет, шрифт, отступы, стекла)
• Работает с реальным HTML/CSS (не картинка, а код)
• Экспорт — скопировал и вставил на сайт

Скорость

Раньше: неделя работы дизайнер → месяц правок → сайт живой. Теперь: вечер в Claude → четыре варианта → выбрал → завтра в продакшене.

Что это решает

• Дизайн больше не bottleneck, когда ты собираешь продукт
• Микро-продукты собираются за сутки вместо двух недель
• Не нужно договариваться с дизайнером

На что подходит

✓ Лендинги, ✓ Дашборды, ✓ Админ-панели, ✓ Маркетинг-сайты ✗ Брендирование, ✗ Логотипы

Как начать

1. Откройте Claude Code
2. /design лендинг для микро-продукта про AI, тёмная тема
3. Получите три варианта
4. Выберите лучший, отредактируйте через панель
5. Скопируйте HTML в свой сайт

Чем это отличается от Figma и no-code конструкторов

Figma даёт макет-картинку — код всё равно потом пишет кто-то отдельно, и на стыке макет/вёрстка обычно теряется точность. No-code конструкторы (Tilda, Webflow) дают готовый код, но внутри своего редактора и со своими ограничениями по стилю. /design отдаёт обычный HTML/CSS без прослойки: то, что сгенерировано, можно сразу читать, редактировать руками и переносить в любой проект — не привязан к платформе.

Где ломается

• Сложная брендированная айдентика (нестандартные иллюстрации, уникальные иконки) — модель хорошо работает с типографикой и сеткой, но не заменит художника
• Очень длинные многостраничные сайты с общей навигацией — удобнее собирать блоками и сшивать самому
• Анимации сложнее, чем hover-переходы, — для них нужен отдельный проход с уточнением деталей

Частые вопросы

/design подходит для продакшена или только для прототипов?

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

Нужно ли знать HTML и CSS, чтобы этим пользоваться?

Нет, но полезно уметь читать код, чтобы точечно поправить деталь самому, а не переписывать промпт заново из-за одной строки.

Сколько итераций обычно нужно до финального варианта?

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

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

Разница между расплывчатым «сделай лендинг покрасивее» и рабочим запросом — в конкретике на входе. Хорошая формулировка обычно включает четыре вещи: кто аудитория (кому показываем), что должно быть на странице (блоки: оффер, преимущества, форма), в каком стиле (тёмная тема, минимализм, конкретные референсы) и что является целью страницы (подписка, покупка, заявка). Без этого модель угадывает, и угадывает средне.

Пример слабого запроса: «лендинг для курса». Пример рабочего: «лендинг для онлайн-курса по фотографии, аудитория — начинающие 25–40 лет, блоки: оффер с ценой, три отзыва, программа из пяти модулей, форма записи внизу, тёмная тема с акцентным жёлтым цветом».

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

Как встроить /design в обычный рабочий процесс

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

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

Что проверить перед тем, как выкладывать макет в продакшен

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

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

Куда двигаться дальше после первого лендинга

Освоив базовый цикл (запрос → три варианта → правки через панель → экспорт), логично переходить к более сложным сценариям: многостраничным сайтам с общей навигацией, интеграцией форм с реальной отправкой данных, адаптацией одного макета под несколько языков или аудиторий. Каждый следующий шаг проще предыдущего, потому что базовый словарь запросов («тёмная тема», «блок с отзывами», «форма записи») уже понятен и не нужно объяснять модели заново, что означает каждый термин.

Главное: дизайн перестал быть преградой для быстрого запуска.