Orchid: A Design System Born From a Merger

The Situation

After Keela's acquisition by Aplos, three products needed to become one. Each had its own component libraries, color palettes, spacing scales, and interaction patterns. The inconsistency was visible to users and frustrating for the teams building across products.

But here's what I recognized early: this wasn't a design system problem. It was a culture problem. The real challenge was getting three teams with different histories and priorities to build on shared foundations. You can't mandate that.

Making the Case

Previous design system efforts had died because they couldn't secure dedicated engineering time. I pitched Orchid differently.

Before the pitch, I ran internal surveys across five departments: Engineering, Customer Care, Sales, Marketing, and Product. The goal was to surface recurring problems that leadership could see in their own teams' words, not just hear from design.

Development and Engineering survey results inconsistencies causing rework — Engineering survey: unique variants and missing documentation causing significant rework

Customer Care survey results explaining UI inconsistencies to users daily — Customer Care: explaining visual inconsistencies to users was a weekly burden

Sales survey results upmarket prospects comparing Keela unfavorably to competitors on design quality — Sales: upmarket prospects noticing UI inconsistencies in demos

The survey data let me tie the design system investment to three concrete numbers: faster feature delivery, less QA rework, and a coherent experience that would smooth the product merger. We got two dedicated frontend engineers. First time a design system had earned that at Keela.

How We Built It

The Audit

I ran a full inventory across all three products: 340+ unique components. Through workshops with each team (not presentations to them), we distilled those down to 86 foundational primitives covering 95% of interface needs.

Old Keela designs showing inconsistent components, decimal values, and messy layering — Pre-Orchid: inconsistent components, decimal measurements, non-reusable elements

Tokens First

Orchid is built on a token foundation. Colors, spacing, typography, elevation, and motion are all defined as tokens flowing from Figma variables to code constants. This architecture enables theming, ensures design-dev parity, and provides the backbone for eventual product unification.

Storybook as Source of Truth

We adopted Storybook integrated with Chromatic to give the design team a workflow linked to GitHub. Components live in Storybook as the canonical reference for both design and engineering. Chromatic runs visual regression tests on every PR so inconsistencies surface before release, not after.

Pagination component built with Orchid tokens release ready — Rebuilt pagination clean token-based component ready for release

Chromatic showing release-ready components with visual regression testing — Chromatic visual regression testing integrated with the PR workflow

Storybook component library — Storybook as the shared source of truth for design and engineering

Figma documentation with developer annotations and usage notes — Figma documentation annotated for developers, not just designers

Audit of existing production UI showing inconsistencies — Production audit cataloguing inconsistencies across the live product

A Contribution Model That Actually Works

My first attempt at governance was too formal: proposal templates, committee reviews, multi-day turnarounds. Contribution proposals dropped to near zero. I simplified: async reviews, 48-hour turnaround, lightweight templates. Proposals doubled overnight. Governance should reduce friction, not create it. That was a hard lesson.

Getting Adoption Without Authority

I had no direct authority over most of the people who needed to adopt Orchid. What worked:

Weekly office hours: drop-in sessions where anyone could get help migrating or propose components. These built relationships and gave real-time signal about what was actually hard.
Paired adoption sprints: I sat with engineers during migration, pair-designing and debugging together. Teams adopted because Orchid was genuinely faster, not because it was required.
Migration guides per product: meeting each team where they were, not where I wanted them to be. Each guide looked different because each codebase was different.

What Happened

40% faster component development for new features
Adopted across all three products within 6 months
96% component reuse rate in new feature development
70% reduction in visual inconsistency bugs
12+ designers and engineers contributing monthly
Orchid is now the foundation for the unified product experience

Future vision for Orchid unified product experience across Keela, Raisely, and Aplos — Where Orchid is headed: a unified product experience across all three platforms

Phase 1 release recognition team collaboration across PM, Engineering, and QA — Phase 1 shipped. Lead PM Natalie, Lead Dev Marco, Senior Dev Keiner, Lead QA Badal, QA Engineers Ronnie and Binay

The contribution model is the thing I'm proudest of. A design system nobody contributes to is just a style guide with extra steps.