РУКОВОДСТВО

Лучшие практики создания дизайн-макетов, инструкций для ИИ и «человечных» дизайн-систем

Версия: 1.0 Назначение: сайты, веб-приложения, CRM, CMS, дизайн-макеты в pen.dev/Figma и AI-assisted development.

Содержание

Главная идея
Почему дизайн выглядит «сгенерированным»
Процесс создания сложного человеческого дизайна
Как писать инструкции для ИИ
Архитектура дизайн-системы
Токены и переменные
Компоненты и состояния
Работа с AI в Figma/pen.dev
Проверка качества
Практический workflow для проектов Юрия
Шаблоны инструкций и чек-листы
Источники

ГЛАВНАЯ ИДЕЯ

ИИ хорошо производит варианты, но плохо понимает, почему один вариант уместен именно для этого бизнеса. Поэтому задача дизайнера — не просить «сделай красиво», а передать ИИ контекст, ограничения, вкусовые ориентиры и критерии качества.

Хороший дизайн — это не набор эффектов. Это согласованная система решений:

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

Ключевой принцип:

ИИ генерирует варианты, человек задаёт направление, ограничения и критерии отбора.

Нужно разделять три артефакта:

Бриф — зачем создаётся продукт и для кого.
Визуальная система — цвет, типографика, ритм, формы, изображения.
Инструкция для агента — как применять систему и чего не делать.
ПОЧЕМУ ДИЗАЙН ВЫГЛЯДИТ «ИИШНЫМ»

Типичные признаки AI-slop:

одинаковые карточки с одинаковыми скруглениями;
фиолетово-синий градиент без связи с брендом;
Inter/Roboto везде без типографического характера;
огромный hero с абстрактными шарами и фразой «будущее начинается здесь»;
чрезмерное количество glassmorphism, свечения и теней;
одинаковая сетка 3 карточки + 3 карточки;
много декоративных элементов, которые не помогают задаче;
тексты-заглушки вместо настоящего контента;
идеальная симметрия и отсутствие визуальной иерархии;
каждый блок выглядит так, будто создан независимо;
отсутствие реальных состояний: loading, empty, error, disabled;
красивый desktop, который ломается на мобильном;
изображение используется как декор, а не как часть смысла.

Причина обычно не в самой модели, а в плохом входе. Запрос «сделай современный сайт» не содержит ни контекста, ни критериев, ни запретов.

ПРОЦЕСС СОЗДАНИЯ СЛОЖНОГО ЧЕЛОВЕЧЕСКОГО ДИЗАЙНА

3.1. Исследовать контекст

До макета зафиксировать:

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

Для CRM важнее скорость работы и плотность данных. Для сайта компании — доверие, доказательства и понятный контакт. Для CMS — редакционный процесс и читаемость.

3.2. Найти собственную визуальную территорию

Не брать «стиль вообще». Выбрать оси характера:

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

Затем определить 2–3 уникальных признака. Например:

тёплый бумажный фон + серьёзная serif-типографика + один глиняный CTA;
чёрный фон + Oswald + технические подписи + оранжевый акцент;
светлая промышленная палитра + крупные номера + табличная структура.

3.3. Сначала композиция, потом декор

Порядок:

карта страниц;
иерархия контента;
wireframe;
типографика и сетка;
реальные изображения и тексты;
компоненты;
motion;
микро-детали.

Не начинать с градиента, тени или анимации.

3.4. Использовать реальные материалы

ИИ должен работать с реальными:

названиями товаров;
телефонами и адресами;
изображениями;
характеристиками;
статусами CRM;
сообщениями об ошибках;
длиной русского текста.

Текст и изображения влияют на композицию. После замены lorem ipsum макет часто разваливается — это признак, что дизайн не проверялся на реальном контенте.

3.5. Создавать намеренную нерегулярность

«Человечность» — не случайный хаос. Это контролируемое нарушение однообразия:

