Единый стиль интерфейса с ИИ: цвета, шрифты, компоненты

Почему интерфейс быстро становится разношерстным

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

Обычно первыми «плывут» базовые вещи: цвета (особенно нейтрали и состояния вроде hover/disabled), размеры шрифта и межстрочные интервалы, радиусы, тени, отступы в формах и карточках. Эти детали сложно держать в голове, когда параллельно решаете логику, тексты и структуру.

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

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

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

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

Что нужно определить, чтобы стиль держался

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

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

Чтобы ИИ действительно помогал, а результат не расползался, зафиксируйте три слоя.

1) Токены (маленькие кирпичики)

Токены - это именованные значения, из которых собирается интерфейс: цвета, типографика, радиусы, отступы, тени. Важно не просто перечислить значения, а договориться о принципе. Например: «1 основной цвет, 1 акцент, 3 нейтральных семейства, и не больше 6 уровней серого». Тогда новые экраны перестанут требовать новых оттенков.

2) Компоненты (готовые детали)

Определите список компонентов, которыми вы реально будете пользоваться: кнопки, поля, селекты, таблицы, модалки, уведомления. Для каждого назовите варианты, но без коллекции «на всякий случай». Обычно достаточно одной основной (primary) и одной вторичной (secondary) кнопки плюс destructive для опасных действий.

3) Состояния и правила выбора

Компонент без состояний почти бесполезен. Зафиксируйте минимум: hover, focus, disabled, error, loading. И добавьте правила, которые снимают споры:

• какие сочетания текста и фона допустимы
• когда использовать primary vs secondary
• как выглядит ошибка в поле и где показывать подсказку
• какие размеры шрифтов у заголовков и основного текста
• какие отступы считаются нормой для форм и карточек

Если вы собираете продукт в TakProsto, удобнее всего оформить это одним «контрактом»: токены + компоненты + состояния. Дальше в каждом новом экране вы просите не «сделай красиво», а «собери строго по контракту».

Как подготовить вводные для ИИ за 20 минут

Чтобы ИИ предложил единый стиль, ему нужны не «красиво и современно», а четкие рамки. Их реально собрать за 20 минут даже без дизайнерского опыта.

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

Дальше опишите контекст использования одним абзацем: кто пользователь, где он работает, что у него на экране, в каком состоянии он обычно бывает (спешит, сравнивает, заполняет формы). Уточните платформу: веб, мобильное приложение или внутренний сервис.

Затем зафиксируйте ограничения. Это экономит часы правок: требования по контрасту и доступности, запрет на слишком мелкий текст, брендовые цвета (если есть), светлая тема, темная или обе.

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

Удобно собрать все в короткий бриф для чата:

• 3-5 референсов и что в них нравится (словами)
• аудитория + платформа + контекст использования
• ограничения по доступности и цветам
• 5-7 ключевых экранов и топ-5 действий
• тональность в одной фразе (строго, дружелюбно, нейтрально)

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

Пошаговый сценарий разговора с ИИ

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

Сценарий из 5 шагов

Сделайте один чат (или один документ), куда вы будете возвращаться, и пройдите по шагам:

1. Попросите ИИ предложить 2-3 направления стиля (например: спокойный финтех, дружелюбный продукт для новичков, строгий B2B). Пусть для каждого даст короткое описание, 3-5 ключевых слов и риски. Выберите одно и запретите смешивание.
2. Утвердите токены и правила: цвета (фон, текст, акцент, успех/ошибка), типографика (роли текста), радиусы, тени, отступы. Попросите записать это в виде таблицы и примеров применения.
3. Опишите библиотеку компонентов и состояния. Пусть ИИ перечислит: кнопки, поля, селекты, карточки, табы, модалки, тосты, и для каждого - normal/hover/disabled/loading/error.
4. Проверьте договоренности на 2-3 ключевых экранах. Например: вход, список сущностей, карточка/редактирование. Попросите описать, какие компоненты где стоят и какие токены используются.
5. Зафиксируйте итог как короткую спецификацию на 1-2 страницы. Дальше, когда появляется новый экран, вы не обсуждаете стиль заново, а выбираете подходящие токены и компоненты.

