Case study · Design System · Keela, then Aplos · 2 min read

Orchid: A Design System Born From a Merger

Three products, 340+ components, and three teams who didn't choose each other. One shared system.

Role: Lead, then Senior Product Designer
Company: Keela, then Aplos2024 to 2026
Team: 3 designers, 2 front-end engineers
Tools: Figma, Storybook, GitHub, Chromatic

340+components brought into one shared library

2dedicated front-end engineers earned with the pitch, a first for a design system there

48 hoursfor a contribution review, down from days

Problem: Three merged products, 340+ scattered components, and three teams who did not choose to work together.
Decision: I treated it as an adoption problem: earned dedicated engineering time with cross-department survey data, then replaced heavy governance with 48-hour async reviews.
Outcome: One shared library, adopted across all three products.
Principle: Governance should reduce friction, not create it.

Stakes

The Situation

After the acquisition in 2025, three products with three visual languages had to become one. I saw early that this wasn't a design system problem. It was a culture problem: three teams with different histories had to choose to build on shared foundations.

The pitch

Making the Case

Orchid started at Keela in 2024. Earlier design system efforts had died without engineering time, so before pitching, I surveyed five departments, letting leadership see the problem in their own teams' words.

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

Marketing survey answers: how well the product fits its audience, its strengths and gaps against competitors, and the customer requests behind them — Marketing: where the product fit its audience, where competitors were ahead, and the customer requests behind it

Product survey answers across ten questions, from what sets Keela apart to the features customers rarely use — Product: what set Keela apart, what was missing, and which features customers rarely used

It worked: we got two dedicated frontend engineers, the first time a design system had earned that.

Before and after

How We Built It

An inventory found 340+ unique components across the three products. Workshops with each team, not presentations to them, distilled them into a small set of shared primitives built on tokens, with Storybook as the source of truth and Chromatic catching regressions on every pull request.

Before

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

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

After

The Orchid library's page list in Figma: design principles, foundations such as colours, typography and icons, then components from alerts to empty states — How the library is organized: principles first, then foundations, then components, and every component marked built in code or still under construction

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

I first built tight governance, and contribution proposals dropped to near zero. The formality was the problem, so I rebuilt around 48-hour async reviews and light templates. Proposals doubled.

	Before Orchid	With Orchid
1	340+ unique components across three products, each with its own colors, spacing and patterns.	One shared set of primitives, distilled in workshops with each team.
2	Values set by hand, down to decimal measurements that never matched between design and code.	Tokens first. Color, spacing, type, elevation and motion flow from Figma variables to code.
3	Inconsistencies found after release, often by customers.	Caught on every pull request by Chromatic visual regression tests.
4	Formal governance, and contribution proposals that dropped to near zero.	48-hour async reviews with lightweight templates. Proposals doubled.

Adoption

Getting Adoption Without Authority

I had no authority over most of the people who needed Orchid, so adoption had to be earned: weekly office hours, pairing with engineers during migration, a migration guide per codebase, and bi-weekly stakeholder reviews. Teams adopted it because it was faster, not because it was required.

Result

What Happened

Orchid was adopted across all three products and is now the foundation of the unified experience. Along the way it earned two dedicated front-end engineers, and contribution proposals doubled once reviews went async.

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

A design system nobody contributes to is a style guide with extra steps.

Thanks for reading.

Built with

Natalie, Lead PM
Marco, Lead Developer
Keiner, Senior Developer
Badal, Lead QA
Ronnie, QA Engineer
Binay, QA Engineer