Документация типографики: что включить дизайнерам и разработчикам

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

Дата актуальности: 28 августа 2026 года.

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

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

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

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

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

Типографическая система становится понятной, когда размеры связаны не с отдельными экранами, а с ролями. Вместо десятков несвязанных стилей создайте набор текстовых токенов: Display для крупных промо-заголовков, Heading для заголовков разделов, Body для основного текста, Label для подписей элементов управления и Caption для второстепенной информации. Названия могут быть другими, но логика должна быть последовательной.

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

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

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

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

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

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

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

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

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

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

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

Представим карточку статьи в блоге. Заголовок карточки использует роль Card Title, основной анонс — Body Small, дату публикации — Meta. В документации нужно указать, что Card Title сохраняет высокий контраст с фоном и ограничивается двумя строками, Body Small допускает больше строк и имеет увеличенную высоту строки, а Meta не должен использоваться для важных сообщений. При переполнении заголовок обрезается по правилу компонента, а не произвольным уменьшением размера.

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

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

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

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

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

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

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

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

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

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

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