Как формулировать требования

Сразу разделите, что можно менять, а что нельзя:

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

Пример запроса: «Собери экран списка заявок только из утвержденных компонентов. Используй акцентный цвет только для главного действия. Ошибки показывай через token error и один формат сообщения». Так стиль держится даже когда экраны растут каждый день.

Цвета: как выбрать палитру и не утонуть в оттенках

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

Базовый набор ролей, который закрывает почти любой продукт:

• Background (фон страницы) и Surface (карточки, панели)
• Text (основной текст) и Muted (вторичный текст)
• Primary и Secondary (основные и вторичные действия)
• Success, Warning, Danger (статусы и ошибки)
• Border/Divider (границы и разделители)

Дальше главный принцип: не плодите десятки оттенков. На практике хватает 3-5 уровней на «семейство» цвета. Для Primary обычно достаточно основного, hover, pressed и одного светлого для подложек (бейджи, подсветка). Для нейтралей держите 4-5 уровней, иначе получите «серую кашу», когда фон, карточка и граница отличаются на полтона.

Правило для фонов и карточек простое: у страницы один базовый background, у карточек один surface и один дополнительный уровень для выделенных блоков. Если хочется «чуть светлее», берите заранее оговоренный token, а не подбирайте новый серый.

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

• если текст на кнопке читается только при прищуре, контраст мал
• на мобильном подписи должны читаться при ярком свете
• ссылка и главное действие заметны без подсказок
• цвет не должен быть единственным носителем смысла (добавьте иконку или текст)

Если планируете темный режим, начните минимально: заведите отдельные значения для Background, Surface, Text, Muted и Border, а акцентные (Primary, Success и другие) по возможности оставьте теми же.

Типографика: размеры, интервалы и роли текста

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

Часто работает самое простое: 1 гарнитура для всего интерфейса и, при необходимости, отдельная моноширинная для чисел и таблиц. Одной нейтральной sans-serif обычно хватает: она читабельна и в заголовках, и в тексте, и на кнопках.

Шкала размеров и роли текста

Выберите базовый размер для основного текста и от него постройте 5-7 уровней. Во многих приложениях хватает такой шкалы: 12, 14 (база), 16, 20, 24, 32. Важны не сами числа, а то, что у каждого размера есть роль и он используется по назначению.

Чтобы ИИ не придумывал новые варианты, закрепите роли и имена токенов, например: h1, h2, title, body, caption, button, link. Дальше требование простое: «используй только заданные текстовые токены».

Интервалы, строка, числа

Ориентир по межстрочному интервалу: для обычного текста 1.4-1.6, для заголовков 1.1-1.3. Длину строки держите умеренной: если абзац растягивается на полэкрана, чтение замедляется.

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

Короткие договоренности, которые спасают от хаоса:

• Ссылки: тот же размер, что body, и стабильный маркер (например, цвет плюс подчеркивание).
• Кнопки: один размер (часто 14-16), полужирный, без переносов.
• Подсказки и ошибки: меньше основного текста (например, 12), но контраст и тон фиксированы.
• Заголовки: только из шкалы, без «слегка увеличить на 1».
• Числа: моноширинные или табличные цифры, особенно в списках и таблицах.

Мини-сценарий: вы делаете экран тарифов. Заголовок «Pro» берется из title, описание из body, примечание про лимиты из caption, цены и проценты идут по правилу для чисел. ИИ не «улучшает» самовольно, потому что рамки уже заданы.

Компоненты: договоренности, которые экономят дни

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

Начните с малого набора, который покрывает 80% задач, и добавляйте остальное только когда реально упираетесь в ограничение. Обычно в стартовый набор входят кнопки, поля ввода, переключатели, контейнеры (карточки/панели) и диалог подтверждения.

Для каждого компонента зафиксируйте три вещи: размеры, варианты и внутренние отступы. Например, у кнопки часто достаточно 2 размеров (M и L), у инпута тоже 2, у карточки один базовый с разными паддингами. Сразу решите, где живут иконки (слева, справа), и какой зазор от иконки до текста (например, 8 px).

