Episode 062 Raw Data

	A	B
1	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 062, deep dive hosted on October 2, 2025 with Ben Callahan and Jeremy Elder. 👏 Thank you to zeroheight for sponsoring this episode! Check out their special offer for you and your design system team! 👏 There are 53 answers. The question this week was: ----- Hello, system thinkers! Welcome back to this week’s co host, Jeremy Elder. He and I co hosted Episode 025 on the concept of design system shearing layers. This week, we want to take that conversation deeper. It’s become common to hear design system practitioners express that “our layer of work needs to move more slowly, with more intention, than product design or development teams.” We’ve long justified this by saying things like, “we set the standard of quality and it takes time to do that” or, “it’s too risky to move quickly with design system work.” While I believe those kinds of statements to be true, I’m also hearing from a lot of folks that there is pressure in the organization for the design system team to move faster. We’re going to try something a little different this week. 😬 We just have two questions for you, but we’re also assigning you a bit of homework. Let me explain… We want you to answer the two questions below to the best of your ability. But we also want you to do some digging between now and the deep dive on Thursday at noon. When you sign into the Zoom, there will be a spot in our collaborative FigJam file for you to add in the results of your homework. We’ll use that to help shape the conversation. Here’s your homework: If you’re feeling pressure for the design system to move faster, we’d like you to do some investigation inside your org to track down the real root of that pressure. Maybe you’re feeling it from your boss, but why are they feeling it? If it’s not initiated from their boss, keep investigating until you find the original source. Our thesis is that we need to better understand the root cause of this pressure to be able to address it in a meaningful way. You’ve got just a couple days to figure this out—start digging! Welcome to episode 062 of The Question. Is your design system team feeling pressure to move faster?  How does this pressure (or the lack of it) impact your design system communication strategy?
2	Question 1: Is your design system team feeling pressure to move faster?	Question 2: How does this pressure (or the lack of it) impact your design system communication strategy?
3	Yes	I have experienced external pressure (and sometimes internal from departmental leads), causing communication strategies to shift to a more defensive mode. Oversharing what we're doing to demonstrate progress, doubling down on actively demonstrating the value our work provides. Ironically, using up time and energy that could be spent working on the DS.
4	Yes	I am not sure yet
5	No,If anything we've received recent pressure to slow down as product teams struggle to keep up with updates inline with our rate of change. This may have a lot to do with being consultants outside of the typical internal org structure.	We have been upping our communication strategy to communicate changes clearly, to key stakeholders as well as the typical devs and justifying changes and why we're making them.
6	Yes	Constantly being asked how we are innovating, how are we intergating AI, whats next on the roadmap. When we talk about BAU and foundational work the question is always Why? Whats the benefit? My one liner is that the foundations will unlock innovation and speed. But the constant stakeholder engagement to push the same message is draining.
7	Yes	It has impacted me negatively but I've had amazing colleagues back me up/save me thankfully. In previous roles, I've seen the pressure involve others' health.
8	Yes	Forces us to stay top of mind fo the organization rather than being impactful and purposeful with it
9	Yes	We were pushed to release beta before component docs and usage guidelines were complete. We’ve also been told to focus on continuing to deliver, rather than helping consumers onboard. We’ve continued to push back against that since we serve teams early in their maturity who need our support.
10	Yes	I think our communication has taken a back seat as we've tried to make the design system a comprehensive tool that meets all of the most important component, token, and development needs.
11	Yes	Often we lack in our frequency of strategic communications due to constantly changing pressures and priorities. Or if we've communicated often people still haven't understood. Often we will repeat communications in many spaces so each person hopefully hears more than once. It's both a lack of prioritizing communications on our part and commitment to move quickly in the company and by nature that can be skipping reading or any step to do so. For example our company value is act fast, learn fast but we sometimes use it as an excuse, well I acted fast but forgot the learning part.
12	No	At times, we lack prioritization in creating new features and balancing the longterm roadmap. However, we are OK with that lack of pressure because it allows our grassroots team to have flexibility to balance their other priorities.
13	No	We strike a balance between not wanting to be a blocker and knowing what requires extra attention. Typically, our consumers understand that the scale of their ask may require more or less time to implement. They also know that it may go faster if they can directly contribute. We then help contributors understand the impact of the change and the checks that need to happen to maintain quality. So far, they've all seemed to understand and feel it reasonable. (Also, I send that article to my boss like every 6 months)
14	Yes	We need to learn what others (multiple levels up or over) in the org care about, what their perception of the design system is, and how it does or doesn't meet their needs. Based on that, we have to determine meaningful ways to shape the work and communication to best support the layers above. We don't have answers today, but are working through it.
15	Yes	We have felt the pressure through the rest of our design org feeling the pressure. This has caused us to have to repeat communications or find more obvious, more efficient, more convenient ways to tie design system updates to their processes. A specific recent example was around layouts. We launched layout templates a few months ago, did a brown bag session on this, provided reminders and deep dive sessions on these with recorded sessions for designers to go back and reference how to use them. Recently we did research on this feature and found out people didn't know they existed. Designers are working so fast and in a high production environment that they are often omitting these as part of their work and falling back into previous habits because it's easier for them to remember or learn. We've also felt the pressure of teams not wanting to follow standards due to AI related pressures to move faster. Teams are claiming that we need to move fast and reduce the time it takes to complete work but this often ends up being an excuse to omit due diligence and quality in an effort to do so. We're trying to address this by meeting them in AI tools but there's still this perception that following standards like a design system 'slows them down'.
16	Yes	Personally I'm not sure how it affects our "communication strategy" if you're referring to external/consumer comms. Internally, it makes communications tricky because tracking the work and statuses for dependent tasks or initiatives are a moving target. Things appear to be like a sprinting relay-race: when a task is done, frantic Slack collaboration happens to ensure the next person can move forward on their task, or alternatively there's periodic and repetitive "where's this project at?" questions (even when the person's been as transparent as possible).
17	Yes	Communication becomes fragmented, unclear and insufficient. When we try to rush towards satisfying the urgency of the requests, documentation quality gets impacted, and teams suffer from that as well. Questions like "why you do this instead of that?" start to pop around teams, trying to understand underlying decisions, which are barely justified upon the ability to ship faster.
18	Yes	I often feel behind on updates, which delays developers. To manage that, I avoid giving firm timelines. With vague timelines, I can deliver earlier than expected and avoid disappointing anyone. But it also makes communication unclear. I’m working on sharing progress more often and breaking updates into smaller pieces so developers aren’t left waiting. Still, to give better estimates, or speed things up, I’d need a bigger team. I’m hoping to get that by the end of the year.
19	No	I have experience with a past employer that pressured the design system team to move as fast as product, all while simultaneously swapping out fundamental pieces causing the team to start over from scratch (the core tech components are built in, the way tokens are named, etc.). I'm happy to share my story, because this type of expectation from leadership has real, tangible impact on staff members. I just had spine surgery 2 weeks ago to replace 2 discs in my cervical spine, and I attribute the stress directly to past work experiences more than anything else.
20	Yes	It forces us to make decisions that aren't fully thought out or tested and often, we have to go back and redo them, further disrupting product designers with breaking changes.
21	Yes	I don't think there's a universal rule for turnaround expectation for any software; all issues of scope & delivery speed are negotiations between areas of leadership that have different incentives. Depending on the health of the organization, product, and strategy, those incentives may or may not be at odds with one another. At my work we have good cover from leadership around DS working at a healthy pace without being considered a bottleneck, and our "adoption, not policing" approach prevents us from being seen as a blocker in general, but I also understand the desire for the system to grow at maximum pace possible. At least for now, this negotiation has been fairly healthy. (Note: this was absolutely not the case at my last job.)
22	Yes	The pressure is to move faster to adopt every possible new tool, while the design and engineering teams are aggressively cut. Every PM and leader wants to know what AI tools we're using to instantly and seamlessly generate entire design systems, UI layouts, read-to-ship code, and always-updated documentation. There is zero understanding of the limitations for those tools; just overly high expectations and hype mixed with the removal of seasoned, smary human workers.
23	Yes	Other teams face this pressure even more, and so while there is some direct pressure, part of the pressure actually comes from trying to match the pace of our dependent teams, like, being able to support them as they try to hit their goals.
24	Yes	It depends, there was a time early on when the assumption that every use case needed to go through the Design System and it was a bottle neck for folks. Once we had the baseline in place and created a layer for experimentation then feature teams could move quickly. Now unfortunately when we want to refactor something it take longer to get the buy in to invest in things like revisiting token updates that we know will have business in the near future
25	No	Progress requires consistent forward movement and continuous improvement. Users generally assume this is happening in the background. In reality, managing technical debt is less about visible progress and more about ensuring the service runs reliably, without sacrificing quality, while retaining the flexibility to implement changes when necessary. When external pressure is low, unspoken expectations tend to accumulate. That’s why it’s essential to maintain strong relationships and open communication with users. Anticipating their needs—often shifting gears before they even ask—is critical. By the time they request something, you should already be ready, or ideally, finished. This proactive approach has been highly effective for us. Because of it, we rarely face high pressure to deliver—we’ve already addressed the need before it becomes urgent.
26	Yes	We do get pressure to move faster. I think it makes it harder to make solid roadmaps and can make our communications about delivery confusing or disjointed (moving fast, we get more out of sync with each other - frameworks, design/tech). We get more and more of these rush requests. We get asked to put things in the system before they get tested.
27	historically, we have not BUT as adoption increases, the dial is being turned	with more adoption comes more need for support and with more support comes the tugs of specific products and the changing priorities within those products.
28	Yes	Difficult to explain, the DS communication strategy is not impacted per se, the result for the wish for more speed was the decision from above to just shut down authority of the design system team and make it a delivery team that builds what the product teams want. This hasn't really materialized yet in more speed as far as I know. One thing I really noticed with speed is that product teams are accused of being slow because there's this workflow: - a PM or PO sets a deadline without asking teams to estimate how much time is needed - designers draw Figma frames with components that are not feasible or present in the DS and developers notice that during implementation - developers now tell their PO that they will need more time to develop something (because they need to build many things themselves since not in the DS...but many PMs don't know this) - PO or PM thinks that since development is delayed they need to get more developers - new developers brought in the project need to be onboarded and slow down senior devs that now need to onboard them - new developers still get unrealistic deadlines and designs that require new components to be built from scratch - project deadline gets delayed again but no PM, PO or Head of understands why and blames the product team - product team now blames the DS team for not delivering the new components they wished on time - Head of thinks that the DS team needs more devs to build things faster ...and so it starts again.
29	No	Lack of pressure makes it feel like we have low engagement for our output. It also means we might not be motivated or inspired to prioritize progress on things we know need solving or improving, since people aren't knocking our door down for solutions. Personally, I know deadlines/accountability is what gets thing done when creative folk are involved.
30	Yes	I think we were busy pushing out components/designs that we have now run into the issue of a lack of parity across OS.
31	Yes	We are releasing certain components or tokens too quickly and are not handling the review, communication or release process as rigorously as we should be.
32	Not working on a design system currently.	N/a
33	Yes	I think more than the communication strategy what it impacts is the actual process that we follow to add things in our design system. There is an expectation that components should be ready within a time frame or certain number of components needs to be integrated in a given time. The challenging part is to keep pushing and standing firm on the non negotiable from a system pov which might not be online with other teams timelines. Communicating that is a challenge but we have to keep pushing for the right things.
34	Yes	It's hard to balance the need to compile communication in to informative and actionable messages / emails / etc. when getting pressure to speed delivery. It often starts feeling like we're communicating every detail to have that presence of "in front" of everything, but then that communication isn't impactful and the audience either gets lost in the amount of comms or brushes it off as not as important.
35	Yes	I think the biggest impact is that the speed at which we have to move, makes it hard for key stakeholders to be involved, so we have move to a more async communication style. Things tend to just drag on in Slack threads and get a bit disjointed.
36	Yes	We're seeing the dual pressurse of moving faster and support a wide variety of individual preferences for the same components. Impact on comms strategy has been to explain the level of flexibility our system has built in while also sharing the downside of building in too much variation
37	The pressure we feel comes from the constant shifting of company priorities from management.	The constant shifting of priorities requires our very small team to put enhancements we are working on for our customers on hold, while we attend to the next "important" initiative. We wear many hats, and the tasks we are asked to complete are often unrelated to real design system work, which is frustrating - not only for our customers that are left waiting for the completion of their requests, but also for our team that feels we are letting them down.
38	I wouldn't call it pressure, and it also doesn't come from above, it comes from some consumers.	Our communication strategy isn't directly affected by it - we keep reporting on our priorities (that are business influenced), our progress, and our timelines. The consumers who "complain" we're not moving fast enough for their needs usually do it from a lack of understanding (intentional or not) about what the DS is.
39	Yes	Communicating updates and changes in the system helps to drive adoption. When time pressure speeds up the cadence of DS changes or decisions you lose time to properly educate consumers of the system on what should be done moving forward. It also causes issues with documentation being less thorough and therefore harder to follow.
40	Yes	In my experience (previous employer) the people who say this are not receptive to any explanation or education around why we move slower than product/feature teams. Just move faster, that's it. No excuses. Who cares why you're slow. They (leadership) won't take the time to hear you out, read up, etc. At the same time, they would also be the first ones to complain about lack of quality, consistency, documentation you wouldn't have the time to create, etc. etc. if you were to actually move faster against your better judgement, bypassing parts of the process that are rooted in best practices. I know exactly why they are saying it (in my specific case), but I'll save that for the Figjam!
41	Yes	The communication strategy involves sharing updates as they are completed in various slack channels, and producing a video if a larger project. At the moment, we are not actively required to make "X" updates per sprint or month or quarter. There is a general urgency to all updates however, because they can be seen as blocking product improvements, and also the designers are not allocated to design system work, only myself.
42	Yes	It always leads to our component not being fully documented and understood across products. As well as finding edge cases and scenarios where the component wouldn't stand up to real world usage and bug tickets would always follow.
43	Yes	I am at the very beginning of the process, spinning up a new DS, with a lot of pressure to move fast as new product initiatives are also under high velocity pressures... In terms of comms strategy, this means I am having to do a lot of work around communication of the efficiency curve, fighting for the time/space to do things properly, get it properly resourced, demonstrating the value etc. I feel like this is all very typical and expected though... Phew.
44	No	At the moment, our comms are in a sort of limbo holding pattern until we get back into regular releases once our next major version is out of Beta. But this means we are just storing up a big long list of things to communicate once we're ready to make that release. We will couple that with in depth workshop training sessions so that it's not just a single big information dump.
45	Yes	DS work often gets descoped or punted due to engineering effort estimates or lack of rigor around proposed additions.
46	No,Yes	The design system at present remains an after thought that would of course be a nice to have but all other daily product work takes priority. As a result of that, I put pressure on myself to move quickly because that product work is not going to stop and the lack of a design system to aid in that design process only segments our overall product offering further.
47	Yes	Leadership wants to see KPIs and metrics. Nailing down meaningful KPIs for design systems seems to be a bit of an artform. Would love to know how other teams are handling this.
48	Yes	we try to reinforce more details about the work it takes for us to build solutions and why. it pushes us to try and explain the reasons why we cant just move faster but it also makes me think we need to be more visible about the work we are doing, even when its in progress. people who know how much my team has on their plate often expect more reasonable timelines from us. people who assume we have all the time in the world think that we should get to their ask much faster. as a leader theres also pressure to move faster when it comes to having answers to large strategy questions and thats what im dealing with now. my comm strategy here is to more clearly document the pain points we are facing outside the DS that impact our ability to grow "faster" or even at all. ive also been trying to document the downstream impacts of rushed strategy in an effort to articulate why we need to be more thoughtful about what were trying to solve and why
49	Yes	We have a tendancy to announce things before they are really ready, which puts even more pressure on the team's shoulders.
50	Yes	-
51	Yes	Currently, we have good leadership partnership with our design system and how we pace ourselves. We approach product design and engineering partnership in a collaborative "non-policing" way and make our case for adopting DS early in designs. I'm now an embedded accessibility (a11y) partner with our design system, so now have better check points for accessibility in design and engineering that will result in better usage notes/documentation, more accessible components, and more adoption across product teams. As an accessibility partner, it's always a negotiation and constantly providing backed research, data, pointing directly to WCAG/EAA or other country's a11y standards, like in South Korea, as base for accessibility recommendations. We rely even more heavily on research or standards defined in HIG/Material for native app accessibility. Even when meeting compliance, we can still fail people. So it's constantly a frustrating balance of "what keeps the business safe" vs. "how we can go beyond compliance." Pace plays a big part of how this ^ gets answered. It really comes down to what leadership/product deems a priority. In order to achieve disability inclusion in design systems, the pace ultimately has to slow down and account for a "shift-left" process with accessibility checkpoints from the start. AND getting buy-in from leadership to invest in this pace to build the foundations accessibly from the start (resulting in less future rework, defects, etc.).
52	No	previously, yes. I think it's a misunderstanding of what design systems are for, and a deep desire for a magic bullet.
53	Yes	There is a lot of communication to be done to manage the expectations and make sure to align what the system is able to provide and when. It also means we need to ask more often how teams are doing and check what they are concerned about and clarify with facts if the point of view or expectations are somewhat different than the reality.
54	Yes	Often running incircles chasing answers, becasue there's no time to wait for meetings or in-depth conversations. Also leads to some people feeling left out because we dont have time to wait and consult everyone, and just need to make decisions.
55	Yes	A number of ways. First and foremost, we need to be incredibly clear about how fast the team is already working. A lot of the things design system teams do are invisible to outside teams. It's important to make it clear all the things that the team is accomplishing on a weekly basis. It's also critical to share how all that work being done maps to company/org goals. Because typically pressure to move faster is often associated with a desire to work on something new/unplanned. So it's vital to show how important/timely the current work is. While difficult, we try to reinforce how early and often two-way communication is vital so that the design system can feel faster. A last-minute request is going to be difficult to turn on–which will make the design system team appear slow. However, ample lead time will ensure the things needed are delivered on time and on budget.
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