Дизайн-система без дизайнеров: 10 правил единого UI-стиля

Зачем вообще нужна дизайн-система, если дизайнеров нет

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

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

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

Минимальный набор артефактов для маленькой команды:

• короткий документ с правилами сетки, типографики и цветов (1-2 страницы)
• список компонентов и их состояний
• несколько эталонных экранов (например: список, карточка, форма)
• словарь терминов для текстов в интерфейсе
• простой чеклист перед добавлением нового экрана

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

Как понять, что интерфейс "в одном стиле"

Интерфейс "в одном стиле" не значит "однообразный". Это про предсказуемость: одинаковые решения работают одинаково, а различия появляются только там, где они действительно нужны. Пользователь быстрее ориентируется, а команда меньше спорит.

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

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

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

Правило 1: сетка и отступы, которые не ломаются

Если вы строите дизайн-систему без дизайнеров, начните с шага отступов. Выберите базовый модуль 8 px (или 4 px, если интерфейс плотный и много мелких элементов). Дальше любые размеры и отступы делайте кратными этому шагу: 8, 16, 24, 32.

Опишите сетку страницы словами, чтобы ее можно было повторять на каждом новом экране. Достаточно зафиксировать контейнер, поля, колонки и брейкпоинты. Например: на десктопе контейнер фиксированный, внутри 12 колонок и стабильные боковые поля; на планшете колонки те же, но поля меньше; на мобильном одна колонка и поля по 16 px.

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

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

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

Правило 2: типографика как небольшой набор текстовых стилей

Если в продукте нет дизайнеров, типографика - самый быстрый способ удержать единый вид. Не пытайтесь "настроить красиво" каждый экран отдельно. Договоритесь о маленьком наборе текстовых стилей и используйте только его.

Мини-таблица стилей

Обычно достаточно 4 ролей: Заголовок, Подзаголовок, Основной текст, Подпись (caption). Для каждой роли зафиксируйте размер и межстрочный интервал одной строкой, без вариантов "по ситуации". Например: Заголовок 24/32, Подзаголовок 18/24, Основной 14/20, Подпись 12/16.

Ограничьте начертания: максимум 2 насыщенности (например, Regular и Semibold), без зоопарка курсива. Если нужен акцент, сначала попробуйте Semibold или цвет, а не новый стиль.

Тексты на кнопках и ссылках

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

Для ссылок решите заранее: они всегда одного цвета, всегда с подчеркиванием (или никогда), и не превращаются в "кнопку" без причины.

Чтобы генератор не фантазировал, формулируйте требования как запреты и разрешения: "Используй только 4 текстовых стиля: H1, H2, Body, Caption. Другие размеры не добавляй. Насыщенность только Regular/Semibold. Кнопки: без переносов, без капса, до 24 символов". Тогда дизайн-система без дизайнеров превращается в повторяемое правило, а не в надежду на вкус.

Правило 3: цветовая палитра и правила акцентов

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

Чтобы не спорить про "синий потемнее", используйте токены с названиями по смыслу, а не по оттенку. Например:

• bg/default, bg/subtle
• text/primary, text/secondary, text/inverse
• accent/primary, accent/hover
• border/default, border/strong
• status/success, status/warning, status/error, status/info

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

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

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

Правило 4: компоненты и их состояния, описанные словами

Когда дизайнеров нет, интерфейс чаще всего расползается не из-за "красоты", а из-за разных версий одних и тех же элементов. Поэтому сначала договоритесь о минимальном наборе базовых компонентов и зафиксируйте их словами.

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

Описывайте состояния и тексты прямо в правилах

У каждого компонента должны быть одинаковые состояния: обычное, при наведении, при нажатии, выключенное, загрузка. Важно не только "как выглядит", но и "как ведет себя": когда блокируется, что происходит с кликом, показывается ли спиннер, можно ли отменить действие.

Отдельно закрепите пустые состояния и ошибки. Например: если список пуст, показываем заголовок "Пока ничего нет" и кнопку "Создать". Если поле не прошло проверку, текст ошибки всегда под полем и говорит, что исправить: "Введите email в формате name@domain.ru".

Размеры и простой шаблон описания

Размерные варианты разрешайте только там, где это действительно нужно (например, кнопки S/M/L). Зафиксируйте, где какой размер допустим: в таблицах только S, в формах M, в крупных CTA только L.

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

Правило 5: иконки, скругления и "мелкая графика"

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

Иконки держите в одном языке: либо все линейные, либо все с заливкой. Зафиксируйте толщину линии (например, 2 px), степень скругления углов и размер сетки (24 px или 20 px). Иконки разного происхождения почти всегда отличаются пропорциями и оптическим весом, и интерфейс становится пестрым.

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

Скругления, тени и границы ограничьте до 2-3 значений. Например: радиус 6 для полей и кнопок, 12 для карточек, 999 для чипов. Тени используйте только в одном сценарии (например, для модальных окон), а в остальном заменяйте их аккуратной границей.

Изображения и аватары тоже нормируйте: квадрат 40x40, круг с тонкой рамкой, заглушка с инициалами, одинаковая обрезка. Это особенно важно в списках и чатах.

Если вы генерируете UI, полезно добавить короткий блок запретов:

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

Правило 6: тексты в интерфейсе и словарь терминов

Если в продукте нет дизайнеров, стиль часто разъезжается не из-за цветов, а из-за слов. Один экран пишет "Сохранить", другой - "Записать", третий - "Ок". Пользователь воспринимает это как хаос, даже если сетка идеальная.

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

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

