Почему дизайнер больше не бутылочное горлышко
Раньше запуск продукта упирался в одно: пока нет макета — нечего верстать. Один дизайнер на три проекта, очередь на неделю, а правки после первого ревью съедали ещё столько же. В 2026 году ситуация изменилась: LLM научились понимать структуру интерфейса, генерировать токены дизайн-системы и выдавать готовые фреймы, которые остаётся только собрать в Figma.
Но есть нюанс. Промт «сделай красивый дизайн» даёт мусор. Работает только инженерный подход: вы описываете ограничения, состояния, сетку и токены — и получаете результат, который не стыдно отдать в разработку. Ниже — 9 промтов, которые я использую как личный «дизайн-отдел». Каждый проверен на реальных задачах: от лендинга до внутренней админки.
Важно понимать границы: AI не нарисует вам уникальную иллюстрацию и не заменит исследования пользователей. Но рутину — сетки, состояния компонентов, тексты ошибок, структуру экранов — он закрывает полностью.
1. Аудит и структура: разбор ТЗ в информационную архитектуру
Задача: превратить сырое описание продукта в карту экранов до того, как открывать Figma.
Промт:
Ты — senior product designer. Вот описание продукта: [вставь 3-5 предложений].
Составь информационную архитектуру:
1. Список экранов с приоритетом (must-have / nice-to-have).
2. Для каждого экрана — главная задача пользователя в одном предложении.
3. Навигационная модель (какие экраны связаны и как).
4. Три риска UX, которые нужно проверить на прототипе.
Формат: таблица + список. Без общих слов, только конкретика под мой продукт.
Пример: для сервиса бронирования переговорок модель выдала 7 экранов, из которых 3 оказались «nice-to-have» — их я выкинул ещё до дизайна. Экономия — два дня работы.
2. Дизайн-токены: фундамент системы в одном запросе
Задача: получить палитру, типографику и отступы в виде готового JSON для Variables в Figma.
Промт:
Сгенерируй дизайн-токены для [продукт, тон: строгий/дружелюбный] в формате JSON.
Нужны: color (primary, secondary, surface, error, warning, success — по 5 оттенков),
typography (размеры 12-48, line-height, вес), spacing (шкала 4px), radius, shadow.
Требования: контраст текста на фоне не ниже 4.5:1 по WCAG 2.1 (ссылка: w3.org/WAI/WCAG21).
Дай hex-коды и поясни, где какой токен применять.
Пример: полученный JSON импортируется в Figma через плагин Tokens Studio — переменные создаются автоматически, руками ничего вбивать не нужно. Проверить контраст можно через WebAIM Contrast Checker.
3. Компонент с состояниями: кнопка, которая не сломается
Задача: описать компонент так, чтобы у него были все состояния и варианты.
Промт:
Спроектируй компонент [button / input / card] для Figma.
Опиши: варианты (primary, secondary, ghost), размеры (sm, md, lg),
состояния (default, hover, focus, active, disabled, loading),
правила отступов внутри, поведение при длинном тексте.
Выдай в виде таблицы: вариант × состояние → визуальные изменения (цвет, тень, border).
Учти доступность: видимый focus-ring минимум 2px.
Пример: таблица «вариант × состояние» — это буквально карта Variants в Figma. Я копирую её в компонент и получаю 36 вариантов кнопки за 15 минут вместо часа.
4. Тексты интерфейса: микро-копирайтинг без «Ой, что-то пошло не так»
Задача: написать тексты для всех состояний экрана.
Промт:
Напиши микротексты для экрана [название] продукта [описание].
Нужны: заголовок, подзаголовок, placeholder для 3 полей, текст кнопки,
сообщение об успехе, 3 варианта ошибки (валидация, сеть, сервер), пустое состояние.
Тон: [дружелюбный/формальный]. Ошибки — без обвинений пользователя, с подсказкой, что делать.
Длина: заголовок до 6 слов, кнопка до 3 слов.
Пример: пустое состояние для списка задач модель выдала как «Пока пусто. Создайте первую задачу — займёт 10 секунд». Конверсия в создание выросла — люди перестают бояться пустого экрана.
5. Wireframe-описание: экран до пикселей
Задача: получить текстовый каркас экрана для сборки в Figma.
Промт:
Опиши wireframe экрана [название] для десктопа 1440px.
Формат: блоки сверху вниз с указанием сетки (12 колонок, gutter 24px),
высоты блоков, вложенности и приоритета контента (что видно первым).
Укажи, какие блоки адаптируются на мобильный и как (перестройка в колонку, скрытие).
Без цветов — только структура и размеры.
Пример: такое описание читается как инструкция: «Header 80px → Hero 480px (H1 + подзаголовок + CTA) → сетка карточек 3×2…». Собираю фрейм в Figma Auto Layout за 20 минут.
6. Кликабельный прототип: логика переходов
Задача: спроектировать сценарий прототипа с состояниями.
Промт:
Спроектируй flow для [сценарий: регистрация / оформление заказа].
Для каждого шага укажи: экран, действие пользователя, триггер перехода,
что происходит при ошибке и как вернуться назад.
Выдай как прототип-спеку: экран A → (клик по кнопке) → экран B.
Отметь, где нужны модальные окна, а где — отдельные страницы.
Пример: flow онбординга из 5 шагов с веткой «пользователь уже зарегистрирован» — сразу видно, где прототип зацикливается. Такие дыры в логике до кликабельной версии обычно находят уже на тестах.
7. Ревью макета: второй взгляд без человека
Задача: найти проблемы в готовом дизайне.
Промт:
Проведи эвристическую оценку макета по Нильсену (10 эвристик, ссылка: nngroup.com/articles/ten-usability-heuristics).
Вот описание экрана: [вставь структуру или скриншот-описание].
Для каждой найденной проблемы: эвристика, серьёзность (1-3), как исправить.
Отдельно проверь: читаемость, иерархию, консистентность отступов, доступность.
Пример: на ревью формы оплаты модель поймала отсутствие индикатора прогресса и неинформативную ошибку валидации — классика, которую глаз дизайнера замыливает.
8. Handoff: спецификация для разработчика
Задача: превратить макет в ТЗ для фронтенда.
Промт:
Сделай handoff-спецификацию для экрана [название].
Укажи: токены (цвета, отступы, радиусы), брейкпоинты (320/768/1440),
поведение компонентов, анимации (длительность, easing), edge-cases (длинный текст, пустые данные, загрузка).
Формат: таблица «элемент → свойство → значение → примечание».
Пример: разработчик получает таблицу и не задаёт ни одного вопроса про отступы. Спор «а тут 16 или 24?» исчезает — цифры зафиксированы.
9. Проверка на консистентность системы
Задача: убедиться, что новые экраны не выпадают из дизайн-системы.
Промт:
Сверь описание нового экрана [вставь структуру] с дизайн-токенами [вставь JSON из промта №2].
Найди расхождения: нестандартные отступы, цвета вне палитры, размеры шрифтов не из шкалы, компоненты, которых нет в системе.
Выдай список нарушений с предложением заменить на существующий токен.
Пример: так я поймал, что в трёх экранах админки использовался оттенок серого, которого нет в системе. Мелочь, но именно из таких мелочей рождается «дизайн, собранный из разных кусков».
Что в итоге
Связка из этих промтов закрывает полный цикл: от сырого ТЗ до handoff-спецификации. Мой реальный таймлайн на небольшой сервис: структура и токены — полдня, экраны и компоненты — два дня, прототип и ревью — день. Раньше это была неделя с дизайнером в очереди.
Но честное предупреждение: AI не принимает продуктовых решений. Он не знает вашу аудиторию и не проведёт интервью. Промты дают скорость и консистентность, а смысл — всё ещё ваша работа. Начните с промта №1 и №2: структура и токены дают максимум эффекта на старте. Дальше система собирается почти сама.
Комментарии