One design system for your website and your mobile app

A common request reaches us in the same shape every time: "We have a website, now we want an app, and it should look the same." Then the designs arrive as forty Figma frames, each with slightly different greys, three button heights, and no notes on what happens when the text is longer than the mockup assumed.

The fix is not more pixel-perfect screens. It is agreeing on a small set of design decisions early, writing them down once, and letting the web build and the Android and iOS builds read from the same place. This is how we set that up for clients who have a React or Laravel front end and a mobile app, or plan to.

Start with tokens, not components

Before anyone draws a login screen, we ask the designer for a short list of named values:

• Colours by role, not by appearance: text-primary, surface, border-subtle, danger, accent. Not "blue 500".
• A type scale with five or six sizes and the line height for each.
• A spacing scale. Four or eight point steps are enough.
• Corner radius, and two or three elevation levels.

That is the whole starting set. Once these exist, they go into a single JSON file in the repository. From it we generate CSS variables for the web, a Kotlin or XML resource file for Android, and a Swift asset or constants file for iOS. A tool such as Style Dictionary does this job, but even a small Node script is fine for a first project.

The payoff shows up months later. When the client's brand colour changes, or when someone finally asks for dark mode, you change one file and rebuild three products. Without tokens, that request becomes a bug hunt through hundreds of hard-coded hex values.

Design the states, not just the happy path

Most handoff problems come from screens that were only drawn when everything worked. We ask for these states on every list, form and button before development starts:

1. Loading, with a skeleton or spinner and a decision about how long to wait before showing it.
2. Empty, with a sentence that tells the user what to do next.
3. Error, with wording that says what went wrong and whether retrying helps.
4. Slow or offline, which matters far more on a mobile network than on an office connection.
5. Long content: a 60-character product name, a name in Nepali script, a currency amount with many digits.

The fifth item catches real layout bugs. A card that looks perfect with "Ram Shrestha" breaks with a long company name. It is cheaper to find that in Figma than in a QA round.

Accessibility is a delivery requirement

We treat accessibility as part of the definition of done, not a later polish phase. A few checks that cost almost nothing at design time and a lot at rework time:

• Contrast. Body text should meet the WCAG 2.2 AA ratio of 4.5:1 against its background. Check it on the token pairs once, not on every screen.
• Touch and click targets. WCAG 2.2 sets a minimum of 24 by 24 CSS pixels for pointer targets at AA. Apple's guidelines suggest 44 by 44 points and Material suggests 48 by 48 dp for touch. We design to the larger number on mobile.
• Focus order and visible focus. On the web, a keyboard user should see where they are. WCAG 2.2 also says a focused element must not be hidden behind a sticky header or cookie banner, which is a very common failure.
• Labels. Every input needs a real label, not placeholder text that vanishes when typing starts. On mobile, the same label is what VoiceOver and TalkBack read aloud.
• Dynamic type. On iOS and Android, users change their system font size. Layouts have to survive 130 to 200 percent without clipping.

None of this requires a separate accessibility project. It requires a short checklist in the pull request template and a designer who knows the list exists.

Handoff that developers can use

We ask designers to do three things that make development faster:

• Use the same names in Figma as in the token file. If the design says surface-raised, the code says surface-raised.
• Build components with variants (size, state, icon or no icon) rather than copying frames. A React button, a Compose button and a SwiftUI button should each map to one Figma component.
• Annotate behaviour that cannot be seen: what animates, what is debounced, what gets saved when the user goes back.

We also push back, politely, on designs that ignore platform habits. An iOS user expects swipe-back navigation. An Android user expects the system back button to work. Forcing the web pattern onto both usually makes the app feel foreign, and it creates review friction at the App Store and Play Console as well as with users.

Where a little AI helps, and where it does not

We do use AI tools in this workflow, in narrow places. A script that reads the token file and flags any component in the codebase using a raw colour value is useful. A model that drafts the first version of alt text, error messages or empty-state copy saves time, as long as a person edits it before it ships. We do not let a model decide the layout or the visual identity. Those choices belong to the client and the designer, and they need to stay consistent over years.

What this looks like in a project

For a typical client with a Laravel or WordPress back end, a React web front end and a mobile app planned for later, our first two weeks of design work usually produce:

• A token file and a small component library in Figma.
• Five to eight core screens with all states drawn.
• An accessibility checklist agreed with the client.
• A React component set that already reads the tokens, so mobile can follow without a redesign.

When the mobile build starts, the team is not arguing about whether a button is 40 or 44 pixels high. That argument was settled in week one.

If you have a web product and a mobile app that drifted apart, or you are about to start both, send us the current designs and the list of platforms. We can tell you quickly whether a tokens-first cleanup is a few days of work or a proper redesign.