Scaling products through design system advocacy, architecture, and community
Even the strongest design systems eventually hit a breaking point. Documentation and training stop being enough. Components get forked. Patterns drift. Product quality suffers. There might be speed, but there isn’t velocity — everyone is barreling off in different directions.
This results in centralized systems running alongside a decentralized reality, where:
The core design system team can’t possibly support every product at depth.
Product designers are under pressure to ship fast and make exceptions, compounding inconsistency.
System updates lag behind product needs.
Without active cross-pollination, the design system becomes both too rigid and too distant, a library instead of a living ecosystem, and the core design system team becomes siloed and overwhelmed. At that point, the question isn’t how do we enforce governance, and instead shifts to how do we scale this through processes that empower people?
The three pillars: advocacy, architecture, and community
A sustainable design system isn’t just documentation and governance. As it matures, it needs to become an ecosystem made up of three reinforcing structures based on collaboration:
Ambassador programs: distributed advocacy through through design system experts embedded in product areas.
Design architecture forums: structured collaboration across design system ambassadors and senior product ICs to align on system evolution and cross-product patterns.
Contribution model + community space: a defined framework and platform for designers to contribute patterns, components, and learnings safely and sustainably.
Together, these create an ecosystem with built-in guardrails where alignment happens organically, not bureaucratically.
Ambassadors: distributed system stewardship
The Ambassador model works by embedding design system advocates into each product team. Ideally, these are senior-level designers fluent in the design system and empathetic to product realities. It’s also helpful for them to have broader platform ecosystem knowledge, even if they aren’t specifically platform designers .
Additionally, in each product team, there should be a designated senior level design lead to pair closely with the design system ambassador. This is someone with deep product knowledge and context. Together, they work with the team to translate design system principles into applied product solutions and feed product learnings back into the core design system team.
Their role isn’t to police design decisions. Instead, it’s to:
Bring system thinking into local product work and day-to-day design
Advocate for adoption, consistency, and contribution
Provide ongoing review, collaboration, and feedback
Capture product-specific edge cases to inform future design system team
When done right, this pairing creates bi-directional advocacy — one grounded in architecture, the other in application.
The result: faster adoption, higher quality contributions, and shared ownership of the system as a product, not a policing function.
And critically, this model improves the product itself. When patterns, tokens, and interaction models are shared and maintained through clear advocacy and architectural alignment, engineering velocity increases. Teams spend less time rebuilding components, QA cycles shorten, and accessibility issues decline.
More importantly, product experiences start to feel cohesive across modules and workflows where users can move through complex environments with less friction and confusion. The outcome isn’t just design harmony; it’s measurable product efficiency, usability, and trust.
Design architecture forums: cohesion through collaboration
Ambassadors thrive when there’s a structured place to bring what they learn, and that’s where a Design Architecture Forum comes in.
This forum brings together product–system pairings to look at design problems that cut across multiple teams, products, or domains.
Typical topics might include:
Shared workflows and interaction patterns
Foundational decisions like tokens and visual language
Migration plans for legacy components
Architectural alignment for new initiatives
Catching issues early that may otherwise go unnoticed
Managing design debt across the ecosystem
Unlike a guild, this isn’t about general practice growth, craft, or process. This about empowering product coherence at scale, ensuring similar user problems lead to similar design solutions, without stifling flexibility or slowing velocity.
Contribution model and community space: from adoption to participation
Design systems don’t just need consumers and a core team; they need contributors. A defined contribution model and active community space make that possible.
The contribution model provides guardrails such as:
Standards and guidance for contributions for different UX disciplines
How to propose new components or patterns
How contributions are reviewed, approved, and integrated
How credit and visibility are shared
The community space provides the energy in the form of:
Async channels for discussion and peer review
Live sessions for demos and learning
Opportunities to showcase design evolution across teams
This turns passive users into active participants, helps keep work unblocked, and ensures the system reflects the diversity of real product work happening across the org.
This is not a side gig
Here’s the part that can’t be overstated: this model only works with organizational support. Ambassadorship, architecture forums, and contribution programs are not volunteer work. They are core to how a design organization scales, and in turn how the product scales through design, and must be recognized, staffed, and incentivized accordingly.
When leadership treats this as extracurricular, it fails. When it’s embedded into job expectations and supported by time, visibility, and recognition, it becomes the infrastructure that keeps the design ecosystem coherent. If you want unified product experience and design cohesion, you have to resource it like it matters.
The cultural shift
Both the model and the mindset matter. In this model:
Ambassadors give the design system a human face.
Architecture forums give product teams a voice.
Contribution spaces give everyone a hand in the work.
These three things together scale and support the core design system team to focus on the work that they do best in ongoing support of the system, while at the same time maintaining clear communication and visibility in both directions from product teams to design system.
And this is where design maturity shows. Not in the number of Figma components you maintain, but in how effectively you align people around a shared experience standard. And this relies on one thing: a culture that recognizes it has scaled past central control and governance, and values shared stewardship to take a design system to the next phase.
Why this matters
At a certain point, consistency can’t be run by brut force alone. it has to be cultivated and tended with collaborative efforts.
Design systems are social systems. They scale through networks of trust and communication.
Architecture isn’t a meeting or one person’s job in large design orgs. It’s a mindset. The forum model works when participation is recognized as real design work, not extracurricular effort.
You get what you incentivize. When advocacy is treated as leadership, consistency follows naturally.
If your design system feels like it’s plateauing, and product design teams are feeling frustrations with a lack of voice or missing components, you might not need more documentation or governance. You might just need more advocates and spaces where they can shape the system together.
Product quality, velocity, and design at scale are never just about building systems. They’re about empowering the people within the system who care enough to keep it alive and the organizations wise enough to support them.
Interested in additional thoughts on design systems or product quality? Here are a few posts:
