Let's chatA platform-agnostic, multi-brand design system anchored on 356 tokens, 754 components, and 6,083 variants across seven libraries. Powered EarnIn's brand rebrand across iOS, Android, and a zero-to-one responsive web product.
Design System · 6-month project · Architect + 1 Senior + 1 Mid · 2023
EarnIn is a fintech reimagining how money moves. The product lets users access a portion of their future earnings before payday. EarnIn was growing fast, mid-rebrand, and operating with a mobile-native app while a web product was on the roadmap. The design team was new to Figma. The design-to-engineering pipeline was the bottleneck. Each rebrand decision had downstream consequences across iOS, Android, and the planned web product. Light and dark modes had to work everywhere. The design system needed to scale with the team and the product surface area, not act as a constraint on either.
EarnIn needed a versatile, platform-agnostic, multi-brand system that every team could adopt (including designers new to Figma), that could carry the new brand identity at the moment of rebrand, and that could support the existing native apps plus a zero-to-one web product in parallel.
By the numbers: 356 design tokens · 754 components · 6,083 variants · 7 libraries · iOS + Android + responsive web · AA accessibility compliance.
Design systems, Design operations, Product strategy, UI/UX, User Research, Brand identity and theme development, Brand strategy, Content strategy, Figma, Responsive web product, Consumer product design (UI/UX), Native mobile app design, iOS app design, Android app design
Token architecture, multi-brand design system, shared content library, modular configuration component, card-and-slot strategy, native iOS rebuild, native Android rebuild, responsive web v1, light and dark modes, AA accessibility compliance, training program, documentation, Loom instructional videos
EarnIn was mid-rebrand, growing fast, and running a single mobile native app while a web product was on the roadmap. The design team was new to Figma. Every rebrand decision carried downstream consequences across iOS, Android, and a planned web product that didn't exist yet.
The bottleneck was the design-to-engineering pipeline: no single source of truth for content patterns, legalese being rewritten in three places, and components being rebuilt independently on each platform. Consistency couldn't survive at that pace. The design system needed to absorb the rebrand and enable the web channel — simultaneously.
Behind the design system, two architectural decisions shaped how EarnIn ships product.
The shared content library. Across iOS, Android, and the planned web product, designers kept running into the same flows, the same copy blocks, and the same content patterns. Legalese was being rewritten in three places. Onboarding for user segment A was being designed twice for the same screen on different platforms. Instead of a better hand-off process, we built a custom content library, published as an additional shared library that every designer could pull from. One place for legalese and opt-in copy. One source for onboarding flows by user segment. UX, engineering, product, and legal pointed to the same source of truth.
The modular configuration architecture. Settings are usually a rigid destination: users navigate to Settings, find the right toggle, make a change. But within the core app experience, configuration often needs to happen in-context, in a sheet on a transaction, or a modal on a setup step. We built a single custom form component used both in Settings and in core-app modality. One configuration component, applied per setting, rendered differently based on context.
Together these unlocked two structural improvements: streamlining of internal processes for managing and improving any setting-driven feature, because the source of truth for content and configuration was singular. And a meaningfully lower barrier of entry for shipping v1 of the responsive web channel.
A platform-agnostic, multi-brand design system anchored on 356 design tokens, 754 components, and 6,083 variants across seven libraries.
Once we solidified the application of the new brand to their core product, progress accelerated as we captured those decisions using design tokens. As this was a multi-brand system, meticulous planning was essential for token naming conventions, global value definitions, semantic themes, and light and dark modes. While Figma has made strides with their new variables update, we encountered limitations in creating a comprehensive multi-brand system. To overcome this, we seamlessly integrated the Tokens Studio plug-in, enabling us to effectively manage and synchronize all styles with Figma and Github. This approach not only keeps styles consistently updated but also streamlines the theming process, making maintenance and creation remarkably more efficient.
The system uses two typescales: Inter as the base for product UI (22 type styles across display, headings, labels, text, and superscript), and EarnIn's custom Mori as the marketing typescale for brand moments (7 type styles). The two typescales operationalize the intentional brand moments decision at the token layer.
With the default brand established, switching to a new theme is two token changes and a sync. Light and dark mode switching works via the layers panel directly in Figma, no plugin interaction required. The same mechanism that enables light/dark switching enables new brand themes: change the semantic token values, every component updates.
Two color token adjustments update all interactive states for primary and accent elements — every button variant, every focus ring, every disabled state — automatically. The compounding return of semantic token architecture: one decision propagates everywhere rather than cascading through manual component-by-component updates.
Light mode and dark mode each have parallel semantic token sets covering foreground, background, borders, and illustration semantics. Seven shadow sizes per mode, four control shadow states per mode, five blur sizes. Distinct treatments rather than shared — accurate to how the two modes actually feel different, not just color-inverted.
The typography scale is at the core of the sizing system. Using both font size and line-height to create two contextual applications for components: standalone and contained elements.
Standalone elements can be displayed without the need for any other element to support them (for example, a floating action button). Contained elements are typically surrounded by a div or frame with multiple elements supporting each other (for example, a list item).
Within each of these categories are a range of sizes labeled using the t-shirt system. This allows for all small elements to work together, all medium elements to work together, and so on, while still allowing for mix and matching to define hierarchy.
24 sizing tokens distinguish base from icon, and contained from standalone. Each category has six sizes (XS through XXL). Everything comes together in mathematical alignment.
Once the foundations have been established, we begin the creation of components, starting with the simplest and most atomic elements: content, buttons, icons, and avatars. We use these atomic elements to fashion more complex components such as cards, sheets, modals, and lists. This streamlines the maintenance process by minimizing the number of adjustments required to effect significant changes.
Beyond the standard component library, three structural decisions extended the system's value:
The shared content library. 266 components with 138 variants. Source of truth for legalese, opt-in copy, onboarding flows, and segmented content patterns across UX, engineering, product, and legal. Published as an additional shared library so every designer pulled from a single source.
The modular configuration architecture. Single configuration component rendered in Settings and in core-app modality (sheets, modals). One component, applied per setting, rendered differently based on context.
The card-and-slot strategy. Cards act as the primary container (header, body slot, footer). Designers build body content as a local component using design system primitives and swap it into the card. This both lowered the cognitive load for designers new to Figma and enforced hierarchy.
Documentation and training are part of the system, not an afterthought. We expanded from guided training sessions plus written text and images in Figma to include Loom instructional videos for component usage and methodology context. We invested in deeper technical handoff documentation for token management and automation, recognizing that engineering pickup speed is as load-bearing as designer adoption.
Training workshops became active practice rather than passive walkthroughs: designers brought their own product-area screens, compared pre-rebrand designs to new-system designs, identified what components were used, and recreated views as exercises. Smaller breakouts for larger team workshops let questions surface that would have gotten lost in a single room.
We always want design teams to have everything they need and feel comfortable maintaining the system on their own, although we are always here to support. We prioritize creating thorough documentation: tutorial videos, written usage docs covering states and properties, async office hours through Slack, live workshops throughout the engagement, recorded Loom videos for handoff.
Our next challenge involved rebuilding EarnIn's existing native apps for iOS and Android in both light and dark mode, as well as designing a v1 of a responsive web app, a net new channel for the company. The device and platform-agnostic components seamlessly transitioned to the web app, requiring only the addition of a few essential new components and variants, such as navigation and sheets.
The structural impact shows up in how EarnIn's product team operates today: a single source of truth for content and configuration, designers composing views from cards and local components rather than copy-pasting between files, and a web channel that launched in the same engagement window as the native rebuild rather than as a serial follow-on.
What we learned: Multi-brand token architecture front-loads complexity — defining semantic naming, global values, and theme structure takes significant upfront investment — but the compounding return justifies it. Switching EarnIn's full product surface to a new brand required two color token changes. Without that architecture, it's a manual audit across 754 components. With it, it's two edits and a sync. The shared content library had an equally disproportionate return: one update propagated to three platforms simultaneously. We carry both the semantic-first approach and the content library pattern forward into any system where cross-platform consistency is the core constraint.
A Figma-native, platform-agnostic, and multi-brand design system to unify design for one of the fastest growing B2B tech companies and their ever-expanding customer base and suite of products.
Read more