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

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

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

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

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

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

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

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

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

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

Названия должны описывать функцию, а не только внешний вид. Стили «Большой серый» и «Жирный 14» быстро становятся непонятными после редизайна. Семантические названия сохраняют смысл при изменении визуальных параметров: Body Default может стать крупнее, но останется стилем основного текста.

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

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

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

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

Практичная структура состоит из трех уровней. Базовые токены описывают исходные значения, например размер 16 или вес 400. Семантические токены связывают эти значения с задачей, например color.text.primary или typography.body.default. Компонентные токены уточняют применение внутри конкретного компонента, например button.label или input.helper.

Выберите единый формат именования и не смешивайте в одном наборе названия ролей, размеров и компонентов без правила. Например, typography.heading.section и typography.body.default легче поддерживать, чем набор разрозненных имен с разной логикой. В changelog фиксируйте переименование, удаление и изменение значения токена, потому что эти действия могут повлиять на код и макеты.

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

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

Предположим, продукт использует четыре уровня иерархии. Page Title применяется один раз для главного заголовка экрана. Section Heading обозначает крупный раздел. Body Default используется для основного чтения. Caption предназначен для вторичной информации и не должен становиться единственным способом передать важное сообщение.

В документации недостаточно перечислить эти названия. Для Page Title укажите пример заголовка длиной в одну-две строки и правило поведения при переполнении. Для Body Default покажите абзац с несколькими строками и ссылкой. Для Caption добавьте предупреждение: стиль подходит для пояснения, но не должен использоваться для основного действия или критически важного статуса.

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

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

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

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

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

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

Основным должно быть название по назначению: Body Default, Page Title, Helper Text или Button Label. Размер и вес лучше указывать в параметрах карточки. Такой подход сохраняет смысл документации после редизайна и не заставляет переименовывать стиль при изменении его визуальных характеристик.

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

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

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

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

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

Если для проекта нужен собственный шрифт или визуально согласованное шрифтовое решение, создайте его на fontgenerator.ru и добавьте правила использования в документацию дизайн-системы.