Design System

Roofr’s design team was rebuilding the same UI primitives across every project: buttons, form inputs, typography ramps, color applications. Sprint capacity went to component recreation, not product work. Engineering had no authoritative source for what “Roofr UI” meant.

I built v1 solo, prioritizing components by actual insertion frequency, not by what felt foundational. v1 served the org for 2.5 years and reached 20,000+ weekly inserts at peak. The usage data was the argument that earned a team-wide v2 rebuild.

v2 focused on Figma variables and slots. Mode switching lives at the token layer, so dark mode is a byproduct of the architecture. v2 has 4x more variables (117 → 476) and 80% fewer styles (116 → 26): variables absorbed what static styles used to do, and every component inherits automatically.

1. Sprint capacity wasted by component recreation. Each project rebuilt similar pieces with minor variations.
2. UI inconsistency across features created maintenance overhead for both design and engineering.
3. Quality and accessibility standards varied meaningfully across product areas.
4. Engineering had no source of truth for what “Roofr UI” meant; component-library decisions kept getting relitigated.

For Roofr’s product-team size, it was all about velocity. Every new feature paid a re-invention tax. A design system would compound: the more teams using it, the more the foundation paid off, and the faster new surfaces shipped.

• Can’t disrupt in-flight design work. v2 rollout had to happen alongside active product design, not block it.
• Figma capability ceiling. v1 shipped before variables existed at the depth v2 uses.
• Variable architecture is path-dependent. A weak token structure in v2 would cause future problems. The mode and variable model had to be correct.
• FE component library parity. A design system is only effective if engineering adopts the same vocabulary. Tight coordination with FE leads across the rollout.
• Prioritize by actual usage, not by what feels foundational. Data-driven prioritization of what components to spend the most time on.

A full audit of Roofr’s existing designs showed the most used pieces: buttons, form inputs, typography, color applications, all rebuilt constantly with small variations. Foundational primitives carried almost all the load.

Some components are used a staggering amount whereas others are rarely touched. Button alone accounts for hundreds of thousands of insertions. Build priority came from the audit data.

Daily design-team workflow needs were another input. A DS only works if the people consuming it want to use it. v1 was built by me for the team, whereas v2 was built by the entire team.

• Lead DS metrics with usage volume, not component count. 400 components is a meaningless number, whereas 20,000+ weekly inserts is impactful.
• Usage data earns resources. v2 got team-wide resourcing because v1’s adoption was undeniable in the analytics. The strongest DS argument is empirical.
• Variable architecture is where the time goes. The right token model turns dark mode from a duplicated component set into a byproduct.
• The edge cases don’t matter as much as you think. The foundational ~10% of components account for the vast majority of insertions. Resist building rare components until they’re actually needed.
• Cross-team adoption is the real validation. When marketing starts using the DS, the system has outgrown its original scope. Design for that from day one.
• If repeating: instrument usage analytics from day one of v1, not retroactively. Earlier data would have made the v2 resourcing argument easier.

Post-launch. v2’s variable architecture is the foundation every new product surface inherits. Storybook and the production component library are migrating to match; on the design side, v2 is the current system of record.

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