This is the first case study in the Scanat design system series. Part 1 covers the initial 0→1 setup and later file-architecture changes; Part 2 focuses on governance issues that emerged after three years of use and on extending the system into engineering.

Snapshot

2. Established a two-layer Color Token model and six component categories;
3. Completed missing component states and end-to-end UI flows;
4. Reorganized the files into a three-tier architecture as cross-platform and white-label work expanded. | | Current Status | The initial system shipped into daily use and continued to evolve over the following three years (see Part 2). |

TL;DR

When I joined Scanat, the existing Figma files supported day-to-day design work but lacked consistent styles, reusable components, and file organization. Within my first two weeks, I built the initial design-system foundation: standardized color, typography, spacing, and other core rules, introduced a two-layer Color Token model, organized six component categories, and completed common interaction and page states.

As Mobile, Web, and white-label work expanded, the original single-file structure became heavy again. I then separated design resources into three layers: foundational assets, platform design systems, and production UI project files.

This case focuses on how the system was built from 0→1 and why its file architecture had to evolve as the product grew.

1. Problem

What Was Wrong with the Existing Figma Files

The design files I inherited could support feature work, but they had not yet formed a coherent design system. The main issues fell into four areas:

• No global styles. Color, type size, weight, spacing, radius, and shadow were not centrally defined, so visually similar styles often used different values across pages;
• Many elements were not componentized. The same button or input could exist independently across multiple pages, making style changes manual and error-prone;
• Inconsistent color usage. For example, similar text and UI hierarchy levels on the same page could use four slightly different blacks;
• Everything lived in one file. Production screens, assets, and in-progress features were all mixed together, slowing the file as it grew and making future white-label variants harder to manage.

Constraint

The rebuild had to happen without pausing ongoing product work. Instead of writing a complete specification first and switching everything at once, I prioritized the issues that most affected design and handoff, put the new system into real use quickly, and migrated legacy screens incrementally.

2. Approach

The initial 0→1 build progressed through four stages.

Stage 1: Audit and Consolidate the Existing UI

I first audited existing screens and UI elements to identify duplicated styles, near-identical components, and missing states. I then componentized scattered elements and consolidated duplicate or nearly identical color, typography, and component styles.

Stage 2: Establish Global Styles and Tokens

After the audit, I established foundational rules for color, typography, radius, shadow, and spacing, then made components reference those shared rules. For color, I avoided binding components directly to raw values and instead introduced two Token layers: Primitive for base colors and Semantic for UI roles such as brand, text, and status. Components referenced the Semantic layer.

This made later brand or theme changes easier because the semantic mapping could change without editing every component individually.

Stage 3: Organize and Expand Components

In the old files, UI elements mostly lived with individual screens, so the same control could have separate copies across features. I reorganized the library by component responsibility: product screens referenced shared components instead of maintaining local variants. All UI elements were grouped into six functional categories:

This step was not just about wrapping old elements into components. I also used Figma Variants and Properties to complete sizes, visual styles, and interaction states.

For example, a button that originally had one style and two sizes was expanded to four styles and five sizes, with Default, Active, Disabled, and Error states defined explicitly. Engineers could see the complete state model during handoff instead of inferring behavior from a single static screen.

Stage 4: Reorganize Screens and Complete UI Flows

Once foundations and components were stable, I returned to the production UI files, regrouped screens by feature, and completed states that had been missing from the original designs, including:

• Empty State
• Loading / Skeleton
• Error
• Success

These states had previously been clarified ad hoc during development, so I brought them back into the full design flow as explicit product states.

Stage 5: Evolve from a Single File to a Three-tier Architecture

The first system solved foundational consistency, but as Mobile, Web, and white-label projects grew, the single-file structure became heavy again. I separated responsibilities into three layers:

Separating product screens from the component libraries allowed platform components to be maintained independently, while each white-label project could have its own UI Project File and still reference the shared assets and systems.

3. Outcome

• Completed the first design-system foundation within my first two weeks and put it into use for subsequent product design and engineering handoff;
• Standardizing component sizes, Variants, and interaction states made handoff specifications more complete, with consistently positive feedback from PMs and engineers;
• App and Web component libraries became independently maintainable from production UI screens, while white-label projects could create their own UI Project Files and continue referencing shared resources.

The system remained in active use for the next three years. The naming, documentation, and governance issues that emerged over time are covered in Scanat — Design System Governance & Design-to-Code .

4. Reflection

1. In the 0→1 phase, usability came first. A complete specification mattered less than quickly standardizing core styles, components, and production screens so the new system could enter real work and be completed incrementally.
2. System structure has to evolve with the product. The two-layer Token model and three-tier file architecture solved color reuse, cross-platform scale, and project-file growth, but structure alone cannot replace ongoing governance.
3. Building and maintaining a design system are different problems. Part 1 was about establishing the system; after three years of use, naming, documentation, and component-governance issues became the starting point for Part 2.