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

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

Типографический токен — это не просто значение вроде 16 пикселей или font-weight 600. Это переменная с понятным назначением: например, text-body-md, heading-xl или label-sm. Внутри неё хранится конкретное значение, но в макетах и коде команда работает прежде всего с ролью. Такой подход отделяет смысл от реализации и позволяет изменить шрифтовую систему централизованно, не исправляя десятки компонентов вручную.

Токены особенно полезны, когда над продуктом работают дизайнеры и разработчики, а интерфейс развивается сразу в нескольких темах, разрешениях или платформах. Вместо обсуждения «поставь 18 пикселей и серый цвет» команда использует общий язык: «примени стиль заголовка уровня two» или «возьми основной текст среднего размера». Это снижает количество случайных решений и делает правила системы проверяемыми.

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

В зрелой системе полезно разделять примитивные и семантические токены. Примитивный токен может называться font-size-400 и хранить значение 16 пикселей. Семантический токен body-md ссылается на этот размер и выражает назначение. Если позже основной текст станет крупнее, достаточно заменить связь body-md, не меняя названия компонентов и макетов.

Семантические имена лучше привязывать к роли: display-lg, heading-md, body-sm, caption, button-label. Названия вроде blue-text или font-18 менее устойчивы, потому что описывают текущую реализацию. Если размер изменится, имя останется логичным. Если один и тот же размер используется в разных ролях, это не означает, что роли нужно объединять: позднее их требования могут разойтись.

Шкала размеров — последовательность значений, между которыми есть понятная логика. Она помогает избежать ситуации, когда в продукте одновременно используются 15, 16, 17, 18 и 19 пикселей без различимой роли. Начните с базового размера основного текста, затем добавьте ступени для подписей, интерфейсных элементов, подзаголовков и крупных заголовков. Количество уровней должно соответствовать реальному набору контента, а не стремлению описать любое возможное значение.

Для интерфейса можно использовать умеренную шкалу: 12, 14, 16, 18, 20, 24, 30, 36 и 48 пикселей. Это пример структуры, а не обязательный стандарт. В компактном B2B-продукте крупные значения могут почти не использоваться, тогда как лендингу или медиа-сервису потребуется больше выразительных уровней. Важно проверить шкалу на реальных заголовках, длинных словах и локализации.

Один токен не обязан иметь одинаковое значение на всех экранах. Для заголовка страницы можно назначить 36 пикселей на широком экране и 28 пикселей на мобильном, сохранив одну семантическую роль. Такие изменения следует описывать как режимы или переопределения токена, а не создавать отдельные стили desktop-title и mobile-title без необходимости. Название должно отвечать на вопрос «что это за текст», а не «где он расположен».

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

Названия токенов веса должны быть связаны с задачей: weight-regular, weight-medium, weight-semibold, weight-bold. При этом нужно проверить, какие начертания действительно существуют в выбранном шрифте. Синтетически созданный браузером полужирный вариант может выглядеть неравномерно, особенно в кириллице. Для интерфейса на русском языке важно тестировать не только латинские образцы, но и заголовки с буквами Ж, Щ, Ы, Э и прописными знаками.

Межстрочный интервал определяет, насколько свободно текстовые строки располагаются друг относительно друга. Для длинного основного текста обычно требуется больше воздуха, чем для короткой кнопки или крупного заголовка. Удобно хранить line-height как отдельный токен, но связывать его с текстовой ролью: body-md-line-height, heading-lg-line-height, label-sm-line-height. Так команда видит не голое число, а контекст применения.

Например, основной текст размером 16 пикселей может использовать межстрочный интервал 24 пикселя, а короткая подпись размером 12 пикселей — 16 пикселей. Заголовок размером 32 пикселя может выглядеть плотнее и иметь интервал около 38–40 пикселей. Эти значения нужно проверять визуально: высота букв, длина строк, язык и конкретное семейство заметно влияют на восприятие.

Типографическая система работает вместе с токенами отступов. Межстрочный интервал отвечает за внутренний ритм абзаца, а spacing-токены — за расстояние между заголовком, текстом, списком и соседними компонентами. Например, заголовок секции может иметь нижний отступ 8 пикселей до вводного текста, а между двумя самостоятельными абзацами может использоваться 16 или 24 пикселя.

Не стоит задавать отступы случайно для каждого текстового блока. Сначала определите небольшой ряд шагов, например 4, 8, 12, 16, 24, 32 и 48 пикселей, затем назначьте их типичным отношениям. В результате вертикальный ритм становится предсказуемым, а компоненты легче комбинировать. Если отдельному экрану нужен необычный интервал, это должно быть обоснованным исключением, а не новым токеном на каждый случай.

Представим интерфейс сервиса с нейтральным гротеском и базовым размером основного текста 16 пикселей. Для него можно определить несколько ролей: display-lg для главного заголовка, heading-md для заголовков разделов, body-md для чтения, body-sm для вторичного текста и label-md для кнопок. Каждая роль получает согласованный размер, вес, line-height и правила применения.

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

В макетах создайте текстовые стили с теми же семантическими именами, что используются в коде. Не смешивайте в одном компоненте ручные размеры и системные стили: иначе библиотека постепенно потеряет целостность. В коде токены можно представить CSS-переменными, объектом темы или переменными конкретного фреймворка. Главное — иметь единый источник правды и понятный процесс изменения.

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

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

Отдельные названия обычно не нужны, если роль текста остаётся той же. Один семантический токен может иметь разные значения в зависимости от ширины экрана. Например, заголовок страницы уменьшается на мобильном устройстве, но продолжает называться page-title. Отдельный токен оправдан только тогда, когда меняется не размер, а смысл или назначение текста.

Да, но связывать его лучше с текстовой ролью или типографическим пресетом. Отдельный глобальный токен line-height-400 может быть полезен как примитив, однако в компоненте понятнее использовать body-md-line-height или heading-sm-line-height. Это снижает риск применить одинаковый интервал к текстам с разной длиной строки и разной визуальной плотностью.

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

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

Сначала проверьте, действительно ли проблема требует нового размера. Возможно, достаточно изменить ширину блока, вес, line-height или отступ. Если уникальная роль повторяется и имеет отдельное назначение, добавьте семантический токен с описанием. Если это разовый декоративный приём, лучше оформить его как документированное исключение, а не расширять основную шкалу.

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