Brandbook for a mobile application: UI-kit and guidelines

How to assemble a brandbook for a mobile application: structure and order

If you are creating a document from scratch, the order is important no less than the content — it makes no sense to start with an icon and palette if the grid and typographic scale have not yet been fixed. Practice shows that for an application of medium size, the following structure is needed.

1. Brand basics: logo and its adaptations for the application icon (App Icon, favicon in the store), color palette with HEX/RGB values for light and dark themes.
2. Typography system: fonts, sizes for headers and main text, line spacing.
3. Grid and spacing: base unit (usually 4 or 8px), screen margins, safe zones for system elements.
4. Component library: buttons, input fields, cards, navigation — each in several states (default, hover/pressed, disabled, error).
5. Iconography: style (line, filled, duotone), icon sizing grid, usage rules.
6. Patterns and scenarios: onboarding, empty states, errors, loading — what large companies usually separate into a distinct layer in their design systems.
7. Platform guidelines: separate pages or a block with differences between iOS and Android.

For a small team or startup, this list can be condensed to three blocks — palette and typography, components, patterns — but skipping the section on light/dark themes and platform differences should not be done: it is exactly here that designer expectations and reality in the store often diverge.

Application brandbook and website brandbook — are different documents

The web brandbook lives in one browser, with one interaction model — cursor and keyboard. The mobile document must address three tasks that the website simply lacks: adaptation for finger use, for two competing operating systems, and for the user's switching of the theme in system settings.

iOS and Android in one brandbook: how to separate guidelines

Material Design and iOS Human Interface Guidelines are built on opposite philosophies. Material is a layered, structured interface with shadows and volume. iOS leans toward minimalism and flat surfaces, where emphasis is placed on content rather than decorative interface effects. Trying to impose one style on both platforms is a common mistake: the app begins to look out of place on both systems.

These differences can be conveniently documented within one brandbook, not in separate documents, but in parallel columns inside each component card: on the left — the iOS variant, on the right — the Android variant, with a shared token color value and different font size values. This approach avoids the situation where developers on different platforms interpret the 'unified' guideline differently.

Adaptability: from smartphone to tablet

A design system designed only for one screen size breaks on first launch on a tablet or foldable device. Working practice — to introduce a minimum of two size modes for each component: compact for touchscreens and regular smartphones, and regular for larger screens and devices with mouse or keyboard support.

• The minimum text body size is 16px, but in practice it is more comfortable to plan 17–18px due to the limited space of a mobile screen.
• The line height for main text is 1,6 of the font size, for headings — 1,2; this directly affects readability when scaling down.
• Touch targets — no less than 44–48px in height, otherwise the user will miss the button with their finger.
• Text contrast — at least 4.5:1 for regular text and 3:1 for large text, according to WCAG standards, separately verified for light and dark themes.

A tablet requires a separate grid rule: columns that on a phone collapse into a single column, on a tablet become two or three columns, and this must be explicitly described with exact breakpoint values, not left to a developer's guess.

Figma as a working tool: how to structure a file

For a mobile app UI kit, Figma remains the most practical choice — thanks to variables that can switch between themes without creating duplicate layers, and component variants that handle button and field states. The file structure that works for both a startup and a larger team looks like this:

1. The «Foundations» page — colors as variables (with light/dark binding), typography styles, grid, spacing tokens.
2. The «Components» page — a library with variants for each state and both platforms.
3. The «Patterns» page — ready-made builds: onboarding screen, error form, empty state.
4. The «Platform Guidelines» page — a comparison of iOS/Android with example screens side by side.
5. The «Examples» page — real app screens assembled from components, to verify that the system works in practice.

This approach was applied by VK when building a cross-platform design system: instead of three separate layouts for three platforms, a designer works with one, and platform differences are handled via tokens and variables. This eliminates triple duplication of work, which still occurs in small teams that create a separate file for each OS.

Tokens, themes, and what is not visible in the finished interface

A design token is the basic unit for describing a component's attribute: color, size, rounding, state. Tokens do not draw the interface, but set the rules by which it is assembled, and it is this that makes the system scalable. A telling example is the banking design system Converse Bank: 380+ tokens, two color themes, 41 component categories and more than 2300 variations of their combinability. Such volume is not needed for a small application, but the principle is worth adopting — to create tokens upfront, rather than after a dozen random shades of blue have accumulated in the interface.

Two-themed components are a mandatory, not an optional, requirement for the mobile brandbook. The user switches the theme in the phone's system settings, and if the app is not ready for this at the component level, light text on a light background will appear not in a test environment, but with a live user. Therefore, every component in the UI kit for the application must be fixed in at least two versions — this is the main structural difference from a classic web brandbook, where the theme is almost always one.