Mobile design system: what it is and how to build one

A mobile design system is the set of shared parts an app is built from: design tokens such as colors and spacing, reusable components such as buttons and list rows, and the rules for using them. The same parts exist twice, once in the design file and once in code, under the same names. When that's true, a designer and a developer who both say "primary button" mean the same object.

Teams with a system ship more consistent screens faster. Teams without one design the same card over and over, slightly differently each time, and then pay developers to build each variation.

What a mobile design system contains

Design tokens

Tokens are named values. You store the decision "our accent is #1F6FEB" once, call it primary, and use the name everywhere. Change the value later and every button follows.

Name tokens by role. A token called blue-500 tells you what it looks like, and primary tells you where to use it. Dark mode depends on the difference, since background can flip from white to near black and every screen that used the role comes along.

That's around thirty values, and an app can run on fewer.

Components

Components are the reusable pieces built from tokens. A first version of a mobile system needs about ten:

• button (primary, secondary, text)
• text field
• list row
• card
• top bar
• tab bar
• bottom sheet
• switch and checkbox
• chip or tag
• toast or banner

Each one needs its states designed: default, pressed, disabled, loading, and error where it applies. A button with only a default state is half a component, and the developer will invent the other half.

Patterns

Patterns are how components combine into familiar screens: a form with validation, a list with an empty state, a confirmation before deleting something. Writing down three or four saves you from re-arguing them on every new feature.

Documentation

A line or two per component on when to use it and when not to. "One primary button per screen. If there are two equally important actions, the screen is doing two jobs." Rules like that are what stop a system from decaying into a sticker sheet.

Start from the platform, then theme it

You don't have to draw a switch from nothing. Apple's Human Interface Guidelines and Google's Material Design 3 describe complete component sets that are already accessible, already familiar to users and already built into the platform toolkits. Material is designed to be themed: you supply color, type and shape, and its components take them on.

For most apps the sensible system is the platform's components with your tokens applied, plus custom components only where your product does something the platform doesn't cover. The iOS and Android design guidelines post compares the two sets.

How to build one, in order

1. Audit what exists. Screenshot every screen and count the distinct colors, text sizes, radii and button styles. The list of near-duplicates is your to-do list.
2. Settle the tokens. Pick one value per role and write them down. If you already have a mobile app style guide, this step is done.
3. Build the ten core components in your design tool, with states, using only tokens. In Figma that means variables for the tokens and components with variants.
4. Build the same components in code under the same names, reading the same token values.
5. Rebuild two or three real screens from the new parts. This is the test. Anything you couldn't build reveals a missing component or a rule that's too strict.
6. Document as you go, briefly.

Steps 3 and 4 work best done together, one component at a time, with the designer and developer comparing results. Systems designed in full and then handed over tend to arrive with components nobody can build as drawn.

How big should it be?

As small as you can get away with. A solo founder needs tokens and a handful of components, which is an afternoon of work. A team of five benefits from the full ten components and written rules. Versioning, contribution processes and a dedicated maintainer start earning their cost when several teams or several apps share one system. Building that machinery for a three-screen prototype is a common way to avoid working on the product.

Keeping the system in a file AI tools can read

Design systems increasingly have a third copy beside design and code: a plain text description that AI tools read before they generate anything. DESIGN.md is the common format. It lists your tokens and rules in Markdown, lives in the repository, and means a generated screen starts from your system instead of the tool's default taste. Our DESIGN.md examples show what a finished one looks like.

Design systems in Outclass

Every Outclass project is designed as one system from the first screen. All screens share a stylesheet of role-named color tokens and component classes, so the card on the home screen and the card in settings are the same component. The Theme panel edits the tokens, and a change there reaches every screen. You can import an existing system as a DESIGN.md, and when you copy screens to Figma they arrive as named layers with auto layout, ready to be turned into Figma components.