Branch · 2024 to 2026

A design system for a multi-product platform.

Building the design system that scales a complex enterprise SaaS surface through a multi-year product transformation. Component library, governance, intake process, dark mode readiness, and design-engineering ownership model.

Role

Sr. Director, Product Experience

Duration

Multi-year program

Surface

Multi-product platform

Adoption

94% across product surface

The problem

A growing platform, an aging system.

Branch's product surface had grown across multiple products and customer segments. The existing design system was struggling to keep up: components had drifted, custom one-offs had multiplied, design tokens were inconsistent, dark mode was unsupported, and Figma-to-code alignment was unreliable.

The cost was real. Designers and engineers spent significant time recreating what should have been shared infrastructure. New product modernization work risked compounding the inconsistency. Customer-facing UI quality varied across products. Without a stronger system, every new product surface added entropy.

The approach

Foundation, governance, adoption.

Foundation

Rebuild the building blocks.

Typography revisions, badge component corrections, design token normalization, dark mode feasibility, and a production audit that mapped every inconsistency back to a system gap. The work of making the primitives right so everything built on top could trust them.

Governance

Rules, intake, ownership.

A formal governance model with a moratorium on custom components, a structured intake process for new requests, and a defined ownership model between design and engineering. Without governance, a design system entropies back into a component zoo.

"No new custom components."

Adoption

Make the system the path of least resistance.

Public documentation, Storybook integration, a canonical spec repository for component documentation, training sessions, and integrating the system into the broader product modernization program. Adoption isn't enforced. It's earned by making the system easier than the alternative.

The system itself

Light. Dark. One system.

Inputs. Buttons. Checkboxes. Tabs. Dialogs. Alerts. Dropdowns. Pagination. Empty states. Progress. Toasts. Tokens for primary, accent, border, destructive, positive, caution, magenta, purple, and orange in foreground and background variants. All shipped from one source of truth across both themes.

Branch design system overview in light theme showing the full component library: inputs, buttons, checkboxes, radio buttons, tabs, dialogs, alerts, dropdowns, pagination, empty states, progress bars, toasts, and a complete color token palette with primary, accent, border, destructive, positive, caution, magenta, purple, and orange variants — Light theme

Default surface

Branch design system overview in dark theme showing the same component library and color tokens applied to a dark surface, demonstrating theme-aware foreground and background pairs across the whole system — Dark theme

Theme-aware tokens

Click either canvas to view at full size.

The operational artifacts

What we built, what we shipped, what we measured.

Component library

Reusable components across primitives, composites, and patterns. Versioned, documented, and synchronized between Figma and code.

Storybook integration

Live component playground for engineers. Documentation, props, states, and accessibility specs in one place.

Canonical spec repository

Single source of truth for component specifications, design tokens, and usage guidelines accessible to design and engineering.

Public documentation

Public-facing system documentation for designers, engineers, and product partners. Adoption requires accessibility.

Governance model

Formal governance with named owners, decision rights, and a moratorium on new custom components. Rules of the road.

Intake process

Structured intake for new component requests. Triage, prioritization, and a defined path from request to release.

Production audit

Full audit of live product surfaces to map system drift, inconsistency, and the cost of custom one-offs.

Dark mode readiness

Feasibility assessment, token architecture, and roadmap for dark mode support across the platform.

Training sessions

Structured onboarding and training for designers and engineers adopting the system. Reduces support burden.

The governance flow

How a request becomes a tracked, finished system change.

Before governance, every team was creating their own custom components and nothing was getting logged. The system was reverting to the problem the system was supposed to solve. The fix was a real intake with three defined paths, a triage gate, and auto-generated tracking work per request type. The rule that made it work was simple: no new custom components.

One form · One gate · Three paths · Sub-issues auto-generated per path · One source of truth

The rule that made it work

No new custom components.

The design system stays stable and untouchable during feature development. New patterns go through the intake. Without that rule, every team optimizes for their own feature timeline and the system silently drifts back into a component zoo. With it, the system gets cared for.

Before and after

From scattered to systematic.

The design system didn't ship as a deck. It shipped as a product. Two side-by-side comparisons of the same screen, before the system and after. Same data, same purpose, different experience.

Before state. The original Branch Summary dashboard in the legacy design language, showing a dense table of metrics, an unstyled line chart, and a sidebar of navigation links in marketing blue — Before · Summary dashboard

Legacy design language. Dense layout, no hierarchy, no AI surface.

