Design System Library

Branch's dashboard grew faster than its shared design language. A familiar component still needed an answer: which version should engineering build? Designers specified cards again, and QA spent time catching visual differences across surfaces.

Each question was small. Repeating it across squads made it expensive. The design system needed to carry an agreed decision from design into code, then make that decision easy to find the next time someone needed it.

I started with shared tokens: named values for color, spacing, and typography, synced to code. That gave designers and engineers the same foundation beneath the screens. I brought icons and interactions into the shared language too.

The library grew to 60+ components, including cards, forms, tooltips, and data widgets. Each needed guidance on when and how to use it. Searchable patterns, examples of what to do and avoid, and accessibility notes made the documentation part of the product.

A reusable card only saves time if the next person can tell that it is the right card.

Shared components create a second responsibility: explaining what changes when the library changes. I introduced Major.Minor.Patch versioning to make breaking and additive releases explicit for engineering adoption.

Semantic Versioning gives that distinction a precise meaning: major versions signal incompatible API changes, minor versions add compatible functionality, and patches make compatible fixes. It communicates the intended compatibility of a release; teams still need to verify upgrades.

I migrated high-traffic modules first: cards, forms, and navigation. Each migration included QA gates, with visual regression checks on token changes. Checking shared foundations helped us look for changes that could spread across screens while reducing repeated pixel corrections in individual reviews.

The original project summary also reports that the library cut QA time in half, without specifying that measure's scope. I keep that broader claim separate from the 40% engineering QA reduction on migrated surfaces and the 50% reduction in visual drift reports.

The practical gain was fewer consistency questions consuming design time. We could spend more of it on journeys, onboarding research, and self-serve growth.

A good library gives the team fewer old decisions to make, and more time for the next useful one.

• −40% engineering QA time on migrated surfaces.
• −50% visual drift reports from design review.