• Ошибка: "Не удалось [действие]. Попробуйте еще раз."
• Действие: "Сохранить", "Отправить", "Создать" (глагол в инфинитиве)
• Успех: "Готово" или "Сохранено" (выберите один вариант)
• Пусто: "Здесь пока нет [объектов]. Создайте первый."

Отдельно сделайте словарь терминов на 10-20 слов: как вы называете сущности и действия в продукте. Это быстрее, чем кажется, и сразу снимает половину споров.

Следите за длиной текста. Если не помещается, не уменьшайте шрифт и не ломайте кнопку. Сократите фразу, уберите лишнее ("пожалуйста", "успешно"), замените на более короткий глагол или перенесите пояснение в подсказку.

Правило 7: дизайн-токены как язык для команды и генерации

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

Какие токены завести в первую очередь

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

• spacing: xs, sm, md, lg (например 4, 8, 16, 24)
• radius: sm, md, lg
• font: size и weight для заголовка, обычного текста, подписи
• color: bg, text, primary, danger, border

В названиях избегайте "синий1" или "серый7". Лучше описывать роль: color-primary, color-text, color-bg. Тогда всем понятно, куда это ставить.

Свяжите токены с компонентами простым правилом: компонент не придумывает числа. Кнопка берет padding-md, radius-md, color-primary и font-button. Поле ввода берет color-border и spacing-sm.

Чтобы не утонуть, введите пределы: максимум 4 шага отступов, максимум 3 радиуса, не больше 2 акцентных цветов. Запрет полезнее свободы: "нельзя добавлять новый оттенок, если он не закрывает новую роль".

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

Правило 8: как описывать экран так, чтобы стиль сохранялся

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

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

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

Ограничения лучше писать как запреты и допуски. Например: "В шапке всегда один основной заголовок и одна вторичная ссылка", "В карточке максимум 2 строки описания, дальше троеточие", "Акцентный цвет только для основного действия". Это удерживает дизайн-систему без дизайнеров от расползания.

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

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

Сгенерируй экран "Список счетов".
Цель: быстро найти счет и оплатить.
Блоки: шапка (заголовок + поиск), контент (список карточек), действия (Оплатить), ошибки, пусто.
Компоненты/состояния: поиск (default/focus/error), кнопка (primary loading/disabled), карточка (hover/selected).
Ограничения: primary только один на экран, отступы и радиусы как в проекте, тексты до 2 строк.
Адаптивность: мобильный - одна колонка, кнопка на всю ширину, фильтры в модальном.

Частые ошибки и ловушки, которые ломают стиль

Главная причина, почему разваливается дизайн-система без дизайнеров, простая: команда добавляет "еще один вариант" вместо того, чтобы выбрать один и закрепить его. В итоге интерфейс выглядит как сборник исключений.

Ошибка 1: бесконечные варианты текста

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

Ошибка 2: отступы и высоты "на глаз"

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

Быстрые признаки, что вы уехали в хаос:

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

Ошибка 3: новые цвета и акценты везде

"Сделаем красивее" почти всегда означает новый оттенок. Лучше договориться, что акцентный цвет один и он про действие, а не про украшение.

Ошибка 4: нет состояний компонентов

Если не описаны loading, error и disabled, каждый экран решает это по-своему. Поэтому заранее фиксируйте: как выглядит кнопка при загрузке, где показывается ошибка, что блокируется, а что нет.

Ошибка 5: копипаст без унификации

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

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

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

Проверьте:

• Сетка и отступы: все кратно вашему шагу (например, 4/8 px), есть понятный контейнер, на основных брейкпоинтах ничего не "прыгает".
• Типографика: используете ограниченный набор текстовых стилей, без новых начертаний "на всякий случай".
• Цвета и акценты: цвета берутся по ролям, главный акцент на экране один.
• Компоненты и состояния: для кнопок, полей, переключателей одинаково описаны и выглядят default, hover, active, disabled, error.
• Тексты и термины: термины совпадают со словарем, сообщения короткие и похожи по структуре на остальные.

Если вы делаете экран через TakProsto, этот чеклист удобно вставлять в planning mode и сначала просить перечислить, какие токены и компоненты будут использованы, а уже потом собирать макет. Так стиль проверяется до того, как появится новый "особый случай".

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

Небольшой SaaS: два разработчика и продакт. Дизайнера нет, но есть боль: каждый новый экран выглядит как "чуть другой продукт". Они собрали дизайн-систему без дизайнеров не в Figma, а в виде коротких правил, которые можно повторять в задачах и в генерации.

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

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

• любой отступ должен быть из шкалы, иначе это исключение
• если возникает вопрос "почему тут 12", ответ один: покажи правило или добавь новое с причиной
• спорные случаи решает продакт и фиксирует решение одной строкой
• изменения правил делаются вместе с задачей и отмечаются в ревью

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

Следующие шаги: закрепить правила и ускорить сборку интерфейса

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

Дальше выберите минимальный набор токенов и запретов. Токены помогают не спорить о вкусе: вы не "делаете серый", вы берете text/secondary. Запреты экономят время: "не используем произвольные тени", "радиус только 8 или 12", "акцентный цвет один".

Процесс, который удерживает стиль:

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

Если вы генерируете интерфейсы на TakProsto (takprosto.ai), удобно держать эти договоренности как "контракт" для каждого экрана в planning mode. А когда экспериментируете со стилем, выручает подход со снапшотами и откатом: можно проверить новую версию UI и быстро вернуться назад, если консистентность поплыла.