| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 070, deep dive hosted on March 12, 2026 with Ben Callahan and Hannah Clarke. 👏 Thank you to Mintlify—the intelligent knowledge platform—for sponsoring this episode of The Question. Get 50% off the Pro plan for six months using the code MINT-THEQ. 👏 There are 45 answers. The question this week was: ----- Hello, System Thinkers! I’m excited to welcome Hannah Clarke as my co-host this week. She and I sat down to talk about her background, what got her into design systems, her current role, and what she was curious about. Let me just say, she’s curious about everything! This week we’re shifting our focus to the engineering side of design system work. There’s a big gap between drawing architecture diagrams and actually getting those drawings to work in real life. Hannah finds herself responsible for making those diagrams happen by owning how coded component packages are deployed to her engineering teams. This is part of the work that’s often overlooked, yet it has such an impact on the longevity of your system. This week, we want to understand how you’re building lasting design system infrastructure. Welcome to Episode 070 of The Question! Which of these statements best describes your company? • Led by Engineering • Led by Product • Led by Design • Led by a balance of Engineering, Product, and Design • Other On your design system team, which roles have at least one dedicated person: • Dev Ops • Design Ops • UI Design • Frontend Developer • N/A Who has responsibility over the delivery of your coded components? What do you believe are the most important actions a design system team can take to create a system that lasts? | |||||||||||||||||||||||||
2 | Question 1: Which of these statements best describes your company? Note: not your team, the company as a whole! | Question 2: On your design system team, which roles have at least one dedicated person: | Question 3: Who has responsibility over the delivery infrastructure of your coded components? | Question 4: What do you believe are the most important actions a design system team can take to create a system that lasts? | ||||||||||||||||||||||
3 | Led by a balance of Engineering, Product, and Design | Design Ops,Dev Ops,Frontend Developer,Product Owner,UI Design | Our software engineers and UX engineers. | Implementation agnostic foundations that precede a specific front end framework. | ||||||||||||||||||||||
4 | Led by a balance of Engineering, Product, and Design | Frontend Developer,Product Owner,UI Design | Essentially the product teams | Learning how to collaborate and have decision making across disciplines | ||||||||||||||||||||||
5 | Let by Design | Design Ops,UI Design | On loan frontend engineers | Inspect the architecture to make sure it not only delivers on users' needs but also scales in alignment with company goals. | ||||||||||||||||||||||
6 | It’s led by “me”, but I’m leading it coordinating the base needs of all those perspectives. Their not in opposition to each other; just tensions in scope need to be understood. | Solo effort, and I’m doing most of them with AI | My AI agent Lina (who manages my component infrastructure) along with my other AI agents Ada (token infra) and Thurgood (testing, governance, and spec development). | — Engaging with people to understand their problems and solve their needs. These systems don’t work if people don’t buy in, and people don’t buy any if they don’t see solutions to their problems. — Create and maintain machine-readable documentation — Accept that people don’t have to use what you prescribe or provide, and approach problems to develop solutions that inspire them to want to use what you built. Carrots and sticks. Sticks are easy, but don’t motivate half as well as carrots. | ||||||||||||||||||||||
7 | n/a | ,Frontend Developer,UI Design | n/a | n/a | ||||||||||||||||||||||
8 | Let by Product | We do not have a dedicated design system team. All design system effort is federated/contribution-based. And Design and Engineering do not collaborate on design systems; they maintain their own separate libraries. | Each individual product engineering team is responsible for their own product code work. There is no collective global engineering design system effort despite being part of a very large corporation. | Once a team exists, maintaining buy-in. | ||||||||||||||||||||||
9 | Let by Product | Frontend Developer | Myself as lead front-endndeveloper. While I have my manager, he tends to leave the entirety of our system operations to me, only covering higher level conversations on roadmap ping and goal setting to match the organization. | Collaborate with champions who have a strong desire to do their system work more efficiently. People that want to solve unique problems and not remake the same base month over month are key individuals to tap into. They can be vocal advocates for your work even if leadership is skeptical. | ||||||||||||||||||||||
10 | Let by Design | Dev Ops,Frontend Developer,Product Owner | Engineering | Improve upon Engineering and Design communication and handoff. The final output needs to come from both, not just one or the other. | ||||||||||||||||||||||
11 | Led by Engineering | Not even me as the only designer is fully dedicated to design system work. It's me + architecture lead + one dev. | Me, design engineer. We created skills to scaffold components based on design + engineering needs. | Encode design decisions as guidelines in the executable parts of the system. Built on shared design and engineering requirements. | ||||||||||||||||||||||
12 | Led by Engineering | UI Design | Slowly moving to a balance | Solid foundations, principles and clear workflows | ||||||||||||||||||||||
13 | Government: led by a blend of law, policy, security, and current leadership priorities, often politically driven (and urgent) | Product Owner | Product Owner | Focus on scalability | ||||||||||||||||||||||
14 | Led by a balance of Engineering, Product, and Design | Frontend Developer,UI Design | Our Lead engineer | If we're focusing mainly on the engineering side here... it probably goes without saying (but I'll say it anyway) that the DS code needs to be stable, reliable, and bug-free. It should be LESS work and worry for dev teams to utilize the DS. Maybe more importantly: if consuming dev teams can't predict how updates will arrive, what might break, or how to update safely, etc. they'll just stop updating, or worse, they'll fork. Semantic versioning, documented changelogs, staged rollouts, and clear deprecation procedures are all super important here. | ||||||||||||||||||||||
15 | Led by a balance of Engineering, Product, and Design | Design Ops,Frontend Developer,Product Owner,UI Design | Our Principal Engineer takes the lead on our our infrastructure for code and manages our architecture strategy | In my experience, creating a design system that lasts comes down to striking the right balance between structure and flexibility. A system needs enough rigor to drive consistency and deliver the benefits it promises, but enough flexibility that users and the products they build don’t feel constrained or blocked by it. But that balance isn't easy. It depends on who your users are and what consuming products require. Given that, one of the most important actions a design system team can take is to stay in continuous conversation with the users and products they support. The system should evolve in response to real product needs, not operate independently of them. Equally important is grounding decisions in data. When we choose to be more prescriptive, such as standardizing a side navigation pattern, we need to clearly articulate our reasoning and back it up with evidence. Transparency builds trust, and trust is what ultimately sustains adoption over time. | ||||||||||||||||||||||
16 | Led by a balance of Engineering, Product, and Design | Frontend Developer,Product Owner,UI Design | Engineers | Listen to your users wants and needs. Learn from detachments and custom builds instead of punishing them. | ||||||||||||||||||||||
17 | Let by Product | Frontend Developer | Our Tech Lead, who is the Manager of all developers on the team. | Right now, it feels like preparing for machine readability/AI. Which will inevitably drive automation adoption across the org. | ||||||||||||||||||||||
18 | Let by Product | Frontend Developer | The lead dev on the system. | The entire org, leadership and individuals becoming an integral part of the system. | ||||||||||||||||||||||
19 | Let by Product | We have an unofficial Design System team comprising of a couple of Viz Designer and a couple of FE Devs. We each have our respective team responsibilities but have contributed part-time to initiate the DS work. We are garnering more support as products adopt the DS. | I'm one of the FE Devs. The other is well versed in the DevOps side of engineering and has so owned integrating the Design System into our existing infrastructure. | Communication and collaboration. On everything from approval and governance with leadership all the way down to infrastructure with DevOps, identifying the needs early and getting ahead of the requests will provide the foundation necessary to have a lasting design system practice. | ||||||||||||||||||||||
20 | Let by Product | no dedicated roles. all volunteers 😢 | Most involved is our Innersource/Opensource office. | Community. Connecting people that ask about the system. Tools will keep changing over time but people will keep interest alive. | ||||||||||||||||||||||
21 | Let by Product | Frontend Developer,Product Owner,UI Design | Frontend developers | Communication and coordination with product development teams ensuring that the DS is providing the components and functionality they need to build their products. | ||||||||||||||||||||||
22 | Led by a balance of Engineering, Product, and Design | UI Design | Design Manager and Lead Software Engineer on the DS team. | To create a lasting design system, I think you have to treat it as a product where the developer is your primary customer. Longevity is built on trust, which is earned through a strict 1:1 parity between Figma components and Storybook code. The moment a developer encounters a mismatch or has to hunt down the "real" source of truth, the system becomes a hurdle rather than an accelerant. | ||||||||||||||||||||||
23 | Led by a balance of Engineering, Product, and Design | Design Ops,Dev Ops,UI Design | Engineering Lead / Manager | Understand the products and people the system supports while staying in tune with technology advancements to manage updates and upgrades in a way that is intentional and considerate of the product and people. Updates are great, but you must understand the impact and costs to the business and relationships. | ||||||||||||||||||||||
24 | Let by Product | Frontend Developer,Product Owner | Dev team | proper turnaround time to change requests and a working contribution model. As long as you can stop designers/developers going their own way out of the DS pattern, which can actually happen both if you are too rigid or too flexible. | ||||||||||||||||||||||
25 | I'm not currently employed | In my previous role, I was the only active member of the DS team. I translated the existing Figma library into a Storybook component library, created a zeroheight documentation site, and setup a CI/CD pipeline to deploy CSS/JS artefacts and a published Storybook. | In all the companies where I've been involved in formal (and informal) DS work, I've taken on the responsibility of delivering the DS (sometimes with the help of the devops team if there are specific requirements / implementation details). | ??? | ||||||||||||||||||||||
26 | Led by Engineering | Design Ops,Frontend Developer,Product Owner,UI Design | The design system team | Building trust and responding to customer needs. Being predictable about the changes you make and communicating clearly. | ||||||||||||||||||||||
27 | Led by Engineering | UI focused team separate from DS | steady process and communication | |||||||||||||||||||||||
28 | Led by shared governance. Basically decisions by committee. | Frontend Developer | The developer | Thinking intentionally about what can be platform or application agnostic is high on my list. Second is to have as much accessibility compliance built-in as possible. | ||||||||||||||||||||||
29 | Let by Product | Frontend Developer,UI Design | The UI Engineering team which is a team inside the design system team | Trying to make the design system as framework agnostic as possible so that it can survive changes to frameworks or changes to design or engineering software. | ||||||||||||||||||||||
30 | Let by Product | Frontend Developer,UI Design | My tech lead, frondend developer, and the broader engineering foundations group that our engineers ladder into. | build what's needed informed by the needs that consumer teams have from the system. | ||||||||||||||||||||||
31 | Let by Product | Frontend Developer,UI Design | Frontend Developer | Build trust, clear documentation, a system that has high amount of flexibility and composability | ||||||||||||||||||||||
32 | Engineering led, product second, design third -- but design's energy was concentrated on brand rather than product. The Superhuman rebrand got a lot of attention while product design decisions were largely driven by eng and product." | Design Ops,Frontend Developer,Product Owner,UI Design | At Grubhub, engineers. At Grammarly, a mix of engineers and design technologists. | Treat it like a product, not a library. Stay ahead of the business, embed in new surfaces before patterns solidify, and make contribution easy enough that teams actually use it. People need to feel ownership, not compliance. Establish clear governance so decisions don't get made by default. Balance rigidity and flexibility — opinionated enough to create consistency, open enough that teams aren't working around you. Hold a high craft bar, because the system sets the standard for everything built on top of it. Measure relentlessly -- surveys, validation, business impact -- because evidence is what keeps leadership invested and the system alive. And practice good hygiene: prune what's no longer earning its place. | ||||||||||||||||||||||
33 | Let by Product | My design system team has me as a DesignOps & UI Designer, the rest of the roles are fluid - there are people assigned, but design system isn’t their only responsibility. | Design system owner & Dev Team | Communication would be the key, so aligning on how we understand particular aspects of design systems, so that we speak the same language. When we started introducing atomic design approach, we kicked off with design-dev workshops on how we understand it in the context of components complexity, we aligned on the naming conventions, etc. Understanding the product, its demands and environment limitations is crucial as well, so that the decisions we make are accurate and catering to actual needs. Listening to teams using the design system is sth worth practicing constantly to eliminate pain points and facilitate using the design system as a product. | ||||||||||||||||||||||
34 | Led by Engineering | Frontend Developer,UI Design | Development lead. | Build trust. | ||||||||||||||||||||||
35 | Let by Product | Design Ops,Dev Ops,Frontend Developer,Product Owner,UI Design | Design System team engineers with the help of a dedicated platform team that serves the whole Product domain. | Automation everywhere. Designer makes a change to a token value -> a PR is created (the designer can also approve) -> Automated tests (visual regression, accessibility, unit tests etc. -> Analysis of what has changed in the built assets, and which projects use those values. This helps us to communicate changes especially if we are about to drop tokens -> Automated publishing of NPM package based on changesets -> Automated updates in all consumer projects with Dependabot so all design system changes get updated as fast as possible to avoid any mismatches in the many microservices we have | ||||||||||||||||||||||
36 | Let by Product | Frontend Developer,Product Owner | The engineers, engineering manager, and uniquely, the designers (who both code) | I think three things for us at the moment: 1. Really excellent APIs that engineers really want to use; no corners cut, best modern practices, 2. Availability where the engineers are at (e.g. monorepo on web, package in iOS), 3. Word of mouth marketing to organically lift the authority of our system | ||||||||||||||||||||||
37 | Led by a balance of Engineering, Product, and Design | Frontend Developer,Product Owner,UI Design | Technical Lead (Lead UX Developer) | Get buy-in from engineering leadership & partner with architecture to know what standards they think are critical, stay in the know about changing engineering standards, two-way conversation with our user community to understand what they're experimenting with. More tactically, make APIs more flexible rather than less (a lesson we learned the hard way) to allow for future features / scenarios | ||||||||||||||||||||||
38 | Led by a balance of Engineering, Product, and Design | Frontend Developer,Most of us fulfill these roles as needed, depending on the project. | Engineering (with collaboration from Product and Design) | Focus on solving real problems for the teams building services and the people using those services. A design system lasts when it is grounded in user needs, easy to adopt, well-documented, and continuously improved through feedback. | ||||||||||||||||||||||
39 | Led by Engineering | Design Ops,Frontend Developer,Product Owner,UI Design | There is shared responsibility between product and development. The architecture of the components is owned by our chief development architect. Our development director owns the release process. And our product owner controls the communication and prioritization aspects. Our team does our best to consult with each other when needed so that we have the best information to make decisions and then leave the final decision to the appropriate stakeholder. | Parity is paramount. Debt is detrimental. To manage debt, we take parity very seriously, which is why every development change is evaluated to determine if it requires design and documentation changes as well. The designers and developers using the system shouldn't have to ask what the source of truth is, and they shouldn't have to compare the design, documentation, and code to figure out what is going on with a component. We also carefully consider whether changes will be impactful or breaking in any way. When our product teams use the system to build their applications, they need to trust that the infrastructure it provides is stable so they can focus on solving other problems. | ||||||||||||||||||||||
40 | Let by Design | Frontend Developer,UI Design | Design and Engineering equally (two person dedicated team) | Scalable & modular frameworks, clear documentation that lives where the team works, and strong feedback loops to ensure the system is actually supporting the team. | ||||||||||||||||||||||
41 | Led by a balance of Engineering, Product, and Design | Frontend Developer,Product Owner,UI Design | Front-end | to always be curious about design systems and the how much can we make it agnostic to work with any tooling. | ||||||||||||||||||||||
42 | Led by Marketing and supported by Design | Design Ops,Dev Ops | Design team does, since UX defines the deliverables. | Nurturing it like a garden. Weeding and adding new plants. | ||||||||||||||||||||||
43 | Led by Engineering | Frontend Developer,Product Owner,UI Design | The DS engineers, although we still have to conform to enterprise standards for deployment pipelines. | Ensure that your release strategy builds trust through reliability. Users should have clear expectations of when breaking changes will occur (e.g. only in major releases) in order to minimize impact to their applications. There should be multiple layers of automated testing so that production bugs are rare. There should also be a clear deprecation strategy for any element of the design system so that users are informed of these changes and have enough time to update their applications before something is removed. All of these aspects give users confidence that they can keep their design system dependency up-to-date without a lot of friction. | ||||||||||||||||||||||
44 | Let by Product | Frontend Developer,Product Owner,UI Design | Engineering manager | - Read the mood music of the business and blend it with your DS consumer needs - You need the data & the insights - Keep the house clean (deprecation, cyclical comp reviews and improvements) It's rarely asked but always expected and can break trust over time if ignored. | ||||||||||||||||||||||
45 | Let by Product | Design Ops,Frontend Developer,Product Owner,UI Design | Development | keep your feet on the ground but your eyes on the stars. What I mean is, stay aware of what your tech team is currently capable of, but dream of better capabilities for the future. | ||||||||||||||||||||||
46 | Led by a balance of Engineering, Product, and Design | Design Ops,Dev Ops,Frontend Developer,UI Design | Design system lead engineer and now moving to our squads frontend developers | Governance | ||||||||||||||||||||||
47 | Let by Product | Frontend Developer,UI Design | SEM and engineering team | Focus on people, being flexible and understanding needs before jumping into solution mode. | ||||||||||||||||||||||
48 | ||||||||||||||||||||||||||
49 | ||||||||||||||||||||||||||
50 | ||||||||||||||||||||||||||
51 | ||||||||||||||||||||||||||
52 | ||||||||||||||||||||||||||
53 | ||||||||||||||||||||||||||
54 | ||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||