Отдельно договоритесь о состояниях. Их часто забывают, и именно из-за этого интерфейс расползается:

• normal
• hover
• focus
• pressed
• disabled

Loading и error лучше считать обязательными для кнопок и форм: кнопка должна уметь показывать спиннер, а поле ввода - ошибку под ним одним стилем.

Пустые состояния и ошибки тоже полезно сделать шаблонами, иначе тексты будут разными по тону. Достаточно 3-4 заготовок: «Пока здесь пусто», «Не удалось загрузить. Попробуйте еще раз», «Проверьте поле», «Данных нет». И заранее решить, есть ли рядом кнопка действия.

По иконкам главное одно: единый стиль. Договоритесь про толщину линии, сетку (например, 24x24), размер в интерфейсе (16 или 20) и скругление.

Макет и отступы: как добиться аккуратности без дизайна

Больше всего «самодельный» интерфейс выдают хаотичные отступы. Когда между блоками то 10 px, то 14 px, карточки в одном месте «дышат», а в другом прилипают, единый стиль рассыпается даже при хороших компонентах.

Сетка и правила отступов

Самый простой способ навести порядок - выбрать один шаг сетки и не спорить с ним. Обычно берут 8 (иногда 4 для мелких зазоров). После этого вы договариваетесь не про «красиво», а про числа: какие паддинги у карточек, какой gap между смысловыми блоками, какие радиусы допустимы.

Пример рабочего мини-набора правил:

• базовый шаг: 8 px (микро-отступы допускаются 4 px)
• внутренние отступы в карточках и секциях: 16 или 24 px
• расстояния между смысловыми блоками: 24 или 32 px
• радиусы: 8 px для большинства, 12 px только для крупных карточек
• тени и границы: либо «только граница 1 px», либо «тень только для поднятых элементов», без смеси в одном экране

Дальше держите порядок блоков: сначала заголовок и контекст, затем основное действие, потом контент, а вторичные элементы (подсказки, ссылки, вторые кнопки) уводите вниз или вправо и делайте визуально тише.

Как зафиксировать решения и заставить ИИ их соблюдать

Сохраните правила в одном месте: спецификация на 1-2 страницы с таблицей токенов (например, spacing-8/16/24/32, radius-8/12, border-1) и короткими примерами. Этого достаточно, чтобы любой новый экран собирался как конструктор.

Перед созданием нового экрана давайте ИИ один и тот же запрос:

Сгенерируй экран по спецификации UI ниже. Не вводи новые значения отступов, радиусов, теней и границ.
Порядок блоков: заголовок -> основное действие -> контент -> вторичные элементы.
Сетка: шаг 8px (допускается 4px), padding секций 24px, gap между блоками 24px.
Radii: 8px (12px только для крупных карточек). Borders: 1px, тень только для модальных окон.
Если не хватает элемента, предложи вариант из существующих компонентов.

Так вы перестаете «перерисовывать на глаз» и начинаете повторять одни и те же решения, а это и делает интерфейс аккуратным.

Типичные ошибки и как их избежать

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

Вторая ошибка - переусложнение. Когда в проекте 12 цветов, 9 размеров шрифта и 6 видов радиусов, поддерживать это не сможет никто. Лучше сделать набор маленьким, но понятным: 3-5 основных цветов, 1-2 акцента и 4-6 текстовых ролей.

Что ломает консистентность чаще всего

К разнобою почти всегда приводят одни и те же ситуации:

• запрос без контекста: «нарисуй экран/компонент» без токенов и примеров
• палитра «на все случаи»: новый оттенок под каждую кнопку или статус
• нет правил состояний: hover, focus, disabled, error выглядят по-разному на разных экранах
• копирование референса как есть: красиво в чужом продукте, но плохо ложится на ваши тексты и плотность данных
• смешивание паттернов платформ: веб-таблицы ведут себя как мобильные карточки, а мобильные формы получают «десктопные» ховеры

Как это исправлять на практике

Сделайте правило: любой новый экран или компонент добавляется только вместе с ответами на три вопроса: какие токены используются, какие состояния есть, и какой это паттерн (веб или мобайл).

