ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Thanks for your interest in The Question!

Sign up to participate in future questions here.

This file is the raw data from Episode 078, deep dive hosted on July 23, 2026 with Ben Callahan & Kacey Wood.

There are 50 answers. The question this week was:

-----

Hello, system thinkers!

Last week, ToniAnn and I were chatting with Kacey Wood, and she posed a fascinating question: if design systems were a college major, what would the course catalog look like? Of course, there'd be classes on tokens, components, and documentation. But based on Kacey’s experience, she was hoping for a load of psychology courses.

Design systems sit at the intersection of every product discipline, interact with nearly every product team, yet have virtually no authority over any of them. Perhaps our most valuable skill isn’t making components, it’s getting people to want to use them. Kacey brought up psychological reactance theory, summarized here from Wikipedia:

“In psychology, reactance is an unpleasant motivational reaction to offers, persons, rules, regulations, advice, recommendations, information, and messages that are perceived to threaten or eliminate specific behavioral freedoms. Reactance occurs when an individual feels that an agent is attempting to limit their choice or response or range of alternatives.”

The more someone feels their choice is being taken away, the more they instinctively push back, even against something that's objectively good for them. This week, we want to talk through tactics we could use to work with that instinct instead of against it—how do we convince people without triggering the defensiveness?

Welcome to Episode 078 of The Question, with Ben Callahan and Kacey Wood!

Questions:

What part of the organization does your design system team live within? (Select one)
Product
Design or UX
Engineering
A specific product team
A foundation or infrastructure team
We don’t have a dedicated team
N/A or Other (please explain)

Which group tends to push back on your design system the most? (Select one)
Product
Designer or UX
Engineering
Leadership
A specific product team
We don't see much pushback
N/A or Other (please explain)

What tactics have you successfully used to build buy-in for your system? (open text)

Tell us about a time someone convinced you to change your mind about a system decision. What did they actually do that worked on you? (open text)
2
Question 1: What part of the organization does your design system team live within? (Select one)Question 2: Which group tends to push back on your design system the most? (Select one)Question 3: What tactics have you successfully used to build buy-in for your system?Question 4: Tell us about a time someone convinced you to change your mind about a system decision. What did they actually do that worked on you?
3
Both Design/UX and Engineering (shared)A specific product teamTop-down mandate from leadershipMostly a beat until submission stand-off. The design system is meant to reflect the usage, even if the usage is arguably poor.
4
We don't have a dedicated teamProduct1. Neutral surfaces: start sharing and collecting feedback on the earliest iterations of your work in tools that everyone shares. Not Figma (design emphasis), not code (engineering emphasis). I personally use Excel or Google Sheets to start with token work. It’s a space everyone can have equal access to that everyone hates equally.

2. “Everything is a draft until it isn’t”: Opening every discussion with honesty about how firm the details are. People shutdown when the feel the direction is already decided.

The earlier you start, the more fluid the work. The more fluid the work, the more feedback you’ll get. The more feedback you get, the more investment you’ll build; and investment leads to adoption.

3. “I won’t always do, but I will always listen.”: be transparent that it’s your job to curate the decisions. They won’t always like those decisions made, but they will always have opportunities to influence those decisions in group or individual settings to have you say on those decisions. The only guarantee I can make is I will listen with an open mind before committing to a direction.

4. The Collapsing Ping Pong Table Method: Collecting endless rounds of feedback from partners is paralyzing, but you can’t ignore them on critical decisions either.

With each round of feedback, make informed decisions on topic details discussed by all stakeholders — even if not all universally agreed upon. Present 1-3 topics previously discussed, the decisions made as fact, and immediately transition into how those decisions frame the next discussion.

Go back-and-forth with incrementally less ground to cover. If you find you need to revise past decision, fine; but always drive the mission forward. Stagnation is death.

5. “Don’t show me different, show me better”: ground disagreements and/or ideas in the reality of improvement; not feelings, opinions, or hypotheticals. An alternative direction or idea is an introduction, not a solution. We deal in solutions.		A designer came to me with the problem that address fields took up too much space, and wanted to condense everything (street, city, zip, etc.) into a single field.

