Последовательный UI в React‑приложениях с дизайн‑токенами и правилами

Почему сгенерированные экраны React часто выглядят несогласованно

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

Чаще всего причина дрейфа — в нескольких базовых вещах:

• Отступы: padding, gap и ритм секций отличаются
• Типографика: размеры шрифтов, веса и высоты строк нестабильны
• Компоненты: кнопки, карточки, границы и тени немного меняются
• Формы: время валидации, размещение ошибок и состояние disabled различаются

Это обычная ситуация, когда экраны генерируются из отдельных подсказок. Каждая подсказка — фактически новое начало, поэтому модель додумывает пропущенные решения. Даже «используй современный стиль» оставляет сотни мелких выборов: 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‑текст перестали «дрейфовать». Не нужна большая типографическая система — нужны ясные, повторяемые шаги.

Компактный набор, который остаётся полезным без раздутия:

• Отступы: 4, 8, 12, 16, 24, 32
• Тип: один размер body, два размера заголовков, одна высота строки для body, одна для заголовков
• Цвета: text-primary, text-muted, bg, surface, border, accent
• Радиус: два значения (например 4 и 12)
• Elevation: none, small, medium (максимум три уровня)

Доступность тоже должна быть в системе. Определите стиль фокусной обводки (цвет, толщину, отступ), чтобы пользователи с клавиатурой получали одинаковые фокус‑состояния. Установите минимальную область нажатия (например 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 одинаковые шаги ширины и выравнивание футера.

И, наконец, сделайте состояния неоспоримыми — именно в них интерфейсы часто начинают выглядеть случайно:

• Loading: дизейблить контрол, показывать спиннер, сохранять ширину
• Disabled: пониженный контраст, но не удалять hover/focus стили полностью
• Empty states: короткое сообщение плюс одно понятное действие
• Validation: ошибки появляются под полями и не вызывают больших сдвигов в макете

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

Правила поведения форм: детали, которые обычно дрейфуют

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

Выберите один паттерн форм и используйте везде: метка, маркер обязательности/необязательности, вспомогательный текст, затем текст ошибки. Также держите формулировки единообразными (например, метки в предложном регистре, короткий вспомогательный текст, ошибки, начинающиеся с глагола).

Правила, которые предотвращают большую часть дрейфа:

• Метки всегда над полями (не placeholders), маркер required на метке
• Вспомогательный текст всегда под полем, одного размера и цвета, не используется для ошибок
• Время валидации: показывать ошибки после blur или submit, очищать их при change
• Размещение ошибок: одна строка ошибки прямо под полем, выровненная с вспомогательным текстом
• Поведение фокуса: порядок Tab следует визуальному порядку; Enter отправляет только на последнем поле или когда сфокусирована primary‑кнопка

Зафиксируйте размеры и макет, чтобы экраны не «дышали» по‑разному. Определите одну высоту 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

После спецификации добавьте несколько проверок приёмки, которые ловят дрейф на ранней стадии:

• «Используйте только токены выше; никаких inline‑стилей.»
• «Все формы должны использовать FormRow и показывать ошибки одинаково.»
• «Если нужно добавить компонент, базируйте его на Card и существующей типографике.»

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

Рабочий процесс, который сохраняет согласованность экранов

Напишите 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 для вставки в подсказки, держите его коротким:

• Используйте ту же шкалу отступов и токены типографики, что и в существующих экранах; не придумывайте новые значения
• Используйте только одобренные компоненты и их варианты
• Включите loading, empty и error состояния, используя те же токены
• Указывайте поведение (валидация, порядок фокуса, submit, disabled) так же ясно, как и визуальные правила

Быстрый чеклист на согласованность перед принятием экрана

Перед мержем сгенерированного экрана сделайте двухминутный осмотр.

Начните с отступов. Ищите случайные значения вроде 13px или одноразовые маргины. Если вы используете токены, каждый gap должен браться из утверждённого набора, включая gutters, padding карточек и расстояния между полями.

Затем проверьте типографику по шкале. Заголовки должны уменьшаться предсказуемо. Body‑текст не должен менять размер между похожими секциями. Высота строки тоже важна, особенно на плотных экранах настроек.

Проверьте кнопки. Варианты и размеры должны соответствовать правилам: primary для главного действия, secondary для менее важных, danger — только для удаления. Высота кнопки, расположение иконки и стиль текста должны совпадать.

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

Короткий чеклист:

• Отступы используют только значения токенов (никаких случайных чисел)
• Типографика совпадает со шкалой (включая высоту строки)
• Кнопки следуют одним вариантам и размерам
• Формы используют один паттерн для меток, вспомогательного текста и ошибок
• Состояния присутствуют: hover, focus, disabled, loading, empty

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

Пример: генерация небольшой React‑фичи без дрейфа стилей

Представьте простой 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‑элемент, не позволяйте модели импровизировать. Добавьте одно правило и регенерируйте с мыслью о повторном использовании:

• ProgressStepper: height=32, spacing=md, current step bold, completed steps clickable

Следующие шаги: сделать согласованность умолчанием

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

Практичная спецификация обычно включает: таблицу токенов (spacing, type, radii, colors), короткий набор правил для компонентов (кнопки, инпуты, карточки, заголовки), правила поведения форм (время валидации, ошибки, disabled/loading), дефолты лэйаута (padding страницы, max width, расстояние между секциями) и короткий список «не делать» (случайные маргины, одноразовые размеры шрифтов).

И затем одна привычка: сначала обновляйте спецификацию, а не отдельные пиксели.

Если вы используете Koder.ai (koder.ai), режим планирования — хорошее место, чтобы повторить и подтвердить спецификацию перед генерацией UI. Когда хотите попробовать альтернативы, снимки и откаты помогут исследовать, не потеряв стабильную базу.