Брендбук для мобильного приложения: UI-кит и гайдлайны

Из чего собрать брендбук мобильного приложения: состав и порядок

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

1. Основы бренда: логотип и его адаптации под иконку приложения (App Icon, favicon в сторе), цветовая палитра с указанием HEX/RGB для светлой и тёмной темы.
2. Типографическая система: гарнитуры, размеры для заголовков и основного текста, межстрочные интервалы.
3. Сетка и отступы: базовая единица (обычно 4 или 8px), поля экрана, safe zones под системные элементы.
4. Библиотека компонентов: кнопки, поля ввода, карточки, навигация — каждый в нескольких состояниях (default, hover/pressed, disabled, error).
5. Иконография: стиль (line, filled, duotone), размерная сетка иконок, правила использования.
6. Паттерны и сценарии: онбординг, пустые состояния, ошибки, загрузка — то, что дизайн-системы крупных компаний обычно выделяют в отдельный слой.
7. Гайдлайны по платформам: отдельные страницы или блок с различиями iOS и Android.

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

Брендбук приложения и брендбук сайта — разные документы

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

iOS и Android в одном брендбуке: как развести гайдлайны

Material Design и iOS Human Interface Guidelines построены на противоположной философии. Material — слоистый, структурированный интерфейс с тенями и объёмом. iOS тянется к минимализму и плоским поверхностям, где акцент делается на контент, а не на декоративные эффекты интерфейса. Пытаться навязать один стиль обеим платформам — распространённая ошибка: приложение начинает выглядеть чужим и на той, и на другой системе.

В одном брендбуке эти различия удобно фиксировать не отдельными документами, а parallel-колонками внутри карточки каждого компонента: слева — вариант для iOS, справа — для Android, с общим значением токена цвета и разным значением размера шрифта. Именно так избегают ситуации, когда разработчики на разных платформах трактуют «единый» гайдлайн по-своему.

Адаптивность: от смартфона до планшета

Дизайн-система, рассчитанная только на один размер экрана, ломается при первом запуске на планшете или складном устройстве. Рабочая практика — вводить минимум два режима размера для каждого компонента: compact для сенсорных экранов и обычных смартфонов, regular для больших экранов и устройств с поддержкой мыши или клавиатуры.

• Минимальный размер тела текста — 16px, но на практике комфортнее закладывать 17–18px из-за ограниченного пространства мобильного экрана.
• Межстрочный интервал для основного текста — 1,6 от размера кегля, для заголовков — 1,2; это напрямую влияет на читаемость при уменьшении масштаба.
• Touch-targets — не меньше 44–48px в высоту, иначе пользователь будет промахиваться пальцем по кнопке.
• Контрастность текста — минимум 4.5:1 для обычного текста и 3:1 для крупного, по стандарту WCAG, отдельно проверяется для light и dark темы.

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

Figma как рабочий инструмент: как структурировать файл

Для UI-кита мобильного приложения Figma остаётся самым практичным выбором — благодаря переменным (variables), которые умеют переключаться между темами без создания дублирующих слоёв, и компонентным вариантам, которые закрывают задачу с состояниями кнопок и полей. Структура файла, которая работает и для стартапа, и для команды побольше, выглядит так:

1. Страница «Foundations» — цвета как переменные (с привязкой light/dark), типографические стили, сетка, spacing-токены.
2. Страница «Components» — библиотека с вариантами (variants) для каждого состояния и обеих платформ.
3. Страница «Patterns» — готовые сборки: экран онбординга, форма ошибки, пустое состояние.
4. Страница «Platform Guidelines» — сравнение iOS/Android с примерами экранов рядом.
5. Страница «Examples» — реальные экраны приложения, собранные из компонентов, для проверки, что система работает на практике.

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

Токены, темы и то, что не видно в готовом интерфейсе

Дизайн-токен — это базовая единица описания характеристики компонента: цвет, размер, скругление, состояние. Токены не рисуют интерфейс, но задают правила, по которым он собирается, и именно это делает систему масштабируемой. Показательный пример — банковская дизайн-система Converse Bank: 380+ токенов, две цветовые темы, 41 категория компонентов и больше 2300 вариаций их сочетаемости. Для небольшого приложения такой объём не нужен, но принцип стоит перенять — заводить токены сразу, а не после того, как в интерфейсе накопится десяток случайных оттенков синего.

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