That sounded like a usability nightmare unless we implemented a Google address pre-fill — which would cost money and development we didn’t have.

Knowing that, the designer presented a clever expand-collapse model that satisfied the layout, accessibility, and usability issues as part of her pitch.

I was immediately eager to test and validate the pattern!

They recognized an opportunity for improvement, considered the practical realities around them, held their ideas to the standards of execution set before them. They addressed everything everything but the roadmap — which I was more than happy to support her with.

This happened in a single session, but just as easily could have been over two or three — I would have been just as supportive.

Identify problem, provide better solution, ensure that solution meets quality bar. I think that’s all we’re ever asking for in systems work.
5
EngineeringDesign or UXTraining, pre-sets, live demos, office hours, video snippets explaining core concepts.This past week, one of our DS engineers argued for a boolean prop because it was more in line with several other components and also with our CSS variable naming conventions. I bought it!
6
A foundation or infrastructure teamI think AI is now pushing back the most... even though we have an MCP.

The real pushback for a long time was design, because they didn't like how our design system "looked"... which is wild because it looked like the product. Even our VP of design disparaged it. Now they are all relying on it, but thinking they're using the system when they're not while vibecoding.		Design pairing, finding opportunities to apply the system in net-new projects (so roadmap glomming), show and tells, constant PR, videos, office hours (so overall education and support), projects where our team is actually adopting the system for folks, teaching folks they can just use tokens alone to adopt.For me, we are constantly having to compromise on design system decisions anyway, so I'm always open to change. The issue is a priority one where we don't always have the time to make adjustments.
7
ProductDesign or UX— Biweekly office hours.
— Active conversations about the design system to hear about what works and what doesn't
— Treating the team that uses the design system like customers we have to please		I can't think of a good story right now. Sorry. :)
8
We are in the Enterprise LOB, with members in Product, Design, and Tech orgs. So, kind of no single owner. AND, the LOB we sit in is also accountable for our 2 biggest products (servicing app and marketing site)...so, you can imagine where we fall on priorities (low).Particular products who are being pushed to innovate but also use the system.

Then designers/product managers who don't want to rock the boat, who want to move fast and lift and shift.		We've manually supported migration of components to the system. We're hoping to automate that a bit more w/ AI soon.

We hold office hours to support folks through using the system and seeing how flexible it can be. We do a lot of trainings w/ designers on how to use the system and Figma - many breaks come from lack of knowledge of the tool and how systems work.

