Episode 063 Raw Data

	A	B	C
1	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 063, deep dive hosted on October 23, 2025 with Ben Callahan and Erin Potter. There are 52 answers. The question this week was: ----- Last week, Erin and I were discussing the trend toward smaller, more focused core design systems. To make this work, it often requires freedom for consuming teams to build upon that core system to create their own collection of components, patterns, or recipes. The trend toward smaller systems often, eventually results in a system of systems architecture. Back in January, Jennie joined me to co-host an episode on this very idea (system of systems) and we learned that about half of the respondents at that time had seriously considered a multi-system architecture. This approach raises a question: what do you call these extension systems? Are they like a franchise—carrying your core system’s brand and name? If so, is there some kind of tax back to the core system? Do they receive the same kind of support that the core system does? And then, of course, who provides that support? For a system of systems to work, you need to define the agreements—the contract—between the core design system and these extension systems. This week, Erin and I want to explore this idea with you. What should be included in that contract between the core system and systems meant to serve a specific product domain? Welcome to Episode 063 of The Question: Contracts Between Design Systems. Does your design system architecture allow for extension systems? If yes, do you have a defined contract between your core system and the extension systems? What should be included in a contract between a core and an extension system?
2	Question 1: Does your design system architecture allow for extension systems?	Question 2: If yes, do you have a defined contract between your core system and the extension systems?	Question 3: What should be included in a contract between a core and an extension system?
3	Yes	No	- Quality gates / DOD (they might differ between core and the rest) - Who owns what + what can only be owned by core or extension - How/where to publish code, assets, documentation - Versioning practices - Workflows and protocols for moving stuff from one system to another - Conflict resolution protocol (who has the last say when teams want to do in different directions?)
4	No		what data is shared and who owns it
5	Yes	Yes	Clear definition of boundaries between systems, who is responsible for what? A clear agreement that the purpose of the local system's role is not to replace or replicate what the core system does, but to expand upon it for their given context and contribute back where it makes sense. It's also important to outline the expectations there are for local system teams, e.g., always upgrading to the latest version of the DS, documenting fully, if using the core DS brand, what the expectations are there.
6	No		Ownership, clarity about decision-making, equality between all extension systems (neutrality).
7	Yes, in theory, but in practice it's been challenging.	We have ways of working/extending our system, but have not defined them as clearly as needed. Have created some contracts around usage when it comes to development, but are still looking	- Explanation of what it means to "extend" — using existing components, using tokens, when to request to features to existing components or new tokens vs. creating new UI elements - When it's acceptable to detach instances - How to document new UI elements that don't exist in the code
8	Yes	Our products all start with our Core Component library, which houses the majority of our components and all of our global system tokens. So far, there are two additional supplemental libraries that are for components and styles that are ONLY approved for use in a given sub-product.	Clear guidelines on when to use central assets vs. supplemental ones, approval process for spinning off new versions of things, general oversight and governance structures.
9	Yes	No	Agreements regarding: design language, accessibility conformance, UX behaviors, versioning, and breaking changes.
10	I don't know	I don't know	I don't know
11	Yes	Yes	Our contract is a process expectations for teams. We expect everyone to start with the Core system and use it as far as it will take them. When they run into limitations, that is expected and by design (the design system will never be everything). When you do, reach out and we will help you, either showing you how to make better use of the Core system, how to customize/override a Core component or how to create a new component in our extension system, Sandbox. Sandbox is our community library where things are less stable/organized and more divergent/emergent. Here we still encourage you to use Core elements as much as possible. Sandbox is a place where you can see what everyone is working on and potentially borrow from it, reuse it, or we may graduate it to Core when we see a strong desire for that component across the organization. The design system team is also less responsible for Sandbox. We create the structure/environment, and we have visibility into it, and maybe some guidance on best ways to contribute to it. However ultimately, it is a collective space co-owned by everyone. We are all responsible for keeping it tidy, while acknowledging it will always be a bit of a mess.
12	It does allow for extension, as in, it is possible because the original system is scalable enough. But it is not an idea that has been explored because of lack of time and changes in priorities.		- Clear communication around breaking changes - Validation of use cases to avoid redundancy - Protocols for contribution and experimentation: Including documentation and testing.
13	Yes	No	Core design tokens will not be replaced.
14	Yes	No	What should always be leveraged from the core / Where it's ok to deviate and create extension-specific components or tokens / When new tokens or components devised in extension systems should actually live in the core
15	Yes	Sort of. There's the opportunity to contribute back to the core design system, and to take a more influential role in the core system's evolution.	A contribution model, definitions of what is/ is not a part of the actual extension system.
16	yes we allow extension components, but that is also maintained by the core team	Yes	documented agreement outlining requirements: what's required for documentation, token usage and set methodology for QA
17	Unsure; as of right now our design system does not have the concept of a "global" (core) design system or a "local" (product domain level) design system.	No	I recently started using the DS at the company (I also recently joined the company) and haven't figured out what that working model/contract is between the DS and consuming product. But from what I can tell, there is not 'local DS model".
18	Yes	No	Agreement on token usage, Figma styles and atomic components. Also, it would make sense to create clear contribution pathways, and regular updates to extension systems for brand refreshes or major refactors.
19	about to explore this path for federated product specific systems	No	RACI for main system and extended system that documents the what & who across all functions. Should be clear when subsystems can move independently vs needing alignment with overall system. Agreement on how knowledge sharing and support will occur. Best practices for building new components and extending others into subsystems. Best practices for tooling to make sure they all work in concert. Contribution models to elevate subsystem elements in a global model Shared decision making frameworks, if possible. Clear escalation paths based on RACI.
20	Not yet, because we're pre-launch, but will need to reconcile with at least 2 floating "systems" around the org. One will likely deprecate (hopefully two!) and a third we'll need to create connective tissue with.	No	A pretty standard RACI and some kind of SLA on timing/who-does-what
21	Yes	Yes,Contribution Rituals & Design Reviews	You'll only create new component if : - You are creating a new feature or new screen - Any of the existing component does fit (and you proved it) - You arrive with a need/context and a proposition
22	Yes	Currently WIP — in contract negotiations!	Ecosystem architecture alignment, shared language, defined roles and responsibilities. I think the baseline for a contract would be to technically connect the pieces that make sense for your needs now (planning for later), create a shared design language and consistent system behavior across systems — not to force identical code where it doesn’t fit (we are specifically targeting ecommerce web and mobile platforms — some things shared, some similar but diff, some totally diff or not equivalent). So some things may be technically shared, while others are conceptually aligned. From a core perspective that shared contract looks like ingredient level components (buttons, links, inputs, etc.) and token systems. Token contract / ownership & management negotiations will be interesting. I have a feeling teams will want to own but may not be equipped to actually manage it. And if they don't, and the Core team manages it, then it becomes a capacity mapping exercise. Excited to learn from this convo!
23	I actually don't know yet - I recently joined a new company and am just starting to learn about their DS		Property consistency. Explicit documentation on where the systems potentially differ in implementation. Clear expectations on the extension system to how quickly they are responsible for updating to support any breaking changes from the core system.
24	Yes	Yes	A downstream copying function to create the extension systems. Similar to the component variant functionality in Figma (there's a parent/main component then instances of that). This way upstream updates replicate down to the extension systems.
25	No	No	I think the most important thing is an explicit agreement about how breaking changes are handled, i.e. the core system won't deprecate anything without two releases for downstream systems to adopt the latest updates.
26	No		A strategic plan for a baseline of building components. At least one dedicated DS designer assigned for review and feedback. Net new components and not already built.
27	Yes. That's the main goal	That's our plan.	To connect all dots . between many stakeholders.
28	No		we don't have systems of systems in the sense that you have a sub system for eg web. But we have what we call slices: web, mobile and appliance. These slices are distinct teams in different departments. The only thing holding them together are design tokens, that's the contract. And it's not enough, the slices diverge already. We need to do something.
29	Yes	No	There should be clearly defined guidelines on when deviating from the core system should be allowed and when not. I do like the Hub & Spoke model from IBM Carbon on how they defined rules on when deviation and extensions are ok or not. I would also add that the semantic design tokens should be used when creating specific components.
30	Yes	Yes	We see our design system as a composable design system rather than a system of systems. For us, the contract includes the following topics: * what is rigid in our core * how pieces can be combined or extended * what the teams can extend * how improvements can flow back to core * how to keep compositions still compatible (versioning & sync) * what are the quality/accessibility standards to adhere * how to ensure transparency in composition (documentation/tracebility) * who decides what (governance)
31	Yes	No	I think the main thing for the contract between core and extension needs to be a core-first approach. I mean, those who are building things in an extension should be using the core as a start when composing new components, patterns, etc. They should follow the core design and accessibility guidelines. I'd love to be able to have some sort of approval of the core system for extensions to ensure the same standards as the core but with my team, we don't have the bandwidth for that at this time. Similar to a code PR review process, it would be nice to have a checklist to ensure consistency in line with the core system.
32	Yes	No	There should be general guidance on what is defined as core systems vs. extension systems. This includes having clear guidelines on components, principles, ownership, and community.
33	Not at the moment but that’s the plan!	No	Clarity on where you converge and diverge from the system and SLAs of how we work together and how we discuss larger systems evolution
34	Yes.. ish. Others use our system as a base to create their own innovation, but rarely (at this point) are their components returned / added to the system as a whole.	Yes.. ish. For those that use our system as a foundation we have a clear understanding of what needs to stay (colors, fonts, some design rules) and what has flexibility.	Understanding of the foundational elements which MUST remain the same (colors, fonts, certain design rules) and what is flexible and open to be innovated on. It was stated by one of our consumers once that w. the DS we want them "to create something in the same family, but not necessarily an identical sibling to an existing product". We don't want to hinder their ideas, but like a loving parent, we do want to keep our hand on the steering wheel while they innovate so they learn best practices along the way.
35	In discussions		Keeping core tokens intact, following guidelines for adding new tokens, components, patterns. Some kind of guard rails for deviation. Prevent duplication of components or patterns. Following naming conventions.
36	Not yet, but hope to in the future	No	Commitment to using the core system tokens and elements, keeping up to date with new versions, some level of documentation
37	Yes	No	A maintenance or check-in schedule on a calendar cycle is my first thought. Some kind of policy that defines what is rigid and what is flexible would also be helpful to evaluate growth or extensions.
38	Yes	Yes	Im currently on an extension DS team, while my previous roles were on the core DS team. - Regular meetings to share both ways. - Process to contribute back to the core. - specific resource allotment, like stories per sprint - Early access to beta components in core - Influence on core roadmap - overlapping communications so audience can learn about both systems - combined docs
39	Yes	We're still sorting out our recipe layer. Folks got a bit overexcited when we first launched it, and it very quickly became unwieldy. I think we'd be better off deleting it and starting over :melting-face:	I think systems of systems needs to share the same foundational architecture (naming conventions for props, etc.) so each system feels like a part of a whole. We've been struggling with community ownership, quality, and maintenance at our recipe layer.
40	Yes: I have set up multi-brand systems in the past No: I'm not currently working with a design system :(	No	Contribution determined by Core team only Alignment on conventions (variables architecture/naming/component craft)
41	No		Core and extension systems must have a clear purpose. Define who governs the system, workflows, rules of engagement. Define where specific capabilities in common across experiences intersect to help set standards. How to turn deviations into contributions
42	No		I think the contract would be dependent on the org and the consumer teams but some things that come to mind are - - Primitive or structural components - Tokens - Accessibility - Governance
43	TBD, we are currently working on a system for a product within a product suite and collaborating with other leads to figure out what makes sense. Since it’s early and we don’t have the needed trust and understanding of needs, we’re aiming for a minimal core system to be shared.	We’re working on something through auditing each product and doing some workshops to get alignment on what sustainable and reasonable “commitment” looks like	What we are aiming for is design principles and tokens as the foundations of the core system. Our UI metaphor, semantic naming, accessibility and token architecture all seem like essential common language elements. After that we are working on a set of basic component building blocks that are very atomic and abstract enough to be used by everyone. After that we feel each product for now can develop its own patterns and templates. Over time we hope to learn more about the dominate and most useful patterns that are shared across products and add those to a layer of the system as well that might orbit the core library.
44	It's complicated. I think the answer is no and that the intention is that teams pick up what the system provides, but the system is not well enough documented for teams to be able to know.	No	- Agreement to use things off the shelf if they can fit your use case. - If you create something above and beyond what the system provides, you're responsible for its maintenance until it's off your plate because it's something used by "enough other teams" to define it as "enterprise". (probably more from there, but that's what I can muster off the top of my head at this point this morning. Need more coffee...)
45	Yes	No	A system of systems should principally align to delivering a great customer (designer/engineer/pm) experience. The contract should consider: * Constraints - e.g. What the core system is expected to provide and how the local systems are expected to extend that, what can/cannot be customized, etc. * Dependencies - e.g. Setting expectations around managing dependencies between the systems, how to handle breaking changes, etc. * Standards - e.g. codified build standards, architectural standards, design standards, test standards, etc. * Support - e.g. How support will be handled for the parts of the core system vs. extension systems I think that a truly successful and rigorous system of systems would abstract away the complexity of the underlying system structure, and give users a simple interface to engage with the various parts of the system. AI could likely enable this either now, or in the near future, but would require strict standardization in order to produce consistent output.
46	Yes	we're working on it now	- obligation of extended systems to leverage/inherit from core system - bring system resources into shared spaces (where possible for ease of finding for users) - definition of maintainers/owners (raci of sorts) - quality requirements - standards, principles, and accessibility - cadence of coming together - discuss planning, prioritization, contribution/elevation, etc
47	Technically yes in the sense that Figma isn't going to stop you, but "allow for" is pretty broad, haha	No	Primarily, specific details about what is automated / tooled vs. guidance, i.e. what is kept aligned via Figma & code interdependencies vs. what is kept aligned via team & individuals communicating & adhering to guidelines.
48	No		Is it naïve to think that if your core is built correctly you shouldn't need a contract?
49	Yes	No	Thoughtful guidance laying out the goals, purpose, and ownership models for each. It’s also crucial that it’s made clear what contribution looks like at each layer and what the process is for moving a component/pattern from extension to core.
50	Yes	No	Not sure as we didn’t have that defined
51	Yes	Yes	A clear description of the new or extended terms, of course edited or anything money related, how are both parties supported, and important dates (e.g. due dates or blockers).
52	Yes	Technically the structure does allow for the system of systems. But we are redefining the structure a bit at this point in time to solve for the tech dependencies.	A contract between a core and an extension design system defines how the two layers interact, ensuring stability and consistency. It should outline what each system owns, what can be overridden, how updates propagate, and the rules for tokens, components, and governance. Essentially, it sets the boundaries, dependencies, and quality standards that keep extensions flexible yet aligned with the core.
53	No	No	Statics and relative atoms?
54	Yes	No,We are about to do something similar at McDonalds for our app and kiosk design systems	I would imagine it to be very clear in the contract what is automated/tooling vs. what is communication or written aggreement based. I'm looking forward to learning more about this, as I have not had as much experience with extension systems.
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100