Еще одна короткая проверка перед принятием результата: откройте два разных экрана и сравните кнопки и поля ввода. Если focus, error и disabled отличаются, значит состояния описаны не до конца, и модель начала импровизировать. Добавьте правила один раз, и дальше это перестанет повторяться.

Короткий чеклист перед тем, как рисовать новые экраны

Перед новым экраном полезно на 2 минуты свериться со стилем. Это быстрее, чем потом править десятки мелких несостыковок.

1) Быстрая проверка токенов

Убедитесь, что базовые договоренности зафиксированы не в голове, а в токенах (названиях и ролях):

• Цвета: роли есть (фон, поверхность, граница, текст, акцент), акцентов не больше 2-3. Если тянет добавить новый оттенок, сначала сформулируйте, какую роль он закрывает.
• Текст: есть шкала размеров и роли (заголовок, подзаголовок, основной текст, подпись), плюс отдельное правило для ссылок (маркер и поведение при наведении).
• Отступы: одна «лесенка» шагов (например, 4-8-12-16-24) и понятные примеры для карточек и форм.

2) Компоненты и эталоны перед новым экраном

Новый экран почти всегда собирается из известных блоков. Проверьте, что у ключевых компонентов описаны варианты и состояния: кнопка (primary/secondary/destructive), поле ввода (default/focus/error/disabled), чекбокс/переключатель, табы, модальное окно.

Затем сравните будущий экран с 2-3 эталонными экранами (например: список, карточка детали, форма). Если что-то выглядит «не как в эталоне», обычно проблема в одном из трех: роль цвета, шаг отступа или неправильный вариант компонента.

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

Пример: как собрать стиль для небольшого продукта за вечер

Представим задачу: вы делаете личный кабинет, где пользователь оплачивает подписку и отправляет заявки (например, на услугу или поддержку). Экранов немного, но без общего подхода стиль расползается уже на второй странице.

Начните с коротких вводных для ИИ: аудитория, настроение (спокойно, делово), 1 главный акцентный цвет и 1 пример продукта, который нравится по ощущению. Затем просите не «красивую картинку», а правила: цветовые токены, роли текста и список компонентов со состояниями.

Чтобы уложиться в первый релиз, выберите 6-8 компонентов, которые закроют 80% интерфейса. Обычно это кнопки, поля ввода, строка списка или карточка сущности, таблица или простой список с колонками, уведомление (toast или banner). Остальные (модалка подтверждения, табы, пагинация) добавляйте позже, но сразу держите базовые состояния: hover, active, focus, loading.

Дальше используйте ИИ по задачам. Для форм - договориться о высоте полей, радиусе, толщине бордера и поведении ошибок. Для таблиц и списков - о плотности (compact или comfortable), разделителях и выравнивании чисел. Для уведомлений - о ролях статусов и тексте сообщений.

Проверка целостности занимает 20-30 минут: соберите один экран настроек (много полей и кнопок) и один экран списка (статусы, фильтры, пустое состояние). Если на этих двух экранах все выглядит как одна система, значит вы попали.

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

Следующие шаги: как удержать стиль в проекте

Единый стиль интерфейса держится на простых правилах и привычке их проверять. После того как вы выбрали палитру, типографику и набор компонентов, зафиксируйте все в одном месте: токены (цвета, размеры, радиусы, тени), роли текста и правила состояний (hover, active, disabled, error).

Выберите 1-2 экрана-эталона и доведите их до идеала. Обычно это экран входа и основной рабочий экран. Дальше любые новые экраны сравнивайте с эталонами: одинаковые отступы, одинаковая логика кнопок, одинаковые заголовки. Если что-то выбивается, сначала правьте правило, а потом экраны, а не наоборот.

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

Если вы делаете продукт в TakProsto (takprosto.ai), удобно держать этот «контракт» прямо в проекте и использовать режим планирования, чтобы новые экраны собирались по одним и тем же правилам, а не заново. Когда стиль устоится, пригодятся снапшоты для безопасных изменений, а затем - экспорт исходников и подключение кастомного домена для полноценного запуска.