Научитесь задавать подсказки для согласованного UI в React‑приложениях с помощью дизайн‑токенов и правил компонентов, чтобы AI‑сгенерированные экраны совпадали по отступам, типографике и формам.
Несогласованность интерфейса обычно проявляется в мелочах, которые кажутся непривычными при навигации. На одной странице отступы щедрые, на другой — тесно. Заголовки меняют размер, кнопки меняют форму и цвет, а одно и то же поле ввода ведёт себя по‑разному в зависимости от экрана.
Чаще всего причина дрейфа — в нескольких базовых вещах:
Это обычная ситуация, когда экраны генерируются из отдельных подсказок. Каждая подсказка — фактически новое начало, поэтому модель додумывает пропущенные решения. Даже «используй современный стиль» оставляет сотни мелких выборов: 8px или 12px, 14px или 16px для основного текста, когда показывать ошибки, как выглядит primary‑кнопка.
Можно вручную поправить две–три страницы, но это не масштабируется. В итоге вы гоняетесь за одноразовыми правками CSS, копируете стили между файлами и повторно исправляете формы. Правила находятся в вашей голове, а не в проекте.
Представьте, что вы генерируете экран входа сегодня, а профиль — завтра. Если на одном показывают ошибки только при отправке, а на другом — при уходе фокуса, пользователи заметят. Если высота primary‑кнопки меняется между экранами, приложение ощущается сшитым из разных кусков.
Последовательность становится нормой, когда каждый экран следует одной общей системе: дизайн‑токены (отступы, тип, цвета) плюс небольшой набор правил для компонентов и форм.
Дизайн‑токены — это простые именованные значения, которые вы переиспользуете по всему интерфейсу. Вместо того чтобы в каждой подсказке просить «комфортный padding», вы используете токен вроде space-4. Вместо «слегка скруглённый» — radius-md. Имя остаётся стабильным, даже если позже вы измените, чему оно соответствует.
Токены — это набор решений, которые вы хотите, чтобы все экраны разделяли. Они убирают вкус и догадки — а именно это вызывает дрейф при генерации или создании новых страниц.
Типичные токены покрывают отступы, типографику, цвета, форму и небольшое количество elevation. Практический выигрыш: заголовок всегда одного размера, карточка всегда с одинаковым padding, а primary‑кнопка сохраняет цвет и радиус.
Токенизируйте то, что влияет на общее ощущение продукта: шкалу отступов, размеры шрифтов и высоты строк, основные цвета (текст, фон, primary, danger, border) и небольшой набор радиусов.
Оставьте гибкими выборы, зависящие от контента: длину текста, какую иконку использовать или нужно ли секции две или три карточки.
Когда вы генерируете экраны (включая инструменты вроде Koder.ai), указание небольшого набора токенов заранее сокращает количество догадок и делает результат заметно более согласованным.
Набор токенов — это короткое меню допустимых значений. Меньше — лучше, потому что остаётся меньше места для случайных выборов, но набор должен покрывать базовые вещи, которые портят внешний вид экранов.
Начните с отступов. Выберите одну шкалу и используйте её везде для padding, gap и layout. Набор вроде 4, 8, 12, 16, 24, 32 покрывает большую часть UI. Если дизайн требует 10px или 18px, округляйте до ближайшего токена вместо добавления новых чисел.
Затем определите типографические дефолты, чтобы заголовки и body‑текст перестали «дрейфовать». Не нужна большая типографическая система — нужны ясные, повторяемые шаги.
Компактный набор, который остаётся полезным без раздутия:
Доступность тоже должна быть в системе. Определите стиль фокусной обводки (цвет, толщину, отступ), чтобы пользователи с клавиатурой получали одинаковые фокус‑состояния. Установите минимальную область нажатия (например 44x44) для мобильных. Ограничьте текстовые цвета небольшим, проверенным набором, чтобы контраст был предсказуем.
Если кнопки иногда выглядят сжатыми, часто это потому, что на одном экране использовали padding 10, а на другом — 12. С токенами вы можете сказать: «Кнопки используют paddingY=8, paddingX=16, radius=12, token фокуса, min height 44.» Как только эти числа зафиксированы, генератор перестаёт импровизировать.
Токены задают числа. Правила компонентов задают привычки.
Выберите небольшой набор основных компонентов и используйте их как единственные строительные блоки экранов. Делайте их простыми и переиспользуемыми: Button, Input, Select, Checkbox, Card. Можно добавить TextArea и Modal, но они тоже должны следовать той же системе (лейблы, отступы, состояния).
Далее ограничьте варианты и определите, когда их разрешено применять. Например: Button имеет primary, secondary и danger. Primary — для главного действия на экране (обычно одно). Secondary — для отмены или действий низкого приоритета. Danger — только для деструктивных действий, вроде удаления. Если вариант нельзя обосновать — по умолчанию используйте secondary.
Правила отступов предотвращают тонкий дрейф. Определите дефолты внутри компонентов: padding у Button, высота Input, расстояние между меткой и полем, стандартный gap между полями в стеке. Добавьте правила layout: у Card фиксированные внутренние отступы и одинаковое расстояние между хедером и телом; у Modal одинаковые шаги ширины и выравнивание футера.
И, наконец, сделайте состояния неоспоримыми — именно в них интерфейсы часто начинают выглядеть случайно:
Когда вы генерируете страницу с большим количеством форм, например «Создать проект», эти правила предотвращают смешение размеров кнопок, сдвиги меток или одноразовые «специальные» карточки, которые появляются только на одной странице.
Даже при стабильной визуальной части многие «это как‑то не так» жалобы приходят от поведения форм. Если каждая страница обрабатывает метки, ошибки и фокус по‑разному, пользователи это замечают как несогласованность.
Выберите один паттерн форм и используйте везде: метка, маркер обязательности/необязательности, вспомогательный текст, затем текст ошибки. Также держите формулировки единообразными (например, метки в предложном регистре, короткий вспомогательный текст, ошибки, начинающиеся с глагола).
Правила, которые предотвращают большую часть дрейфа:
Зафиксируйте размеры и макет, чтобы экраны не «дышали» по‑разному. Определите одну высоту input, одну высоту кнопки и дефолтную ширину поля. На десктопе выравнивайте поля по сетке и ставьте метки над инпутами. На мобильных делайте поля во всю ширину и избегайте двухколоночных форм, если это не действительно необходимо.
Простой пример: экран «Создать проект» может содержать Name, Region и Description. Даже если Region — select, обрабатывайте его как любое другое поле: одинаковая высота, одна и та же позиция метки, одна и та же строка ошибки. Если пользователь отправляет форму с пустым Name, фокус переходит на Name, под ним появляется ошибка, и макет остаётся стабильным.
Если вы генерируете экраны в Koder.ai, укажите эти правила форм в подсказке один раз и переиспользуйте их во всех фичах, чтобы каждая новая форма вела себя одинаково без повторных исправлений.
Относитесь к подсказке как к небольшому UI‑контракту. Держите её короткой, конкретной и переиспользуемой, чтобы каждый новый экран подстраивался под те же отступы, типографику, компоненты и поведение.
Практичный паттерн — вставить компактную спецификацию UI в начало запроса, затем описать экран простым языком.
UI SPEC (apply to every screen)
Tokens:
- Spacing: 4, 8, 12, 16, 24, 32
- Radius: 8
- Typography: H1 24/32, H2 18/26, Body 14/20
- Colors: text, muted, bg, primary, danger (no custom hex)
Components (must use): PageShell, Section, Card, Button, Input, Select, TextArea, FormRow, HelperText, Toast
Layout rules:
- Page padding: 24 desktop, 16 mobile
- Section spacing: 24
- Card padding: 16
- Grid: 12 cols desktop, 4 cols mobile, gap 16
Do:
- Reuse components and tokens only
- Keep labels above inputs, helper text below
Do not:
- Invent new spacing values, font sizes, or one-off CSS
- Mix different button heights or input styles
If a new component is needed:
- Extend an existing component pattern and document it in the output
- Do not create new visual styles outside tokens
После спецификации добавьте несколько проверок приёмки, которые ловят дрейф на ранней стадии:
Если вы используете чат‑генератор, держите эту спецификацию неизменной между запросами. Менять её каждый раз — значит лишить смысл всей системы.
Напишите UI‑контракт до того, как что‑то генерировать: короткий набор токенов (spacing, type, colors, radius, shadows) плюс небольшой инвентарь компонентов (Button, Input, Select, Card, Modal, Table, Toast). Если токена или компонента не хватает, модель придумает его, и ваш интерфейс уйдёт в дрейф.
Затем создайте один эталонный экран, который проверяет правила. Страница с большим количеством форм хороша как стресс‑тест, потому что включает заголовки, вспомогательный текст, ошибки валидации, primary и secondary кнопки и уведомление об успехе. Относитесь к этому экрану как к базису.
Дальше создавайте новые экраны, составляя их из уже определённых блоков. Не просите «свежий стиль». Просите те же Card, ту же шкалу отступов, те же шаги типографики и тот же паттерн полей.
Простой рабочий процесс:
Если экран «Поиск пользователей» вышел с более плотными отступами, чем эталон, не правьте маргины вручную. Обновите spacing‑токены или правило Card padding один раз, затем регенерируйте.
Если вы работаете в Koder.ai, снимки и откаты помогут: зафиксируйте эталон, экспериментируйте спокойно и быстро откатывайтесь, если изменение начинает вводить дрейф.
Самый быстрый способ потерять согласованность — относиться к токенам и правилам как к рекомендациям. Маленькие исключения множатся на новых экранах.
Одна из ловушек — менять шкалу отступов в середине проекта. Ранние экраны используют 8, 16, 24. Новый экран вводит 10 и 18 «потому что так выглядит лучше». Теперь дрейф разрешён, и старые экраны редко обновляются.
Другой источник дрейфа — позволить генератору придумывать новые стили компонентов. Если вы не сказали «существуют только эти варианты кнопок», модель может создать новый радиус или другой padding у инпута на одном экране.
Состояния — ещё одно частое место ошибок. Loading, empty и error состояния часто меняют отступы и поведение. Если вы добавляете их в конце, обычно получаете спешные паттерны, которые не соответствуют остальному.
Также следите за неправильной формой конкретики: «сделай современно с мягкими тенями» — это расплывчато, а правила поведения вроде «ошибки показывать под полем», «disabled‑кнопки сохраняют фокус», «Enter отправляет только на последнем поле» — конкретны и повторяемы.
Если нужен лёгкий guardrail для вставки в подсказки, держите его коротким:
Перед мержем сгенерированного экрана сделайте двухминутный осмотр.
Начните с отступов. Ищите случайные значения вроде 13px или одноразовые маргины. Если вы используете токены, каждый gap должен браться из утверждённого набора, включая gutters, padding карточек и расстояния между полями.
Затем проверьте типографику по шкале. Заголовки должны уменьшаться предсказуемо. Body‑текст не должен менять размер между похожими секциями. Высота строки тоже важна, особенно на плотных экранах настроек.
Проверьте кнопки. Варианты и размеры должны соответствовать правилам: primary для главного действия, secondary для менее важных, danger — только для удаления. Высота кнопки, расположение иконки и стиль текста должны совпадать.
Для форм согласованность — это прежде всего структура. Метки остаются в одном месте, индикация required следует одному правилу, вспомогательный текст и ошибки не конкурируют, ошибки появляются в одном и том же месте.
Короткий чеклист:
Наконец, сделайте быстрый мобильный прогон. Сожмите ширину и убедитесь, что лэйаут адаптируется без придумывания новых размеров шрифтов или отступов.
Представьте простой onboarding‑флоу: три экрана (Profile, Preferences, Confirm) и позже страница Settings. Вы хотите, чтобы каждый экран выглядел так, будто он от одного дизайнера, даже если генерировался отдельно.
Перед генерацией укажите небольшой набор токенов и несколько правил компонентов:
TOKENS
- spacing: xs=4, sm=8, md=12, lg=16, xl=24
- radius: sm=8, md=12
- type: body=14/20, title=20/28, label=12/16
- layout: pageMax=960, sectionGap=24, fieldGap=12
COMPONENT RULES
- Page: max width=pageMax, padding=xl, sectionGap between blocks
- Card: padding=lg, radius=md
- Field: label above, helper below, fieldGap between fields
- Button row: primary on right, gap=sm
- Errors: shown under field, same copy style, no alerts
Теперь сгенерируйте «Profile» и «Preferences» отдельно. Поскольку оба экрана должны использовать Page, Card, Field и Button row, они получат одинаковые отступы, расстояния меток и расположение кнопок. Шаг Confirm тоже вписывается, даже если в нём больше текстовых блоков.
Поведение форм — то место, куда дрейф часто пробирается, поэтому задайте его один раз и переиспользуйте: submit отключён до валидности, inline‑ошибки показываются после blur или submit, Enter отправляет только на последнем шаге, а кнопка Back не очищает уже введённые значения.
Когда нужен новый UI‑элемент, не позволяйте модели импровизировать. Добавьте одно правило и регенерируйте с мыслью о повторном использовании:
Преобразуйте токены и правила в переиспользуемую спецификацию, которой вы действительно пользуетесь. Если она слишком длинная для вставки, её не будут соблюдать.
Практичная спецификация обычно включает: таблицу токенов (spacing, type, radii, colors), короткий набор правил для компонентов (кнопки, инпуты, карточки, заголовки), правила поведения форм (время валидации, ошибки, disabled/loading), дефолты лэйаута (padding страницы, max width, расстояние между секциями) и короткий список «не делать» (случайные маргины, одноразовые размеры шрифтов).
И затем одна привычка: сначала обновляйте спецификацию, а не отдельные пиксели.
Если вы используете Koder.ai (koder.ai), режим планирования — хорошее место, чтобы повторить и подтвердить спецификацию перед генерацией UI. Когда хотите попробовать альтернативы, снимки и откаты помогут исследовать, не потеряв стабильную базу.
Потому что каждый запрос на генерацию экрана — это новый старт. Если у вас нет общей системы, генератор заполняет пропуски догадками — отступы, размеры шрифтов, отступы кнопок, тени и поведение форм — и мелкие различия накапливаются между страницами.
Дизайн‑токены — это именные, переиспользуемые значения для таких вещей, как отступы, размеры шрифтов, цвета и радиусы.
Вместо «комфортного отступа» вы используете что-то вроде space-md. Имя остаётся стабильным, и каждую страницу используют одни и те же решения, поэтому интерфейс перестаёт «дрейфовать».
Начните с малого и покрывайте только то, что вызывает заметный дрейф:
Вставьте компактный блок спецификации UI в начало каждого запроса и относитесь к нему как к контракту:
Затем опишите экран ниже. Главное — не менять спецификацию от запроса к запросу.
Токены задают числа; правила компонентов задают привычки. Полезные правила:
Правило по умолчанию: если вариант нельзя обосновать, возвращайтесь к стандартному.
Выберите один шаблон и используйте везде:
Это избегает типичной несогласованности, когда один экран валидирует на blur, а другой — только при отправке.
Стандартизируйте состояния:
Если не указать состояния, каждая страница будет придумывать свои паттерны.
Не давайте генератору придумывать стиль. Добавьте новый компонент как документированное расширение существующего паттерна:
Если вы не можете описать компонент через токены, скорее всего он слишком кастомный и вызовет дрейф.
Создайте «референсный» экран, который нагружает систему (страница с формами хорошо подходит), затем используйте одну и ту же спецификацию для всех новых экранов.
В Koder.ai используйте режим планирования (planning mode) для подтверждения спецификации перед генерацией, а также снимки (snapshots) и откаты (rollback) для сохранения стабильной базы при экспериментах.
Короткая проверка перед приёмом экрана:
Если что‑то не так — обновите спецификацию/токены и сгенерируйте снова, не патчьте разовые отступы.
Если нужен «новый» размер, округляйте до ближайшего токена вместо ввода 10px или 18px.