Building Design Maturity at Figure

COMPONENTS

Rebuilding from Screenshots to Components

Rather than a separate "design system sprint," I embedded component work directly into real design tasks. When working on a feature, I retraced the existing product screens into proper Figma vector components as I went - making every subsequent task faster.

Following Dan Mall's contribution model: design system work hides inside product work. Build the system by building the product.

• Retraced screens into proper Figma components, working feature by feature rather than in a separate system sprint.
• Met with developers to review components before grooming to verify implementability — not just visual correctness.
• Added slot-based container components (e.g. Bottom Sheet) for flexible composition.
• Converted logos from bitmap to scalable Figma components with toggleable tags for production and local builds.

Not all components got it right the first time. Early builds were designed for maximum Figma flexibility — every variant and property exposed, every combination possible. Developers flagged the problem: that flexibility created invalid states that don't exist in code, making it unclear what to implement.

The fix: several components were rebuilt around a closer 1:1 mapping between Figma and implementation — same variants, same states, same names. Where Figma genuinely can't constrain an edge case, an annotation explains the intent instead. The change benefited designers too: fewer opportunities to accidentally combine properties into something that doesn't correspond to anything in production.

TOKENS

Figure Design Tokens

Developers had named tokens explicitly as a pain point. I made it the next focus. I studied design tokens seriously — completing Brad Frost's Subatomic course and Dan Mall's Design Systems 101 — then built Figure Design Tokens in Figma as a first-class system.

One constraint: scheduling and daily workload meant the team couldn't workshop the token architecture together before building. I defined the first version independently, validating choices with developers as I went rather than presenting a finished structure for sign-off. The first version is working well, and is understood to be a living system that will continue to evolve.

The tokens were introduced on mPOS, a new product in active development. Greenfield products are the right entry point: tokens can be there from the start, and the work integrates naturally into sprints rather than requiring a separate migration effort.

• Created Figure Design Tokens Figma file: color, spacing, typography, border - each documented with values and names.
• Aligned token names with developer; renamed collections to Pascal Case for clean export.
• Proved and shipped the full pipeline end-to-end.

• Created Whitelabel Tokens — a single source of truth for the 3 merchant brand variations. Switching a design between brands now takes two clicks rather than manually replacing every colour value across every file.
• Documented token changelog with semantic versioning aligned to dev expectations.

The tooling choice was deliberate. Token Studio and Supernova were both considered — each offers a polished UI layer for token management. The case against them was vendor lock-in: a third-party tool's pricing change or deprecation would break the pipeline.

Native Figma Variables with Style Dictionary won instead because:

• It follows the W3C Design Tokens community specification.
• The pipeline is owned entirely by the team.
• Any developer can read and modify a JSON file or Style Dictionary config without a plugin licence.

HANDOFF

Closing the Design–Dev Gap

A component library and token pipeline only deliver value if they reach developers accurately and early. The bottlenecks at that boundary — late design visibility, mismatched naming, no version tracking — were as much a process problem as a tooling one.

• Got read-only access to Figure's source code on GitHub - could now read actual color values in code instead of guessing from screenshots, and compare naming between Figma and implementation.
• Used Storybook to pair production components with their Figma counterparts and test alignment.
• Named components consistently: "component extraction" sessions during grooming aligned Figma names with code names.
• Established a shared handoff process: designers set "Ready for dev" on components, link the exact Figma version history snapshot in Jira, and notify developers of changes via Slack.
• Thanks to the Project Manager, the design team moved from Notion to Jira - design and development tasks now tracked together under the same stories and epics.

COLLABORATION

Improving Collaboration Practices

Beyond tooling and process, the research revealed that collaboration itself needed to change. Designers were too far downstream in the development process.

• Joined grooming sessions regularly - answered feasibility questions on the spot, caught missed edge cases before dev started.
• Created a design review checklist in collaboration with PM, covering hover/pressed states, empty states, edge cases, icon viewboxes, shadow application, and spacing - adopted by the design team before handoff.
• Designers started reviewing each other's work before grooming.
• Product Manager began attending grooming, closing the NY/CZ communication loop.
• Lead developer became routinely involved in technical feasibility scoping, not just for major projects.
• Provided Figma training to non-designers so developers could navigate and inspect designs independently.