Defining Layers in the Design System

This aims to protect quality in critical components while making it easier for teams to contribute and share reusable elements.

We’re proposing layers within the design system to better communicate maturity, ownership, and support levels:

• The Core layer: that contains high-quality, broadly relevant components owned directly by the groupdesign system
• An Extended layer: reusable assets with a lower barrier to entry, maintained in partnership with contributing teams.

This is a significant change to how the design system is organized and how teams will contribute to it. The layering approach keeps everything part of the design system, while making clearer distinctions about expectations, ownership, and maturity. It directly responds to feedback that our current contribution process feels both too rigid and too ambiguous.

Purpose of this discussion

This issue is intended as a starting point for discussion around:

• Working definitions of the “core” and “extended” leers so that everyone has something to react to, refine, or challenge.
• The implications of these layers (and definitions) for our contribution processes and role of groupdesign system.

Why now?

We’ve been getting consistent signals that change is needed

• Recent sentiment research: Highlights a growing friction in contribution and collaboration.
• Internal workshop input: Highlighted uncertainty within our own team about prioritization, scope, and the boundaries of the design system.
• Upcoming quarterly UX memo: We have an opportunity to share with the wider org how groupdesign system is evolving to address these gaps.

Alignment workshop notes

We recently held an internal alignment workshop that provided input on both the experience teams should have when working with us and the gaps we need to address.

What we want teams to experience:

• Feeling supported and unblocked quickly, like a good customer support interaction.
• Feedback that feels constructive and educational, building appreciation for systems work.
• A healthy friction that challenges ideas without discouraging contributions.

Improvement areas:

• Contribution is both too rigid and too ambiguous. We need structure and a lower barrier to entry.
• No consistent, repeatable process for making changes.
• Contributors don’t know how to engage before something is finalized.
• Intake, triage, and support models are inconsistent, with little insight into what’s being worked on.

---

Proposed Criteria and Governance

Core layer	Extended layer
The core layer is a collection of high-quality, broadly relevant elements maintained directly by groupdesign system and reviewed for use by all design system consumers. This includes foundational assets like tokens and typography, plus components, patterns, and guidelines with system-wide relevance.	The extended layer is a lower-barrier space for reusable assets that benefit from having design, code, and documentation in one place, but don't require a commitment from groupdesign system. Primarily components, patterns, and guidelines, though other assets may fit if they don’t meet Core criteria.
Criteria (should meet most/all): Broad usage across multiple domains and Design System consumers. Not clearly owned by a single domain team Sets the system-wide standard for consistent use across domains. Mature and stable design and implementation. High risk if implemented inconsistently.	Criteria (meets one or more): Reusable in more than one place, but not necessarily across multiple domains. May be primarily domain-owned, but valuable to share across teams. An early-stage or evolving component or pattern.
Requirements: Fully conforms to accessibility requirements. Supports current and future requirements of teams. Includes design specs, Figma assets, code assets, and documentation. groupdesign system has capacity and capability for ongoing maintenance and long-term improvement.	Requirements: Solves current needs, but not expects to scale across all product teams. Includes documentation and code (Figma assets and design specs optional) No groupdesign system capacity for full support, but still has value in reuse. Excludes: Code-only assets without documentation.
Governance: Anyone can contribute, but groupdesign system team reviews, approves, and maintains all contributions. Core elements are kept extensible so valid new use cases can be supported without breaking stability. If a valid use case cannot be supported, groupdesign system collaborates with contributors to evolve the element in a reusable way. groupdesign system commits to proactive improvements, accessibility, documentation, and long-term stability.	Governance Default to “yes” for new entries that meet the criteria. Maintained primarily by contributors, with groupdesign system offering guidance or selective contributions. Default position for any new contributions. Extended assets may wrap or extend Core elements. Extended assets may graduate to Core if adoption grows and maturity increases.

Process impact

When a change is proposed:

1. Classify the proposal (automatically if possible)
   • Core, Extended, or reject it for inclusion in the design system.
   • For minor updates, this will often confirm an existing classification, but the step is still required because it sets up our level of support and next steps.
2. Define level of support
   • End-to-end: groupdesign system leads through completion
   • Task-specifc: groupdesign system leads a specific part of the process. For example, producing a design for the UI kit or conducting an accessibility review.
   • Consult/review only: groupdesign system team advises and reviews; contributor leads execution
   • No support: the contributor owns fully.
   • Note: Support levels may change as the work progresses, but they are still defined up front.
   • Supporting contributions to the core layer
     • A point of contact from groupdesign system will be assigned to work with the contributor to help guide them through the process, expectations, and requirements.
   • Supporting contributions to the extended layer
     • When a contribution is classified as extended, the Design System team will check in to understand what support, if any, is needed.
3. Align on delivery timelines and checkpoints with contributors.
   • Confirms our role and sets exceptions with contributors

Minor updates

Most changes to the design system are incremental improvements rather than brand-new proposals. For these smaller updates we still need to confirm the core vs. extended classification because that determines if a change must be reviewed/approved by groupdesign system.

Questions for Discussion

• Are the proposed criteria for Core and Extended clear enough to guide classification? How would you refine them?
• Is a design asset a requirement for inclusion in the extended layer? Or is code and documentation enough?
  • Answered. No, design assets are not required for the extended layer.
• Do we need to define a clearer threshold for “reuse” in Core vs. Extended?
  • Answered. Reuse is an indicator, not a hard requirement. Something can be heavily reused but still domain-specific (Extended), and conversely something foundational with little reuse might still belong in Core. Evaluate against the criteria as a whole.
• What if another team needs an extension to the core layer their unique use case? How should they proceed if a proposed update to an existing element is rejected?
• Are the proposed support levels (end-to-end, task-specific, consult/review) sufficient? How would you refine them?