Who owns the work that sits between a component and the product?
Senior Design Program Manager | Cross-domain pattern governance
THE PROBLEM
As multiple product domains adopted the design system, the same question kept surfacing in different disguises: who owns reusable patterns that sit above a component but below a full product experience?
The system had clear rules for atomic components and none for that in-between layer. One cross-domain pattern exposed the gap: the shipped version was incomplete, the next version lived only in design with no code, and engineering had already built its own before a system-owned version existed. Four domains were each solving the same problem independently. The issue wasn’t the pattern itself. The same ownership questions kept producing fragmented solutions.
THE APPROACH
As I looked across the escalations, it became clear they weren’t separate pattern requests. They all pointed to the same missing capability: the organization had defined component governance, but never defined pattern governance.
That missing layer was an operating-model gap, not a design one. Without a shared way to decide ownership, every cross-domain pattern became a new negotiation.
THE FRAMEWORK
Four governance principles
I looked at where the earlier escalations had actually broken down, and the same questions came up every time: who owns the decision, when should a domain involve the design system, and what makes something reusable versus product-specific. Those recurring questions became the four principles. They reflected where the process kept breaking down, not an idealized governance model.
I kept it to four rather than a long procedural list, because a framework people can actually recall is more durable than one that's complete but forgettable.
01 Define ownership
Every reusable artifact has a named owner, not an assumed one.
02 Align before building
Agree on ownership and reuse before implementation, not after teams have already diverged.
03 Document shared decisions
Capture reusable design and engineering decisions once so teams build from shared guidance instead of recreating them.
04 Maintain shared patterns
Treat shared patterns as products with ongoing ownership, not one-time deliverables.
Naming the missing ownership layer was only the beginning. I authored an ownership model and the governance rationale behind it, then worked through it with Design, Product, and Engineering one domain at a time rather than trying to roll it out as a mandate. Because the framework wasn’t binding, its credibility depended on whether teams found it useful enough to apply. The goal wasn’t agreement for a single pattern. It was giving teams a shared way to make ownership decisions before work diverged.
THE KEY DECISION
Once the ownership gap was clear, fixing a single pattern no longer addressed the real problem. I also wasn’t trying to design a comprehensive governance program that would take months to define and socialize. Instead, I recommended a lightweight framework that teams could start applying immediately. Because it wasn’t mandated, its value depended on whether people found it useful enough to use. That felt like a more practical way to test the model than trying to define every possible scenario up front.
WHAT CHANGED
The governance model shifted the conversation from individual pattern requests to ownership and decision-making. Rather than debating each pattern independently, teams had a shared framework for evaluating reusable work before implementation. The result was more consistent ownership decisions, clearer boundaries between Design Systems and product teams, and fewer ad hoc governance conversations.
Anonymized from a large fintech design system. Specific domains and patterns are generalized; the framework and the ownership model are the point.