Как устроить типографические токены в дизайн-системе продукта

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

Дизайн-токен — это не просто число вроде 16 пикселей. Это именованное решение, которое связывает значение с его назначением. Например, token.text.body.medium может описывать размер, высоту строки и начертание основного текста. Если продукт переходит на другой шрифт или меняет масштаб интерфейса, команда корректирует системное правило, а не ищет одинаковые значения в сотнях экранов.

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

Без токенов типографика постепенно распадается на локальные исключения. Один дизайнер использует 15 пикселей для карточки, другой — 16, а разработчик добавляет собственное значение для мобильной версии. Отдельная проблема возникает при редизайне: изменение базового шрифта требует ручной проверки множества компонентов и часто приводит к незаметным расхождениям.

Важно не превращать токены в формальную коллекцию переменных. Их ценность появляется только тогда, когда у каждого имени есть понятная роль, область применения и владелец. Если команда может объяснить, чем body.medium отличается от label.medium и почему нельзя использовать один стиль везде, система действительно работает.

Удобная архитектура обычно разделяет токены на базовые, семантические и компонентные. Базовые значения описывают технические параметры шрифта. Семантические назначают эти параметры текстовым ролям. Компонентные уточняют поведение конкретного элемента, например кнопки или поля формы. Разделение не является единственно правильным, но оно помогает не смешивать значение и контекст его использования.

Базовый слой содержит нейтральные примитивы: семейство шрифта, набор начертаний, размеры, высоту строки и межбуквенный интервал. Примеры имён — font.family.brand, font.weight.semibold, font.size.400, line.height.600 и tracking.tight. Такие токены не должны описывать конкретную кнопку или заголовок страницы. Они формируют строительные материалы, из которых затем собираются смысловые стили.

Семантический слой отвечает за назначение текста. Здесь могут находиться display.large, heading.page, heading.section, body.large, body.medium, body.small, label.medium, caption и code.inline. Если визуальный стиль меняется, роль остаётся прежней. Например, body.medium может ссылаться на один базовый размер в веб-версии и на другой — в мобильном приложении, сохраняя смысл «обычного текста интерфейса».

Компонентные токены нужны там, где текст зависит от анатомии элемента. Для кнопки это может быть button.label.font, для поля — input.value.font и input.helper.font, для таблицы — table.header.font. Компонентный слой не должен дублировать всю типографику. Он полезен, когда компоненту требуется отдельная семантика, состояние или адаптация, которую нельзя выразить только общими ролями.

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

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

Шкала размеров должна быть достаточно компактной, чтобы команда запоминала её, и достаточно гибкой для разных задач. Часто используют последовательность с небольшими шагами в зоне обычного текста и более крупными шагами для заголовков. Высоту строки задавайте осознанно: крупному заголовку нужен один ритм, плотной подписи — другой. Не связывайте line-height с размером шрифта механически без проверки на реальном тексте.

Пример небольшой шкалы: size.100 — 12 пикселей для вторичных подписей, size.200 — 14 пикселей для метаданных, size.300 — 16 пикселей для основного текста, size.400 — 20 пикселей для вспомогательных заголовков, size.500 — 24 пикселя для секций, size.600 — 32 пикселя для крупных заголовков. Это не универсальный стандарт, а стартовая модель, которую нужно проверить на шрифте и контенте продукта.

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

Хорошее имя описывает назначение, а не внешний вид. Название text.gray.large быстро становится ошибочным, если цвет или размер меняются. Гораздо устойчивее использовать отдельные измерения и роль: color.text.secondary, typography.body.large или button.label. Выберите один порядок слов, разделитель и формат числовой шкалы, затем закрепите правила в документации.

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

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

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

В коде токены можно представить CSS-переменными, объектом темы или платформенным файлом конфигурации. Например, typography.body.medium может ссылаться на font-family, font-size, font-weight и line-height, а компонент получает ссылку на роль. Храните исходные значения отдельно от преобразованных форматов для веба, iOS или Android. Так проще поддерживать единый источник правды и выпускать обновления без ручного копирования.

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

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

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

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

Пятая ошибка — связывать компонентные стили напрямую с примитивами. Если кнопка использует size.300 вместо роли button.label, изменение общей шкалы может случайно изменить её поведение. Смысловые ссылки дают команде возможность обновлять систему управляемо: одна роль меняется целенаправленно, а неожиданные последствия легче обнаружить на визуальном тестировании.

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

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

Текстовый стиль — готовая комбинация параметров в конкретном инструменте, например в Figma. Типографический токен — переносимое именованное правило, которое может использоваться в дизайне, веб-коде и мобильном приложении. Стиль может быть реализацией токена, тогда как токен задаёт общий смысл и связь между платформами.

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

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

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

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

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

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