2022–Ongoing

Design System

Built Roofr's foundational design system, then led the rebuild using Figma variables and slots. 400+ components, 20,000+ weekly inserts across product and marketing teams, and instant dark mode through token-level mode switching.

Design System

Case highlights

20,000+

Weekly inserts

org-wide consumption across product + marketing

400+

Components

shipped across product surfaces

341,000+

Yearly Button inserts

across 220 variants, the most-used component

Role
Staff Product Designer · Systems lead
Team
Solo (v1) · design team led rebuild (v2)
Timeframe
2022–Ongoing
Stakeholders
Design Team · Engineering Leadership
01
  1. Sprint capacity wasted by component recreation. Each project rebuilt similar pieces with minor variations.
  2. UI inconsistency across features. Maintenance overhead for both design and engineering.
  3. Engineering had no source of truth for what “Roofr UI” meant; component-library decisions kept getting relitigated.
02
01

Launch

Adoption proof

  • 01 Component insertion rates across all product and marketing files.
  • 02 Detach rate as a quality signal.
  • 03 Engineering handoff efficiency once the FE library mirrored the DS.
02

Strategy

Org-wide impact

  • 01 Sprint-velocity lift across teams using established components.
  • 02 DS as the source of truth for engineering's component library.
  • 03 Foundation strong enough to support a token architecture.
03
  • An audit drove the build order. Buttons, form inputs, typography, color applications were rebuilt constantly with small variations. Foundational primitives carried almost all the load; Button alone accounted for hundreds of thousands of insertions.
  • A DS only works if the people consuming it want to use it. v1 was built by me for the team; v2 was built by the entire team.
04

The components below are the foundational primitives the audit flagged as most common. v2’s mode switching lives at the token layer; every component reads from semantic variables that resolve per mode, so light and dark are byproducts of the same component definition.

FIG Same component file with two modes. v2 has 4x the variables of v1 (117 → 476) and 80% fewer static styles (116 → 26), because the variables absorbed what styles used to do.

LOOP Input

Form-control input with label, helper text, and validation states. Built early in v1 because input rebuilds were one of the top sources of design-team rework.

LOOP Button

Button component, the most-inserted artifact in the system. 220 variants cover size, intent, icon affordances, and loading states.

LOOP Hint banner

Inline hint banner used for non-blocking guidance and contextual upgrade prompts. Calibrated to feel informational, not interruptive.

REEL Section-level mode switching

Two surfaces in the same canvas, each rendering its own mode. The variable model lets product teams design dark and light states without duplicating components or maintaining parallel files.

REEL Single-toggle full-screen swap

Full screen flips light to dark with one switch. The proof of the v2 architecture: zero additional design work per component, mode resolves at the token level.

05
01

Prioritize by insertion volume

Build order set by frequency-of-use in the existing Roofr surface. Usage validated it: Button (341,898/yr), Tags (83,539), Checkboxes (82,240) lead by an order of magnitude. Resisted visually distinctive components that would have made the system more “marketable” internally.

02

Variables + modes; dark mode is a byproduct

Tokens handle mode switching; every component inherits automatically. Instant dark mode across 400+ components, zero additional design work.

03

Team-wide v2 rebuild

Every designer contributed. Distributed the work and built shared ownership; v2 maintenance is a team problem because the team built it from the inside.

06
  • 20,000+

    Weekly insertions

    Org-wide peak across product and marketing; 16,100/week sustained during the v2 migration window.

  • 400+

    Components

    v1 at 417, v2 at 409.

  • 341,898

    Yearly Button insertions

    Across 220 variants. Foundational primitives carry the volume; rare components seldom break 5,000/yr.

  • 0.13%

    Button detach rate

    428 detaches against 341,898 insertions. The quality signal: designers stay in the system because components fit real workflows.

  • 4x / −80%

    v2 architecture shift

    117 → 476 variables (4x); 116 → 26 styles (−80%). Variables absorbed static styles, which is what enables instant mode switching.

  • Instant

    Dark mode

    Token-level mode switching: every component inherits automatically.

  • Source of truth

    FE component library parity

    Design system became the engineering reference.

08

The charts below back the headline metrics on the public card.

FIG V1 library: 8 teams, 417 components, 116 styles, 117 variables, 16.1k weekly inserts (current consumption during v2 migration; peak was 20K+).
FIG Component-level usage. Button leads at 341,898 yearly insertions across 220 variants with 428 detaches (0.13%). Tags (83,539), Checkbox Base (82,240), Text Input (69,180) confirm foundational primitives carry the load.
FIG Insertion volume over the year, ~20k-50k/week sustained. Top teams: Roofr product design 805,674/yr (74%), Roofr Marketing 277,757/yr (26%). Marketing adoption was the surprise; validated treating brand-adjacent tokens as first-class.
FIG V2 library (codename Shingle): 3 teams adopted so far (still ramping out of v1), 409 components, 26 styles, 476 variables, 5.1k weekly inserts. 117 → 476 variables (4x); styles dropped 116 → 26 (-80%). That absorption enables instant mode switching.

Deep dive

Curious about the specifics?

Adoption cohorts, revenue pivot data, prototype walkthrough videos, and the internal PRD are available on request during a portfolio review.