We have created communities to create camaraderie. We do a lot of Slack support. We do onboarding of teams, presentations to design leaders. A little bit of everything, it feels like.		Can't think of any specific time, but what generally influences me:
- Accessibility guidance, feedback
- Pushes for more flexibility, since I work on the most core part of the system - flexibility means more people can use the system = greater success in my mind
- research, testing - evidence that X is a better decision. i'm happy to be proven wrong, when its truly proven
9
The "design system" (Figma libraries) is a design team. The React component library is a engineering foundations team. We hold weekly "sync" meetings. It's hard for me to say on the whole, because Design hold (and protect) their own interactions with product designers.
Our engineering team then mostly responds to technical issues with the library, so no real pushback there, just bug reports and feature requests.
The greatest source of friction our engineering team experiences is from the DS designers themselves, who seem really resistant to collaboration and feedback from engineering and accessibility. 😞		From a technical perspective, our component library is quite flexible and very well documented, and our team is great at responding to any questions and concerns. We believe product devs are quite happy with our library.Not sure if my mind's been "changed" on anything in particular, but if a good case is made for something given constraints and tradeoffs and the compromise seems reasonable, I'm pragmatic enough to disagree and commit.
10
A specific product teamDesign or UXMarketing our releases like a product launch - get people amped up about using a patternI'd say this is more of a team limitation, but the design + specification has already been made without thinking about whether it fits into our product principals, and then it was how we can adapt the feature to work with the DS - compromise is never going to be amazing
11
We operate within an our "Digital Services" team which is a cross functional team in charge of our public website, design system, and accessibility initiatives. We serve as front-end SMEs across organizational teams that lack dev resourcing or FED expertise as well.EngineeringConsistency with designs and baked in accessibility for teams that don't sweat the details of front end implementation.We were writing acceptance criteria for a date picker and we generated all these feature ideas, but the PO of the ask kept us level that we only need a fraction of the features, saving us cycle times and complexity.
12
Design or UXLeadershipThere is buy in in theory but no actual movement or willingness to devote resources. Having a really hard time to get there.Wanted to stand up a whole new system for our internal tooling set. I was convinced to instead stand up an extention that feeds from our primary DS. Their focus on maintaining a single source of truth convinced me.
13
OperationsWe don't see much pushbackDemos with designers. Road shows for leadership. 1:1 convos with hesitant engineersN/A
14
ProductProductFace-to-face conversations and communication. Showing people rather than telling them gets that "aha" moment, where individuals realize something can be easier, and certain tools just make sense to use.They pointed to a well thought-out framework rather than their own personal opinion. Allow systems to point the way prevents conflicts before the temperature rises.
15
half marketing / half ITA specific product teamsuccessful integration and implementation with one major product, word-of-mouthactually recently during discussions regarding interactive badges / chips
16
ProductEngineeringour UX department is all in on the system
we are still searching for ways to break through with all the different product engineering teams		multiple people have changed my mind.
if a system consumer brings a documented real life example and can proof that it's a valid use case and not a edge case, I'm totally open to changes and adjustments
17
Design or UXEngineeringWe have a governance system where new intent has to go through design system review. It helps garner understanding for how to use components and aiding with problem solving. I haven't had that experience yet :)
18
Design or UXWe don't see much pushbackWe are building a new product and our system is still new. Right now, I think everyone is so busy figuring out the specifics of our complicated SaaS product that the design system is helping them move faster. They are focusing on complicated work flows and don’t want to worry about what the basic components look like. So right now, the design system is fitting their needs, which is great. The challenge for the future is keeping it relevant once we move past the initial build phase. Understanding context really helps me. So if someone shows me a specific use case where a system decision isn’t working, or explains how a global update could solve a bigger problem, that’s really helpful for me. Showing me small or big context that I didn’t have before.
19
We don't have a dedicated teamProductoffice hours, some front-end specific rather than design ledN/A
20
A specific product teamDesign or UXA lot of education, both to leadership and designers. We also leveraged office hours in order to invite people to join and bring their own ideas, as well as proactively talk to people and try to help them solve problems using the design system, as well as updating and improving our documentation and guidance following the team's feedback. Bringing data and research to challenge a decision that the system team made was something that always worked on me to change my mind.
21
"Connected Enterprise"ProductWe've tried several tactics, but we haven't been as successful as we would like at building buy-in.I was young, naive, and working in the customer service department of our business. As a lifelong people pleaser, I felt very discouraged when a customer enhancement request was denied by the company, but when a sincere colleague took a moment to help me understand the business reasons for why we could not give every customer everything they asked for, that really opened my eyes to another perspective to which I'd been oblivious.
22
Design or UXFaculty. This is specific to me most likely, but they are the most entitled, ego-driven group I've ever encountered.I use numbers when it makes sense. Math and stats are hard to dismiss as subjective or opinion. I've seen people react to numbers in an expressive way that shows wonder/ah ha moments. Numbers also feel concrete, and somehow anchoring. Usually its a story that explains how they are trying to avoid some friction or annoyance with a process or outcomes. When I can have context from someone's point of view, my instinct is to agree that they shouldn't have to suffer a burden if its not necessary.
23
Design or UXA specific product teamCo-creating the system with its users gives them ownership and builds stronger support.I think the most convincing arguments have demonstrated that a proposal is customer focused, giving the users/customers what they want/need. It’s more convincing than a just a design preference, industry trend or competitors example.
24
Design or UXDesign or UX- Bringing DS considerations early enough in design crits
- Explaining decisions/justification and how it is beneficial for the product/team
- Letting designers know that they always have the option to build something custom and out of the DS, but explaining the benefits of having use the DS for their use cases - seems counterintuitive to getting buy-in for the system, but it helps designers feel less constricted and more informed whether using the DS is the right call for their use cases		Ended up changing our strategy and IA around zeroheight. Ultimately, it was persistence and an honest evaluation of available resources we have to carry out the strategy.
25
Design or UXA specific product team• Showing the risks of the alternative
• Executive Sponsorship
• Case studies, early adopters		They showed me how a decision would cause them undue stress
26
We don't have a dedicated teamArchitectureCrafted a business case to shop around with leadership to get executive sponsorship for building Web Components to support multiple tech-stack products.I'm basically in an ivory tower and everyone has been on vacation for weeks.
27
A foundation or infrastructure teamDesign or UXSupport channels like office hours and slack channels, aligning jt to the vision of reskins or refreshes, prioritizing what we know will have adoption, lending team members to join product design sprints, shares in larger design meetings, and relationship building overallThey showed their work. They showed us what they tried from the system first and how they thought about breaking or evolving the system. They brought us along their thinking and then let us arrive at the same conclusion
28
We have a dedicated cross-functional team but product and design sit in a global digital org and engineers sit in tech.A specific product teamBuilding advocates that can influence there teams, supporting intake requests for quick wins, tying usage to priority initiatives like redesigns, collaborating with teams on emerging needs, staying flexible where we can, and being good partners. Showed compelling usage needs / limitations of current system assets. Honestly just sharing their reasoning and intent, often there is a good reason that I just hadn’t considered.
29
Not currently employedIt's usually a mix of Design, Engineering, Product, and/or Leadership depending on their buy-in. I've been in a large organization that had the backing of Leadership, but the individual product engineering teams felt they were losing autonomy. In another instance, the original design system caused more friction the it helped, so the resistance was from the Designers and Engineering.Proof of concepts work well. Coded demos work way better than hand-waving. You do take a risk investing so much time in the proof of concept, but there is less open to interpretation.It is always around the edge of the design system, where it should stop and the product domain take over. Sometimes more capacity exists in the product teams, so the role is coordination rather than tangible product delivery.
30
Design or UXDesign or UXWe were doing a design check in Zeplin that checks files against components automatically. In the age of AI, everything has slipped back for ease of use.When someone has an opinion that they care about, and can articulate that opinion, it’s easy to be open minded.
31
ProductWe don't see much pushbackIncreasing quality of the system and educating consumers on use.I was advocating for component level tokens but after I saw that broader semantic meaning could be applied I saw the value in having a smaller set of tokens.
32
EngineeringA specific product teamWorking closely with teams to help them with their specific use case/needs. Or showing that our system has the feature/functionality out of the box, and can save them time and maintenance.I can't remember anything specific. But they are usually around accessibility, or continuity with other parts of the system. Basically, there's something bigger than a component, or isolated decision, that influences the correct direction for the question at hand.
33
Design or UXEngineeringSticking with it for 8 years, getting leadership buy-in and asking them to hold teams accountable, getting a stamp of approval from our architecture team, identifying hold outs and going to them directly to show them we are real people who are trying to build something they want to use, prioritizing some of the hold out team's specific requests as a show of good faith, leveraging our UX teammates to also promote the design system to their squads, showing up to engineering roundtables / hackathons / etc to give our pitchUsually it has taken a team finding some other teams who share the same concern or need so I know its not just a one-off need. It's also been great when a team comes with some user research/testing to back up the claim of "our end user really needs this feature"
34
Design or UXDesign or UXShowing practical examples of what this fixes based on the team that has already implemented it, explaining the story of where this started, showing example of what problems this would solve for them
It's always discussions. They present a problem or concern and we talk it through, going back and forward to brainstorm idea, our concerns, until we reach a conclusion.
35
Product Mgr reports to Product org; UX reports to UX org; Engineering reports to Tech org but we all work together as a team dailyEngineeringI talk to A LOT of people at varying levels because if you don't have buy-in from top to bottom, you will only get so far. We have strong support from leadership so that carries weight and influence on consuming teams. We also take a very supportive approach on our team so when talking with folks about our design system, it's always a conversation about enabling and supporting their work. We almost never approach things from a "you have to use this" point of view.I can't think of anything specific but if someone wants to convince me of something, I'm big on data-driven decisions. Show me the data that supports it and it doesn't take much to convince me.
36
ProductEngineeringOpen-minded conversations with teams hesitant to use the design system, and offer various levels of adoption. As a large company with many acquisitions, new teams with existing products bring different requirements and legacy decisions with them. Once we understand their needs and roadmap, we help determine the right fit. If that means using only our design tokens, then that's a good start.When users can demonstrate, in practice, that a system decision could/should be different, and that change benefits the greater good of consumers, then changing my mind is a no-brainer.
37
While we're in the same unit, we're technically split between two organizations (engineering and product management + ux)A specific product teamWe spent a lot of time building up a good community of people by providing dedicated support and hands on training, which lead to leadership seeing the value and putting system use expectations in OKRs and throughout the product development process.Alignment on timing. While understanding an update was all something that was needed to be done and there were processes to follow for a unified release across teams, I needed to be convinced of a better time for the release and consider other engineering efforts teams were already tasked with. Getting more visibility in to the cross organization expectations supported the logic to pivot even though I was pushing hard for a release based on the timeline I had determined.
38
Design or UXEngineeringSelling people on how much time and money it will save in the longer term. Showing examples of successful systems from known a brand or companyThey described the cost of each suggested option and why the one they recommended was better
39
the miscellany drawerEngineeringIts implementation easing complianceProvided enough evidence to make up for the tradeoffs
40
A foundation or infrastructure teamEngineeringAny "pushback" we get is less about resistance to change and more about practical technical hurdles (e.g. frameworks, code environments, etc.) that would slow-down the consuming team if they tried to adopt. Since our DS is still relatively new/young, our tactic is to take in as much of that information as possible and try to tool-up the DS accordingly--if it makes sense to do so.This happens a lot, actually, and the method to convince me isn't anything earth-shattering: they simply have to lay out the case, show the facts, etc. As long as they act like a calm, rational human being who's presenting facts (and opinions are okay too), I'm receptive. That's built into my DNA as a designer who's been receiving feedback, pushback, critique, etc. for 3 decades now.
41
Design or UXEngineeringSocial proof - teams are using it and are happy with it and it helps them do better work. Someone else advocating for us.Not necessarily changed my mind, but pushed me to try different approaches to collaboration and contribution.
42
We’re a team of two. I (design) am under Product & my frontend counterpart is under Engineering. We used to be under Design prior to a reorg. ProductOffice hours for support, jam sessions for collaboration, surveys & workshops for input, feedback & collaboration, pitch decks & lunch & learn sessions, 1:1 conversations with leadershipMy frontend counterpart recently convinced me to add a new RadioGroup component (instead of as a pattern/recipe) in order to provide the keyboard/screenreader accessibility needed. Initially the ask had been for a pattern. Accessibility is something very driven from the design system and newly prioritized at our org, so the case was made clear. I updated Figma for parity with code on the component approach (extra important in this AI era as we want to make sure the right components are being used in AI assisted development!)
43
A specific product teamDesign or UXOpen communication channels. Weekly dedicated sessions for component and documentation critique, backlog/roadmap sharing. This enables teams to have a shared sense of ownership of the system.Whenever teams come with data that supports their suggestion to evolve the system, that helps me and my team a lot. We recently were debating whether to evolve dark mode (the existing version is pretty robust), but we were shown that 46% of users navigate the product on dark mode! which pushed us to keep investing in it.
44
Design or UXEngineeringMostly pointing out inconsistencies that keep popping up and the lack of scalability that creates. I wanted to pick a more actively supported and widely used Figma library as our DS starting point, but due to our tech stack, I was convinced to use a library that was created by the same company that we use for our component repo. I wasn't thrilled about it, because I knew for a fact that the component repo was inconsistently used, but I knew I wasn't getting traction in this matter otherwise. An imperfect move forward is better than no move forward.
45
Design or UXA specific product teamI'm going to interpret this as a question about adoption. Like we discussed last week, accessibility has been our primary leverage for adoption. We have also had top-down consistency initiatives as well as dark mode and theming adoption. We have also done projects where we worked closely with product teams to add features that they need in order to adopt certain components.I always try to keep an open mind and leave room for key details to change my mind. I'm struggling to think of a feature change decision example. But one thing that has certainly changed over time is our views on detaching components in Figma. For early stage exploration or feature enhancement proposals it makes sense to detach. However, we also have tooling to convert designs to code which hinges on the expectation that all components are not detached. So the reality is that detaching is sometimes necessary and other times you very much need the components intact. What this reveals is that it would be helpful to create tooling to get a team re-attached to the component in later stages of design before development handoff. Being open to those solutions requires an open mind and acceptance that detaching is acceptable and a reality in the process. If detaching it was completely discouraged, I can't see a reason why we would build any tooling to help people to speed up the process of getting from their detached exploration to a more viable development handoff state.
46
Design or UXEngineeringEducation and advocacy although it’s only gone so far. We have a challenge convincing engineering leadership of the value of the work and that it’s not a design-only priority. Practical examples of the impact as opposed to theoretical justification
47
Product Design, which ultimately sits under ProductWe're early in the engineering/adoption journey, so there's currently very little pushback.Design (designers and leadership) were very on board. I haven't had to do much selling here!I added some components and/or elements that I don't agree with (e.g.: carousels, a little badge thing in a tab list) because they currently exist in code. I do plan to deprecate and/or standardize those things eventually, but I'm choosing the time of my battles in an effort to reduce friction and maintain a positive perception of the design system.
48
design, tech, and product folks are separate and report to different people, but work as a team. there is a single team, but not a single reporting structure. that makes things very complicated because the design leaders have no say over what the tech leaders decide to do, up to and including moving the design system tech team members off working on the design system entirely...In my experience, the pushback always comes from people in the larger applications, but doesnt really narrow down to job family. designers and devs alike from larger apps will be more likely to pushback on using the system because they likely are also skilled experts that could have built the system themselves and have the most opinions on how its built. On the other hand, smaller app team members usually dont have the same skill level and are hence less likely to push back on the system and are more likely to use it as is because they dont need the expert skill to use the system.I dont really think I've ever achieved actual buyin for a design system. All of the ones I've been a part of have fallen apart due to the evaporation of leadership backing for some reason or another. Every time we thought we had longterm leadership backing, that turned out not to be true. Im starting to think its not actually possible to build true leadership buyin for the design system at a large company where proving business value can be very difficult.This seems like a loaded question because I believe that design system team members should be open to changing their minds about their system decisions. I dont believe it should be a struggle for design system adopters to change the system that should be built for them in the first place. Likewise, I dont believe that system owners should position themselves as the arbiters of all the good decisions. That said, there have been numerous occasions where we changed what we were doing because of a suggestion from a consuming team. All it really took was a use case, suggestion, or idea.
49
Half of us report up to marketing and the other half up to IT.EngineeringGrass roots efforts and work of mouth have been very helpful with the teams that don’t have front end engineers, but any team that has even one engineer who enjoys or considers themselves strong in front end it has taken top-down direction.Don’t have time to describe an actual example but I would say anytime they engage us in a conversation about it, share examples, and are open to understanding the impact on other users we are pretty easy to convince. But when they are just focused on what they want for their project or we hear second hand that they have just chosen to deviate for whatever reason we are far less likely to give it our time and attention.
50
ProductWe don't see much pushbackI've emphasized that design systems will reduce the amount of pixel pushing our devs are doing to ensure content is consistent throughout the app. By building with DS components, product designers will be able to focus on solving real user problems rather than focusing on small, yet time consuming visual tweaks.I don't have a scenario where someone successfully changed my mind (haha), but there have been times where they tried to convince me to go outside of the DS route. For instance, my squad devs insisted on building a slider component from scratch because they mentioned that the DS component didn't solve their needs. Due to DS team priorities, we weren't able to work on implementing changes to the slider component at the time to solve for those needs, but we did tell the squad devs to at least start with the existing component and then build off of that instead of starting from 0.
51
Design or UXProductBy just executing the entire integration at a lower environment to show proof of DS value
52
Design or UXProductInvolving the product teams directly in design, planning, and implementation. Their needs are carefully considered while we also provide them with DS support and educationDesign teams iterated on a problem and came up with a solution, but had not implemented it at a system level. A pattern came into question where I offered my recommendations, but they pushed back, citing their explorations and precedence, so we incorporated their solution into the system. I still disagree, but it's what works best for the teams, and does not harm the system or product.
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