Дизайн-система без дизайнеров: 10 практических правил и текстовые договоренности по сетке, типографике, цветам и состояниям компонентов.
Если в команде нет дизайнера, интерфейс обычно расползается быстрее всего. Один экран собрали аккуратно, второй делали в спешке, третий делал другой человек, и уже разные отступы, заголовки и кнопки "по ощущениям". Это заметит не только продакт или разработчик, но и маркетолог: одинаковые функции выглядят как разные продукты.
Дизайн-система в такой ситуации - не "библиотека красивых компонентов", а набор договоренностей, который снимает сотни мелких вопросов: сколько отступ, какой размер текста, как выглядит ошибка, какой цвет у акцента. Чем меньше вы спорите и импровизируете, тем стабильнее стиль.
Это особенно полезно, когда вы собираете интерфейс через генерацию. Если правила описаны словами, их проще повторять в новых экранах и не уходить в самодеятельность.
Минимальный набор артефактов для маленькой команды:
Этого достаточно, чтобы любой участник команды (фаундер, продакт, разработчик) мог собрать новый экран так, чтобы он выглядел "как у нас", а не "как получилось".
Интерфейс "в одном стиле" не значит "однообразный". Это про предсказуемость: одинаковые решения работают одинаково, а различия появляются только там, где они действительно нужны. Пользователь быстрее ориентируется, а команда меньше спорит.
Разнобой обычно видно не в "красоте", а в мелочах, которые повторяются десятки раз: отступы и высота блоков, размеры и начертания шрифтов, кнопки и поля (высота, радиус, подписи), акцентные цвета и состояния (наведение, выключено, ошибка), которые каждый раз выглядят по-новому.
Чтобы за полчаса нащупать базовую эстетику, не нужен дизайнер. Возьмите 2-3 уже готовых экрана, выберите один "эталонный" и зафиксируйте несколько решений: базовый размер шрифта, 2-3 уровня заголовков, шаг отступов, радиус скругления, один акцентный цвет и правила для ошибок.
Эти договоренности экономят время на правках. Вместо "сделай покрасивее" появляется конкретика: "кнопка должна быть высотой 44", "акцент только один", "ошибки всегда красные и с текстом под полем". Это особенно помогает, если вы делаете дизайн-систему без дизайнеров и генерируете экраны текстом: чем точнее правила, тем меньше переделок после первого результата.
Если вы строите дизайн-систему без дизайнеров, начните с шага отступов. Выберите базовый модуль 8 px (или 4 px, если интерфейс плотный и много мелких элементов). Дальше любые размеры и отступы делайте кратными этому шагу: 8, 16, 24, 32.
Опишите сетку страницы словами, чтобы ее можно было повторять на каждом новом экране. Достаточно зафиксировать контейнер, поля, колонки и брейкпоинты. Например: на десктопе контейнер фиксированный, внутри 12 колонок и стабильные боковые поля; на планшете колонки те же, но поля меньше; на мобильном одна колонка и поля по 16 px.
С отступами проще, если разделить их на два типа: внешние (между блоками) и внутренние (внутри карточек, форм и панелей). Держите вертикальный ритм: заголовок, текст, кнопка идут с одинаковыми шагами и не прыгают от экрана к экрану.
Для размеров элементов зафиксируйте несколько стандартов: высота полей и кнопок, минимальная высота строки списка, базовые радиусы, минимальные внутренние поля карточки. Этого хватает, чтобы интерфейс перестал выглядеть "собранным из разных наборов".
Нарушать сетку можно, но только осознанно: для полноширинного баннера, модального окна или редкого промо-блока. В правилах лучше прямо написать, что именно допускается, где, и какой отступ использовать вместо стандартного.
Если в продукте нет дизайнеров, типографика - самый быстрый способ удержать единый вид. Не пытайтесь "настроить красиво" каждый экран отдельно. Договоритесь о маленьком наборе текстовых стилей и используйте только его.
Обычно достаточно 4 ролей: Заголовок, Подзаголовок, Основной текст, Подпись (caption). Для каждой роли зафиксируйте размер и межстрочный интервал одной строкой, без вариантов "по ситуации". Например: Заголовок 24/32, Подзаголовок 18/24, Основной 14/20, Подпись 12/16.
Ограничьте начертания: максимум 2 насыщенности (например, Regular и Semibold), без зоопарка курсива. Если нужен акцент, сначала попробуйте Semibold или цвет, а не новый стиль.
Для кнопок задайте правила, которые легко проверить: один регистр (обычный, без капса), длина до 2-3 слов, переносы запрещены. Если текст не помещается, уточняйте действие или увеличивайте ширину кнопки, но не уменьшайте шрифт.
Для ссылок решите заранее: они всегда одного цвета, всегда с подчеркиванием (или никогда), и не превращаются в "кнопку" без причины.
Чтобы генератор не фантазировал, формулируйте требования как запреты и разрешения: "Используй только 4 текстовых стиля: H1, H2, Body, Caption. Другие размеры не добавляй. Насыщенность только Regular/Semibold. Кнопки: без переносов, без капса, до 24 символов". Тогда дизайн-система без дизайнеров превращается в повторяемое правило, а не в надежду на вкус.
Цвет в интерфейсе нужен не для украшения, а для смысла. Договоритесь не о "красивых оттенках", а о ролях: что является фоном, что текстом, что акцентом, что границами. Тогда новые экраны будут выглядеть единообразно, даже если их описывают разные люди.
Чтобы не спорить про "синий потемнее", используйте токены с названиями по смыслу, а не по оттенку. Например:
bg/default, bg/subtletext/primary, text/secondary, text/inverseaccent/primary, accent/hoverborder/default, border/strongstatus/success, status/warning, status/error, status/infoКонтраст и читаемость можно проверять без фанатизма. Простое правило: основной текст должен читаться с первого взгляда, а вторичный не должен превращаться в серую пыль. Если сомневаетесь, делайте текст контрастнее и снижайте насыщенность акцента, а не наоборот.
Состояния компонентов тоже фиксируйте цветом и смыслом: успех, предупреждение, ошибка, инфо. При этом цвет не должен быть единственным сигналом: добавляйте короткий текст и, где уместно, иконку.
Чтобы ограничить самодеятельность, введите одно жесткое правило: на экране может быть только один главный акцент (обычно кнопка основного действия), а все остальное использует нейтральные токены.
Когда дизайнеров нет, интерфейс чаще всего расползается не из-за "красоты", а из-за разных версий одних и тех же элементов. Поэтому сначала договоритесь о минимальном наборе базовых компонентов и зафиксируйте их словами.
Стандартизируйте то, что встречается на каждом экране: кнопки, поля ввода, селекты, чекбоксы, табы. Не обязательно заранее рисовать огромную библиотеку. Достаточно описать структуру и поведение так, чтобы любой человек (или генератор) мог собрать одинаковый элемент.
У каждого компонента должны быть одинаковые состояния: обычное, при наведении, при нажатии, выключенное, загрузка. Важно не только "как выглядит", но и "как ведет себя": когда блокируется, что происходит с кликом, показывается ли спиннер, можно ли отменить действие.
Отдельно закрепите пустые состояния и ошибки. Например: если список пуст, показываем заголовок "Пока ничего нет" и кнопку "Создать". Если поле не прошло проверку, текст ошибки всегда под полем и говорит, что исправить: "Введите email в формате name@domain.ru".
Размерные варианты разрешайте только там, где это действительно нужно (например, кнопки S/M/L). Зафиксируйте, где какой размер допустим: в таблицах только S, в формах M, в крупных CTA только L.
Чтобы не разрастаться в документы на десятки страниц, используйте один и тот же короткий шаблон: назначение и где используется, состав (иконка, текст, подсказка), минимальные размеры, состояния и реакции, а также тексты для ошибок и пустых состояний.
Мелкие детали быстрее всего выдают разнобой. Поэтому заранее договоритесь о трех вещах: какой набор иконок вы используете, какие радиусы допустимы, и как выглядят границы и тени.
Иконки держите в одном языке: либо все линейные, либо все с заливкой. Зафиксируйте толщину линии (например, 2 px), степень скругления углов и размер сетки (24 px или 20 px). Иконки разного происхождения почти всегда отличаются пропорциями и оптическим весом, и интерфейс становится пестрым.
Когда иконка не помогает, выбирайте текст. Для редких действий и неочевидных команд подпись понятнее, чем символ. Иконки хорошо работают там, где они ожидаемы: поиск, настройки, закрыть, назад.
Скругления, тени и границы ограничьте до 2-3 значений. Например: радиус 6 для полей и кнопок, 12 для карточек, 999 для чипов. Тени используйте только в одном сценарии (например, для модальных окон), а в остальном заменяйте их аккуратной границей.
Изображения и аватары тоже нормируйте: квадрат 40x40, круг с тонкой рамкой, заглушка с инициалами, одинаковая обрезка. Это особенно важно в списках и чатах.
Если вы генерируете UI, полезно добавить короткий блок запретов:
Если в продукте нет дизайнеров, стиль часто разъезжается не из-за цветов, а из-за слов. Один экран пишет "Сохранить", другой - "Записать", третий - "Ок". Пользователь воспринимает это как хаос, даже если сетка идеальная.
Держите тон нейтральным и коротким: по делу, без канцелярита и без пассивных форм. Лучше "Не удалось загрузить файл", чем "Произошла ошибка загрузки файла". Лучше "Проверьте интернет и попробуйте снова", чем "Пожалуйста, выполните повторную попытку позднее".
Для системных текстов заведите несколько шаблонов и повторяйте их везде: на кнопках, в ошибках, подсказках, пустых состояниях. Например:
Отдельно сделайте словарь терминов на 10-20 слов: как вы называете сущности и действия в продукте. Это быстрее, чем кажется, и сразу снимает половину споров.
Следите за длиной текста. Если не помещается, не уменьшайте шрифт и не ломайте кнопку. Сократите фразу, уберите лишнее ("пожалуйста", "успешно"), замените на более короткий глагол или перенесите пояснение в подсказку.
Дизайн-токены - это короткий словарь значений, которые вы используете везде одинаково: отступы, радиусы, шрифты, цвета. Для дизайн-системы без дизайнеров это самый надежный способ не спорить "на глаз", а просто выбирать из набора.
Начните с малого, чтобы токены реально применялись каждый день. Обычно хватает четырех групп:
В названиях избегайте "синий1" или "серый7". Лучше описывать роль: color-primary, color-text, color-bg. Тогда всем понятно, куда это ставить.
Свяжите токены с компонентами простым правилом: компонент не придумывает числа. Кнопка берет padding-md, radius-md, color-primary и font-button. Поле ввода берет color-border и spacing-sm.
Чтобы не утонуть, введите пределы: максимум 4 шага отступов, максимум 3 радиуса, не больше 2 акцентных цветов. Запрет полезнее свободы: "нельзя добавлять новый оттенок, если он не закрывает новую роль".
Храните токены в двух местах: один короткий документ с правилами (что значит каждый токен) и один файл переменных в проекте. Когда появляется новый экран, вы сначала выбираете токены, а уже потом собираете компоненты.
Когда дизайнеров нет, стиль держится на тексте. Одна короткая спецификация на экран важнее десяти разрозненных комментариев, потому что по ней можно и руками собрать UI, и отдать в генератор без сюрпризов.
Держите формат одинаковым для всех экранов. Удобно, когда в задаче всегда есть одни и те же пункты:
Ограничения лучше писать как запреты и допуски. Например: "В шапке всегда один основной заголовок и одна вторичная ссылка", "В карточке максимум 2 строки описания, дальше троеточие", "Акцентный цвет только для основного действия". Это удерживает дизайн-систему без дизайнеров от расползания.
Адаптивность описывайте простыми словами: что переносится, что становится в одну колонку, что прячется. Пример: на мобильном действия уходят вниз и становятся на всю ширину, таблица превращается в список карточек, второстепенные фильтры сворачиваются в кнопку.
Чтобы эти правила работали в генерации, добавляйте их в запрос как рамку, а не как пожелания. Например:
Сгенерируй экран "Список счетов".
Цель: быстро найти счет и оплатить.
Блоки: шапка (заголовок + поиск), контент (список карточек), действия (Оплатить), ошибки, пусто.
Компоненты/состояния: поиск (default/focus/error), кнопка (primary loading/disabled), карточка (hover/selected).
Ограничения: primary только один на экран, отступы и радиусы как в проекте, тексты до 2 строк.
Адаптивность: мобильный - одна колонка, кнопка на всю ширину, фильтры в модальном.
Главная причина, почему разваливается дизайн-система без дизайнеров, простая: команда добавляет "еще один вариант" вместо того, чтобы выбрать один и закрепить его. В итоге интерфейс выглядит как сборник исключений.
Часто заводят много размеров и начертаний "на всякий случай": для одного экрана один стиль, для другого другой, потом появляются "почти такие же". Держите набор небольшим и добавляйте новый стиль только по понятной причине (например, появился новый тип экрана).
Когда у кнопок и полей разные высоты, а между блоками отступы каждый раз новые, стиль ломается даже при одинаковых цветах. Помогает правило: любые отступы только из короткой шкалы, а высоты ключевых элементов фиксированы.
Быстрые признаки, что вы уехали в хаос:
"Сделаем красивее" почти всегда означает новый оттенок. Лучше договориться, что акцентный цвет один и он про действие, а не про украшение.
Если не описаны loading, error и disabled, каждый экран решает это по-своему. Поэтому заранее фиксируйте: как выглядит кнопка при загрузке, где показывается ошибка, что блокируется, а что нет.
Быстро взять компонент из другого проекта удобно, но опасно. Сначала приведите его к вашим правилам: размеры, отступы, цвета и состояния. Только потом добавляйте в общий набор.
Перед тем как собирать (или генерировать) новый экран, остановитесь на 5 минут и пройдитесь по одному списку. Это простой способ удерживать стиль без долгих обсуждений.
Проверьте:
Если вы делаете экран через TakProsto, этот чеклист удобно вставлять в planning mode и сначала просить перечислить, какие токены и компоненты будут использованы, а уже потом собирать макет. Так стиль проверяется до того, как появится новый "особый случай".
Небольшой SaaS: два разработчика и продакт. Дизайнера нет, но есть боль: каждый новый экран выглядит как "чуть другой продукт". Они собрали дизайн-систему без дизайнеров не в Figma, а в виде коротких правил, которые можно повторять в задачах и в генерации.
За 1-2 дня они сделали простой файл договоренностей и прошлись по ключевым экранам, выравнивая их под эти правила. Важно, что правила были не про вкус, а про числа и состояния: какие отступы разрешены, какие размеры шрифта бывают, как выглядит кнопка в норме, при наведении и в отключенном виде.
Чтобы не спорить каждый раз, они ввели порядок:
По мере роста продукта они не переписывают все заново, а добавляют по одному пункту, когда появляется новый паттерн (например, новый тип формы или таблицы). Уже в следующем релизе эффекты заметны: меньше мелких правок в конце, быстрее сборка экранов, единые тексты и предсказуемые компоненты.
Чтобы дизайн-система без дизайнеров работала, ей нужны два простых артефакта: один документ с правилами и один список компонентов. Документ должен быть коротким, без теории: сетка, типографика, цвета, состояния, тексты. Список компонентов - что уже есть и как это называется.
Дальше выберите минимальный набор токенов и запретов. Токены помогают не спорить о вкусе: вы не "делаете серый", вы берете text/secondary. Запреты экономят время: "не используем произвольные тени", "радиус только 8 или 12", "акцентный цвет один".
Процесс, который удерживает стиль:
Если вы генерируете интерфейсы на TakProsto (takprosto.ai), удобно держать эти договоренности как "контракт" для каждого экрана в planning mode. А когда экспериментируете со стилем, выручает подход со снапшотами и откатом: можно проверить новую версию UI и быстро вернуться назад, если консистентность поплыла.
Да, если вы хотите, чтобы новые экраны выглядели «как у нас», а не «как получилось». Дизайн-система в этом случае — это набор простых правил про отступы, типографику, цвета, состояния и тексты, которые снимают постоянные мелкие решения.
Возьмите 2–3 готовых экрана, выберите один эталонный и зафиксируйте числа: шаг отступов, размеры текстовых стилей, высоту кнопок и полей, радиусы и один акцентный цвет. Затем приведите остальные экраны к этим правилам и не добавляйте новые варианты без причины.
Самый понятный дефолт — модуль 8 px, а для плотных интерфейсов 4 px. Главное правило: любые отступы и размеры должны быть кратны выбранному шагу, иначе появляются «почти одинаковые» значения и визуальный шум.
Достаточно 4 ролей: заголовок, подзаголовок, основной текст и подпись. Для каждой роли один размер и межстрочный интервал, плюс максимум две насыщенности шрифта, чтобы не плодить «полу-стили» под каждый экран.
Фиксируйте палитру по ролям, а не по оттенкам: фон, текст, границы, акцент, статусы. Тогда на новых экранах вы выбираете смысл (например, «ошибка»), а не придумываете новый красный «покрасивее».
Одно простое правило работает лучше всего: один главный акцент на экран, обычно это основное действие. Остальные элементы должны быть нейтральными, иначе пользователь перестает понимать, где главное.
Обязательно заранее описать loading, disabled и error, потому что именно тут чаще всего появляется разнобой. Если состояние не закреплено, каждый экран решает по-своему, и кнопки, поля и списки начинают «жить отдельной жизнью».
Токены нужны, чтобы компонент перестал «придумывать числа» и всегда собирался из ограниченного набора: отступы, радиусы, шрифты, цвета. Дефолтный подход — держать 3–4 шага spacing, 2–3 радиуса и один основной акцент, а все остальное добавлять только под новую роль.
Сделайте короткий словарь терминов и выберите один вариант для ключевых действий и статусов: «Сохранить», «Создать», «Готово» и так далее. Это убирает ощущение хаоса даже при аккуратной сетке, потому что пользователь перестает встречать одно и то же разными словами.
Пишите спецификацию как «контракт»: цель экрана, блоки, компоненты и их состояния, ограничения по акцентам и текстам, простые правила адаптива. В TakProsto удобно сначала прогнать это в planning mode, а изменения стиля проверять через снапшоты и откат, чтобы быстро возвращаться к стабильной версии.