один нестандартный размер карточки;
асимметричная hero-композиция;
переменная плотность секций;
editorial-вынос цитаты;
редкий, но осмысленный угол или радиус;
разные роли поверхностей вместо одинаковых карточек;
один signature-приём, повторяющийся в нужных местах.

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

3.6. Делать варианты, но выбирать один

Попросить ИИ создать 2–3 направления с объяснением различий. Не объединять всё сразу. Затем выбрать один принцип и довести его до системы.

КАК ПИСАТЬ ИНСТРУКЦИИ ДЛЯ ИИ

4.1. Структура хорошей инструкции

Роль агента.
Цель и пользователь.
Контекст проекта.
Источники истины.
Визуальная идея.
Токены.
Правила композиции.
Правила компонентов.
Что запрещено.
Формат результата.
Проверки качества.
Поведение при неопределённости.

4.2. Пример плохого запроса

Сделай красивый современный лендинг для компании.

4.3. Пример хорошего запроса

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

Используй тёмный тёплый фон #0D0D0B, Oswald для крупных заголовков, IBM Plex Sans для текста, JetBrains Mono для технических подписей. Акцент #FF8400 используй только для главного действия. Не использовать фиолетовые градиенты, glassmorphism, случайные иконки и декоративные карточки без функции.

Сначала опиши структуру страницы и визуальную иерархию. Не добавляй разделы, тексты или кнопки, которых нет в ТЗ. Все тексты оставь дословно. Перед кодом перечисли неясности.

4.4. Формулировать правила через «если — то»

Плохо: «делай интерфейс аккуратным».

Хорошо:

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

4.5. Разделять обязательное и желательное

ОБЯЗАТЕЛЬНО:

не менять тексты;
использовать существующие токены;
соблюдать mobile-first;
не добавлять элементы без ТЗ.

ЖЕЛАТЕЛЬНО:

предложить один вариант улучшения;
добавить hover, если он предусмотрен системой;
предложить альтернативную композицию отдельно.

4.6. Инструкция должна описывать причины

Агент лучше применяет токен, если знает его смысл:

color/action/primary — единственное главное действие на экране;
surface/raised — для контента, требующего отделения от холста;
text/muted — только вторичная информация, не инструкции;
space/section — вертикальный ритм между смысловыми разделами.

Одних чисел недостаточно: нужно описывать роль и ограничения.

4.7. Источники истины

Явно указать приоритет:

ТЗ > утверждённый макет > дизайн-система > существующий код > предложение ИИ.

При противоречии агент не должен придумывать решение молча. Он должен показать противоречие и предложить вариант отдельно.

АРХИТЕКТУРА ДИЗАЙН-СИСТЕМЫ

Дизайн-система — это не только набор кнопок. Она включает:

foundations;
дизайн-токены;
компоненты;
паттерны взаимодействия;
контентные правила;
accessibility;
документацию;
governance и правила изменений.

5.1. Foundations

Описать:

цвет;
типографику;
spacing;
сетку;
размеры контейнеров;
радиусы;
границы;
elevation;
motion;
иконки;
изображения;
breakpoints.

5.2. Трёхуровневая модель токенов

Primitive tokens — необработанные значения: orange-500, space-4.
Semantic tokens — роль: color/action/primary, color/surface/page.
Component tokens — применение: button/primary/background.

Компоненты должны использовать semantic tokens, а не случайные hex-значения.

5.3. Документация токена

Для каждого значения описать:

название;
значение;
роль;
когда применять;
когда не применять;
контраст;
светлый/тёмный режим;
пример.

5.4. Naming

Названия должны описывать роль, не внешний вид:

Хорошо: color/text/primary, surface/danger, space/layout/section.

Плохо: blue-text, big-round-button, left-card.

Причина: визуальный параметр может измениться, а роль остаётся.

5.5. Компонент — это контракт

Документация компонента должна содержать:

назначение;
anatomy;
props/variants;
состояния;
accessibility;
do/don’t;
примеры;
когда использовать другой компонент;
ограничения контента;
соответствие коду.