After state. The new Branch Home dashboard built on the design system, showing a personalized greeting, the Ivy AI assistant search box, and three AI-recommended insight cards with clear typography hierarchy and a dark theme — After · Home

Card-based, personalized, Ivy assistant integrated. Dark theme, system tokens, clear hierarchy.

Before state. The legacy Branch Partner Management screen showing a long sidebar list of ad partners, a tabbed settings interface, and a QR code area with no clear signal of which partners are actively delivering value — Before · Partner Management

Long sidebar of partners. Dense tabbed settings. No signal hierarchy.

After state. The new Partner Network Deep Linking screen showing active partner networks as cards with conversion rate and lift metrics, an Ivy recommendation banner at the top suggesting an action, and inactive networks in a secondary section — After · Partner Network Deep Linking

Active partners surfaced with conversion lift. Ivy recommendation banner. Clear primary and secondary states.

The legacy product shipped without a system. The new product shipped because of one.

The ownership model

Design and engineering as co-owners.

What design owns

Component specifications, props, and states
Design tokens and visual language
Accessibility standards and contrast requirements
Usage guidelines and pattern documentation
Figma library structure and governance
Intake triage and prioritization

What engineering owns

Component implementation in code
Storybook maintenance and updates
Token implementation and theming infrastructure
Release process and versioning
Accessibility implementation and testing
Performance and bundle size discipline

Co-ownership isn't a slogan. It's a decision rights model. When design and engineering both have skin in the system, the system gets cared for. When neither owns it, the system rots.

The system in production

One system. Many surfaces. Two themes.

The proof of a system is whether it scales. Four shipped product surfaces built on the same tokens, components, and patterns. Different product areas, different data densities, different themes. One system underneath all of them.

Organic channel performance dashboard in dark theme showing three metric cards for click-to-install at 2.1 percent, click-to-open at 30 percent, and app adoption rate at 30 percent, with vertical benchmark and best performance indicators, and a six-month performance trend line chart — Analytics surface

Email campaign metrics with vertical benchmarks. Six-month performance trend with CTI and CTO benchmark lines.

Channel performance dashboard showing a configured experiment with filter dropdowns for ad partner, campaign, goal event, and targeting, plus campaign incrementality results including Branch Confidence Score, statistical significance, conversion rate lift of 50.4 percent, and a test versus control line chart — Experiment surface

Campaign incrementality testing. Branch Confidence Score, p-value, 50.4% conversion lift, test vs control chart.

Channel performance dashboard with four KPI cards showing total QR scans at 102.4 thousand, bill pays at 68.9 thousand, conversion rate at 67.3 percent, and active employees at 2,847, plus a US store performance heat map visualizing QR code scan activity across retail locations — Geographic surface

Store performance heat map. KPI cards with year-over-year deltas, sparklines, and US geographic density visualization.

Partner directory screen in light theme showing ad partner cards in a three-column grid with status badges for enabled and needs-setup states, volume and quality grades, and click-through rate metrics, demonstrating the same design system applied to a different product surface — Same system, different product

Same component library. Different customer surface. Light theme instead of dark. The system travels.

Click any surface to view at full size.

What the system did

Adoption, velocity, discipline.

01 · Adoption

94%

System adoption across the modernized product surface. Against a 90% target. Earned through documentation, training, and quality rather than enforced through mandate.

02 · Velocity

2×

Throughput per product pod after the system reached steady state. Less time rebuilding the basics. More time shipping the work the customer can see.

03 · Discipline

Custom components built outside the system since governance went live. Every new pattern came through intake. The rule held.

Foundation made the system trustworthy. Governance made it durable. Adoption made it the path of least resistance.

What I learned

Three lessons for anyone scaling a system.

Audit first, build second.

The production audit was the unlock. You can't fix a system you haven't measured. Every "we need a new component" request can usually be solved with an existing component plus better documentation.

Governance is the work.

A design system without governance is a component zoo. The intake process, the moratorium on custom components, and the ownership model are not bureaucratic overhead. They are what makes a system durable.

Adoption is earned.

Mandates don't drive adoption. Quality does. Documentation does. Training does. The system reached 94% adoption because it was genuinely better than the alternative, not because anyone was forced to use it.

The meta-point

A design system isn't a component library.
It's an operating contract between design and engineering.

The components are the visible artifact. The real product is the relationship: shared decision rights, agreed governance, a public source of truth, and a commitment from both functions to maintain it. The system shipped 94% adoption, 2× pod velocity, and zero custom components since governance went live. That's what an operating contract looks like when it works.