Design System Problems

Hub and Spoke Model

January 15, 2026 • 5 min read

Hub and Spoke Model

The hub and spoke model structures design system teams with a central hub providing coordination and foundations while embedded specialists within product teams serve as spokes connecting products to the central system. This hub and spoke model enables both consistency and responsiveness across large organizations.

What Is the Hub and Spoke Model

The hub and spoke model organizes design system work through two interconnected structures. The hub consists of a central design system team responsible for foundations, standards, and coordination. The spokes are specialists embedded within product teams who implement the design system locally while maintaining connection to the central hub.

This model addresses the challenge of maintaining central coherence while providing product teams with dedicated design system expertise. Rather than choosing between centralized ownership and pure distribution, the hub and spoke model creates ongoing connections that enable both.

How the Hub and Spoke Model Works

The central hub maintains design tokens, core components, documentation, and shared infrastructure. Hub team members focus on system-wide concerns, cross-cutting improvements, and support for spoke specialists. The hub establishes standards and provides resources that spokes implement locally.

Spoke specialists work within product teams, often as embedded engineers or designers with design system expertise. They implement the design system within their products, create product-specific extensions when needed, and serve as the primary design system contact for their teams. Spokes bridge product needs and system capabilities.

Communication flows bidirectionally between hub and spokes. The hub disseminates updates, guidance, and new capabilities to spokes. Spokes relay product feedback, identify gaps, and surface patterns that might benefit from system-wide solutions. Regular synchronization keeps these flows active.

Spokes may contribute improvements back to the hub. Patterns that prove valuable across multiple spokes can graduate to hub ownership. This contribution path prevents duplication and enriches the central system with real-world insights.

Key Considerations

Common Questions

How are spoke specialists organized?

Spoke specialists typically report to their product teams while maintaining dotted-line relationships to the hub. This structure keeps them accountable to product goals while connecting them to the design system community. Some organizations use guild or community structures to formalize spoke connections without changing reporting lines. The specific arrangement depends on organizational culture and existing structures.

What skills do spoke specialists need?

Effective spokes need strong technical foundations in design system implementation. Beyond technical skills, they need communication abilities to translate between product and system contexts. Influence skills help them advocate for design system usage within teams that may resist. Understanding of the broader system enables them to identify opportunities for contribution and recognize when product needs might benefit other teams.

How many spokes does a hub need?

Spoke count depends on organization size, product count, and desired coverage level. Some organizations embed spokes in every product team. Others concentrate spokes in high-priority products or use rotating assignments. The hub-to-spoke ratio must ensure the hub can effectively coordinate with all spokes. Very high spoke counts may require intermediate coordination layers.

Summary

The hub and spoke model enables design system scale through central coordination with distributed implementation expertise. Success requires clear roles, strong bidirectional communication, and attention to spoke specialist development and support. Organizations should consider this model when product teams need dedicated design system expertise while central coherence remains important.

Buoy scans your codebase for design system inconsistencies before they ship

Detect Design Drift Free
← Back to Scaling Governance