ТОКЕНЫ И ПЕРЕМЕННЫЕ

Пример semantic tokens:

color:
  surface:
    page: '#F0EEE6'
    default: '#FAF9F5'
    featured: '#F5E3C7'
  text:
    primary: '#141413'
    secondary: '#6F6B60'
  action:
    primary: '#D97757'
    primary-hover: '#C6613F'

typography:
  display:
    family: 'Golos Text'
    size: '61px'
    line-height: 1.05
  body:
    family: 'PT Serif'
    size: '20px'
    line-height: 1.5

shape:
  card: '24px'
  control: '8px'

spacing:
  1: '4px'
  2: '8px'
  3: '12px'
  4: '16px'
  6: '24px'
  8: '32px'

Не превращать токены в ограничение творчества. Токены задают грамматику, а не готовый макет.

Проверять:

WCAG-контраст;
читаемость кириллицы;
загрузку шрифтов;
fallback fonts;
переполнение текста;
переключение тем;
согласованность Figma/pen.dev и CSS.

КОМПОНЕНТЫ И СОСТОЯНИЯ

7.1. Состояния обязательны

Для интерактивного компонента описать:

default;
hover;
focus-visible;
pressed;
disabled;
loading;
error;
success;
empty;
mobile.

7.2. Не создавать компоненты слишком рано

Сначала выявить повторяющиеся паттерны. Если две карточки отличаются только данными — один компонент с данными. Если отличаются сценарием и поведением — возможно, это разные компоненты.

7.3. Не делать «универсальный компонент на всё»

Компонент с десятками флагов (isSmall, isDark, isSpecial, isCompact, showIcon, reverse, legacy) быстро становится неуправляемым. Лучше несколько ясных вариантов с понятными контрактами.

7.4. Accessibility — часть дизайна

видимый focus;
правильные button и a;
label у полей;
aria только когда нужна;
порядок клавиатуры;
контраст;
текст ошибки рядом с полем;
не полагаться только на цвет;
reduced motion;
alt для изображений.

AI В FIGMA И PEN.DEV

8.1. Давать агенту структурированный контекст

Figma рекомендует документировать:

назначение компонента;
когда его использовать;
какие состояния поддерживает;
чем он отличается от похожих;
смысл переменных и стилей;
ограничения применения.

Агент видит внешний вид компонента, но без документации может не понять его роль.

8.2. Структура библиотеки

Использовать группы с /:

Color/Surface/Page
Color/Action/Primary
Typography/Display/Large
Component/Button/Primary
Component/Button/Primary/Hover

Имена должны быть одинаковыми в макете и коде.

8.3. Для .pen-файлов

извлекать весь текст дословно;
не менять структуру секций;
брать цвета и шрифты из файла;
не добавлять отсутствующие элементы;
проверять version;
не использовать rectangle с children;
проверять итоговый render;
сохранять предложения ИИ отдельно от результата.

8.4. Принцип «макет — источник истины»

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

ПРОВЕРКА КАЧЕСТВА

9.1. Design review

Проверить:

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

9.2. UX review

Проверить:

понимает ли новый пользователь, что делать;
видит ли он следующий шаг;
что происходит после действия;
можно ли отменить ошибку;
есть ли empty/error/loading;
не скрыта ли важная информация;
насколько быстро выполняется частая операция.

9.3. Responsive review

Проверить минимум:

320–375 px;
768 px;
1024 px;
1440 px.

Не просто уменьшать desktop. На мобильном могут меняться порядок, приоритет, плотность и способ взаимодействия.

9.4. Визуальная проверка через браузер

Процесс:

собрать проект;
открыть реальные URL;
сделать screenshots;
проверить desktop и mobile;
сравнить с макетом;
исправить расхождения;
повторить после исправления.

Код без визуального просмотра не считается проверенным.

ПРАКТИЧЕСКИЙ WORKFLOW ДЛЯ ПРОЕКТОВ ЮРИЯ

10.1. До создания макета

Определить продукт, аудиторию и задачу.
Собрать реальные тексты, товары, изображения и ограничения.
Посмотреть 3–5 реальных референсов.
Зафиксировать, что берём и что не копируем.
Описать визуальную территорию.
Составить карту страниц.
Написать ТЗ нумерованными пунктами.

10.2. Перед реализацией

Извлечь токены из макета.
Составить DESIGN.md или аналогичную спецификацию.
Описать компоненты и состояния.
Проверить тексты дословно.
Зафиксировать неясности.
Показать ТЗ Юрию.
Начинать код только после сигнала.

10.3. Реализация

Создать foundations.
Сделать один эталонный экран.
Проверить его в браузере.
Выделить компоненты.
Собрать остальные страницы из компонентов.
Добавить реальные состояния.
Добавить адаптивность.
Запустить build/typecheck/tests.
Выполнить visual review.

10.4. Для Newmark

Использовать реальные локальные шрифты и изображения из AI-design-systems/pen.dev/newmark. Не заменять утверждённый дизайн случайными шаблонами. Сохранять связь между макетом, src/, токенами и deployed site.

10.5. Для CRM и CMS

Приоритеты отличаются от лендинга:

скорость частых операций;
плотность информации;
таблицы и фильтры;
права доступа;
статусы;
ошибки и восстановление;
keyboard workflow;
аудит;
импорт/экспорт.

Красивый hero не компенсирует неудобную рабочую таблицу.

ШАБЛОН ИНСТРУКЦИИ ДЛЯ ИИ

Роль

Ты — UI/UX designer и frontend engineer проекта X.

Цель

Создать [экран/компонент] для [пользователь] с задачей [задача].

Источники истины

ТЗ > утверждённый макет > DESIGN.md > существующий код > твои предложения.

Характер

[3–5 прилагательных]. Не использовать [конкретные клише].

Визуальная система

Цвета: [semantic tokens]. Типографика: [family, sizes, weights]. Сетка: [container, columns, gap]. Ритм: [spacing]. Формы: [radius/border/shadow rules]. Motion: [duration/easing/reduced-motion].

Обязательные элементы

[список]

Состояния

[default, loading, empty, error, disabled, mobile]

Ограничения

Не добавляй тексты, кнопки и блоки без ТЗ. Не меняй контент. Не создавай новые цвета. Не смешивай предложения с реализацией.

Перед кодом

Сначала перечисли файлы, план, неясности и критерии готовности. Если есть противоречие — остановись и укажи его.

После кода

Запусти build, typecheck и тесты. Проверь URL/скриншот. Верни список изменённых файлов, команды и фактические результаты.
ЧЕК-ЛИСТ «НЕ ИИШНЫЙ» ДИЗАЙН

ИСТОЧНИКИ
Google PAIR Guidebook — human-centered AI products: https://pair.withgoogle.com/guidebook/
Google PAIR — patterns: https://pair.withgoogle.com/guidebook/patterns
Microsoft HAX Toolkit — Guidelines for Human-AI Interaction: https://www.microsoft.com/en-us/haxtoolkit/ai-guidelines/
Nielsen Norman Group — AI for UX: https://www.nngroup.com/articles/ai-ux-getting-started/
Nielsen Norman Group — Generative UI: https://www.nngroup.com/articles/generative-ui/
Figma — best practices for helping AI understand a design system: https://help.figma.com/hc/en-us/articles/38978644498199-Best-practices-to-help-Figma-AI-understand-your-design-system
Material Design 3 — design tokens: https://m3.material.io/foundations/design-tokens
Atlassian Design System: https://atlassian.design/design-system
Google DESIGN.md specification: https://github.com/google-labs-code/design.md
Anthropic — Building Effective Agents: https://www.anthropic.com/research/building-effective-agents

ИТОГ

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

﻿РУКОВОДСТВО

Содержание

Роль

Цель

Источники истины

Характер

Визуальная система

Обязательные элементы

Состояния

Ограничения

Перед кодом

После кода

РУКОВОДСТВО