What Nobody Tells You About Design Systems After an Acquisition
The technical challenge of merging three component libraries was real. The organizational challenge, getting people who didn't choose to work together to actually build something together, was the actual job.
When Keela was acquired by Aplos, I found myself responsible for unifying three products' worth of design decisions into a single system. The technical scope was significant (340+ components, three color systems, inconsistent spacing) but it turned out to be the easy part.
The Cultural Layer
Design systems are usually discussed as technical artifacts: tokens, components, documentation. After an acquisition, a design system becomes a cultural negotiation. Each product team had patterns that reflected their priorities, their users, their constraints. Telling any team their approach was "wrong" would have been both inaccurate and a fast way to lose trust.
The shift happened when I stopped framing Orchid as a replacement and started framing it as an evolution: drawing the strongest patterns from each product and giving every team co-ownership. That changed the conversation from "whose system wins?" to "what's the best pattern, regardless of where it came from?"
Getting People to Adopt Something Nobody Asked For
As a design lead working across three teams, I had no authority over most of the people who needed to use Orchid. This is, I think, the defining challenge of Staff-level design work: your impact is measured by what other people ship, not what you ship yourself.
Here's what actually worked:
Make it easier, not mandatory. The first wave of adoption happened because Orchid components were genuinely faster than the existing alternatives. I invested heavily in developer experience upfront: quality Storybook docs, copy-paste-ready code, migration scripts. Adoption was a side effect of usefulness.
Create visible wins. I found high-visibility features shipping in each product and offered to pair with designers to use Orchid components. When those features shipped faster and looked more polished, word spread on its own. Social proof beats mandates every time.
Office hours over governance. Weekly drop-in sessions where anyone could get migration help or propose new components. These built relationships and gave me real-time signal about adoption friction. The side benefit: I learned what each team actually needed, which shaped how the system evolved.
What I Got Wrong
I underestimated how much documentation matters for the second wave of adopters. Early adopters were comfortable reading code and Figma files. But the people who came next needed written guidance: decision rationale, usage examples, migration recipes. I should have invested in docs from day one, not after the early adopters were onboard.
I also made governance too heavy at first. A formal review process that took days killed contribution momentum. When we simplified to async reviews with 48-hour turnaround, contribution proposals doubled. Governance should reduce friction, not add it.
The Lesson
A design system after an acquisition isn't a technical project with cultural side effects. It's a cultural project that happens to produce technical artifacts.
Lead with empathy, build for adoption, measure whether teams are actually shipping faster. Everything else is a vanity metric.
Next article
Systems Thinking Changed How I Design Products →