A design system starts as a shared vocabulary and ends up as shared infrastructure. When it works, product teams ship faster and users experience a consistent, polished product. When it breaks down, you get duplicated components, diverging visual styles, and engineers copy-pasting code between repositories. Scaling a design system across web and mobile requires deliberate decisions about ownership, tooling, and governance — not just a well-maintained Figma file.
Tokens Are the Foundation
Design tokens — named values for colours, typography scales, spacing, border radii, and shadows — are the lowest-level building block of any cross-platform system. They should be the single source of truth that both web and mobile consume.
Tools like Style Dictionary let you define tokens once in JSON and compile platform-specific outputs: CSS custom properties for web, JavaScript constants for React Native, and XML for Android. This eliminates the manual syncing work that causes web and mobile to drift apart over time. Every colour or spacing decision made in Figma should map directly to a token, and every token should exist in your Style Dictionary config.
Component Ownership Needs Explicit Rules
The question "who owns this component?" becomes critical at scale. Without clear ownership, components get modified by whoever needs a change, reviews are inconsistent, and breaking changes ship without warning. Establish a component ownership model early:
- Core components (Button, Input, Modal, Typography) — owned by the design systems team, versioned strictly, changes require design review
- Feature components (ProductCard, CheckoutSummary) — owned by the feature team, built using core components
- Page-level layouts — owned by individual product squads
Document this model in your design system's contribution guide and enforce it in code review.
Versioning and Release Strategy
Treat your design system like a public library. Use semantic versioning: breaking changes increment the major version, new components increment minor, bug fixes increment patch. Publish to a private npm registry so teams can upgrade on their own schedule rather than being forced onto changes that may require significant code updates.
Maintain a changelog that distinguishes between breaking changes, additions, and deprecations. When deprecating a component, keep it functional for at least one major version cycle and provide clear migration instructions. Teams working on large codebases need time to migrate — breaking changes without runway destroy trust in the system.
Cross-Platform Consistency Without Over-Engineering
Web and mobile are different platforms with different interaction patterns and platform conventions. A design system should not try to make them identical — it should make them feel like they belong to the same family. Shared tokens handle colour, spacing, and typography. Platform-specific components handle interaction patterns (bottom sheets on mobile, dropdowns on web, for example).
Resist the temptation to build universal components that abstract over both platforms unless you have a very good reason. The abstraction cost usually outweighs the consistency benefit, and it makes the system harder to understand for engineers who join later.
Keeping the System Alive
The design system is never finished. Schedule regular audits to identify components that have drifted from the spec, tokens that are no longer used, and documentation that is out of date. A Storybook instance that is automatically deployed on every merge keeps the component library visible and discoverable. Pair it with visual regression testing using tools like Chromatic to catch unintended changes before they reach production.