EXT: Episode 16 Raw Data

	A	B	C	D
1	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 16, deep dive hosted on April 5, 2024 with Ben Callahan and Amy Lee. There are 42 answers. The question this week was: ----- Amy and I were chatting about what it looks like when a system is doing well. Some of the signs of a thriving ecosystem might be: Excited designers who are empowered to make changes to a feature. Relieved engineers who have clear visual specifications. Trusting product owners who believe the system team has their best interests in mind. Eventually, all sides begin contributing to the conversation constructively—and then they start educating others on the benefits of the design system! While that kind of vibrant advocacy is needed for a system to become sustainable, the approaches we take to creating “fans of a system” can look wildly different in different organizations. This week on The Question, we’re talking about how to create real advocates for your system, so that it can take root and become much more than a tool. With all of this as context, here is The Question for this week: What is the age of your current design system? Approximately how many teams are using your design system? How would you describe the trend of adoption for your system? Explain what has or hasn’t worked to create genuine advocates of your design system.
2	Question 1: What is the age of your current design system?	Question 2: Approximately how many teams are using your design system?	Question 3: How would you describe the trend of adoption for your system?	Question 4: Explain what has or hasn’t worked to create genuine advocates of your design system.
3	1–2 years	3–5 teams	Somewhat Negative (some teams are choosing to create their own experiences)	First, we do not have a lead for our design system. Second, as a startup company, we are still too early for design system because we are more focused on building features than making the design system better.
4	3–4 years	More than 10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	Teams eventually run into blockers where they thought they could do something, and then it turned out they couldn't. Whether intentional restrictions or missing features, teams get frustrated when they are blocked and that causes friction between them and our team. We also take much longer to deliver things than other velocity-teams and so the uncertainty when we will be able to deliver is also a pain point. While we have a company-wide mandate to use the DS from product leadership, our NPS is still net negative among our consumers.
5	3–4 years	6–10 teams	Somewhat Negative (some teams are choosing to create their own experiences)	Lack of investment into DS resources from leadership. Like to talk but won't put their money where it needs to go. As a result only a handful of people are advocating for an inaccessible and severely undocumented design system and it's just not working. I'm not a full time resource on the team I just help whenever I can.
6	1–2 years	More than 10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	Despite having a company wide mandate to use the system, there’s still so much work to do to change behaviour. There are a lot of expectations of what the system can and will do for people, many of them are unfounded. When expectations clash with reality, that’s when negative feelings are created. We try to counter this with education - repeating ourselves over and over with “reality”. We also publicly celebrate anyone who works with the system and/or with the team.
7	More than 4 years	3–5 teams	Somewhat Negative (some teams are choosing to create their own experiences)	The system fell largely out of date after an initial hot start — folks left the company, priorities changed, etc. There was also a sense of the system being something that you build and then you’re all done. Now, some new folks have banded together to try to reinvigorate it. We’re doing things like creating newsletters, office hours, eng/design user surveys to gather sentiment, and we just announced a new internal “specialist program” for small cohorts of folks to about design systems. We’re still in the very early stages of creating advocates, so we’re not entirely sure what’s worked yet and what hasn’t. We’re hopeful that the specialist program will expose folks to what design systems really are (as we’ve found through surveys that most designers and engineers have not previously worked with a design system), clear up misconceptions, and give examples of what good design systems actually look like.
8	More than 4 years	More than 10 teams	Somewhat Positive (other teams have expressed interest in adopting the system)	Partnering with one team at a time to adopt has been successful for us. Dedicating too much time to onboarding can limit progress on the capabilities of the system, itself, though. It's also important not to grow the surface area of the system too quickly by adding multiple component libraries to support various frameworks if you're not ready. This can create interest and adoption, but you may find yourself overwhelmed and unable to provide good service. We've found that perspectives and needs for a design system change over time, so loose coupling is important to allow for those changes without a large burden on users. If you disrupt other teams' work, even just a few times, by requiring them to update lots of code to use your system, they will delay and begrudge the requirement.
9	3–4 years	3–5 teams	Neutral (the number of adopted teams is pretty stable)	Product teams are still not prioritizing design system adoption unless they are forced to do so by management.
10	More than 4 years	More than 10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	What has worked is component migration efforts and operating more like open source with contributions. Also, having components available in the necessary templates. What is limiting is when a request comes in for something new and we can't get to it right away, because it immediately means that team is looking for alternatives and it may be tougher to align with the system later.
11	1–2 years	3–5 teams	Somewhat Positive (other teams have expressed interest in adopting the system)	Our system isn't 100% live code yet. There is a hunger for it, so that is very encouraging.
12	1–2 years	More than 10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	Engineers have positive experiences when they use the components because it saves them time and effort. It's through usage that builds advocates. They actively advocate for having efforts componentized first before they work on them. On the other hand, designers require different tactics as usage alone might not be enough to convince them the design system is valuable. It's still a work in progress but pointing to consistency as a problem the design system solves may be the strongest message to produce design advocates.
13	More than 4 years	More than 10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	I believe that leadership mandating that everyone use it is highly effective. It definitely gets any stragglers in line and makes engineering have to prioritize developing it rather than it being the first thing they cut. However, the engineers on my project are already just developing their own system rather than using the one in place. To give them credit our team is on a different code base. I still don't understand why different teams use different code bases in companies. This is definitely a design system killer for saving time. The designers are all contributing to the system and submit requests for new additions or variations. This goes through approval which I think is highly effective. My one complaint is that there are too many teams approving designs and it is obviously slowing production down which is aggravating product managers and engineering who have tight deadlines. It's a bad sign when the engineers are ahead of the design team because the designs are being argued over by content, design systems, and product. Too many cooks in this kitchen. There needs to be a clearer decision making process.
14	1–2 years	1 team	Very Negative (teams are walking away from the design system)	Our company's first design system failed, created before my tenure. A year later, we launched Zest 2.0. Despite our efforts to collaborate closely with numerous product teams, only one team engaged, primarily due to concerns about the long-term support of the design system. They perceived it as more of a risk than a benefit.
15	Less than 1 year	None yet	I do have experience with two previous design systems though	The UX team carved out a fully day every three weeks to focus on non-roadmap UX initiatives (usually that was related to the design system). This time allotment for every designer created a culture of shared ownership.
16	3–4 years	6–10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	Good documentation has helped, but I think timing was especially important. We started building our design systems across Apple, Android and Web when our Apple and Android guilds were planning on migrating to new frameworks. So the design system gave them a running start on that migration work. Constant support and communication with consuming teams has led to plenty of positive and constructive feedback.
17	1–2 years	More than 10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	As we created our newest design system we heard our users, included our users feedback, had informational check in with users and included them along the way. This really helped gain adoption but there are still the few teams who have yet to get off the legacy system until now that a decom date is nearing :)
18	1–2 years	None yet	Somewhat Positive (other teams have expressed interest in adopting the system)	Most of our interest and adoption is hypothetical. People seem interested in the concept and possibility but nothing much to ingest/adopt yet. (Token taxonomy WIP, 3 web components and draft figma components)
19	Less than 1 year	1 team	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	We are still early days, but our current DS initiative was tech driven with the intent of having a server driven UI and combining that with a Figma to code plugin. This kickstarted our DS team and our product design partners have been excited to get to start to work with the new component set. Even our senior leadership has been touting this DS as a big part of our product/design/tech strategy moving forward.
20				N/a
21	Less than 1 year	6–10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	-
22	3–4 years	More than 10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	We've built a properly staffed team, who can provide 'customer service' - particular bug reports and quick fixes to engineering issues which arise. We've also worked hard to ensure gaps are plugged in the basic components offer - which was identified as an earlier barrier to adoption for many. By making change and engagement with our user needs visible - even if we're sometimes slow or imperfect, there's a sense of forward momentum for people to invest in. And by being visible as individuals, users who might otherwise be frustrated know that we - like them - are cogs in a big machine with lots of organisational obstacles to doing things quickly, so they cut us some slack!
23	1–2 years	6–10 teams	Somewhat Negative (some teams are choosing to create their own experiences)	We experienced that really involving teams helped us gain trust and increased adoption. Before we built a system in a silo and expected people to use it?, which was the wrong way of going about it
24	1–2 years	6–10 teams	Somewhat Positive (other teams have expressed interest in adopting the system)	Involving as many of our subscribers at various stages of design system asset creation (could be anything from component design, development, documentation etc) has really worked for us- these folks have taken great pride in seeing something they contributed to the system being used by other teams, and this has led to advocacy on our behalf. Our business is social recognition software, so as customer zero of our platform, we most certainly leveraged this to publicly recognise any and all contributions to the system, attendances at workshops, when teams increase their adoption and so on- basically any opportunity there was to publicly recognise, we did it and will continue to do so! But in order to give a more balanced view of the world- we did learn the hard way on the contribution side- to gain advocacy from a team, we allowed a contribution of a complex component from that team. This took significantly longer to approve as a result and over 1 year later we are still dealing with some fallout from it (code is too complex, we continue to find bugs anytime it is touched, at some point in the future we will likely start over with that component!)
25	More than 4 years	More than 10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	What has worked: Focusing on the designer and engineer experience; the user. Building the system based on actual needs, not on what we think a design system should be. A period of organic adoption, which was followed by leadership baking the design system into our DNA via architectural decision records that guide this part of our company toward the system. Word of mouth - most of our adoption came organically through referrals and by simply proving our worth through the value of enablement and empowerment. Early on, we heavily involved the community in the decision making that shaped the design system. Product designers that were around at the beginning of the design system felt a level of ownership that kept them engaged and excited to contribute. We went on to create an advocate program for the design system. This entailed documenting specific duties and behaviors for advocates - empowering designers in the product design org to become conduits for the design system in their local area of specialty. These designers would also be go-to SMEs of the design system and act as proxies for bringing all the product-level goodness to the design system. As the system matured and our organization's design system landscape grew more and more fragmented, this program was retired. I feel that engagement has greatly waned from the highs of the early days. What hasn't worked: I've watched other systems in our company start with top-down mandates ahead of the availability of the system. This only resulted in frustration and users rejecting the system. Multiple design systems across the company has led to uncertainty amongst teams about which system to embrace. It has made it difficult to instill confidence in our own system, and therefore the investment in engagement that we'd like to see.
26	3–4 years	6–10 teams	Somewhat Positive (other teams have expressed interest in adopting the system)	We have not implanted a feedback cycle for design system items, outside of small bug tickets. This means that generally speaking, if something in the design system works for your team, great! If not, create your own solution. This results in creating the DS as more of a dependency than a benefit.
27	More than 4 years	More than 10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	Many designers and project managers haven’t worked with DS before and therefore there’s often reluctance in adopting the ds or lack of understanding of what is possible and not possible to do with the system. Many people also think of it as a pattern library that can be adapted as wished by any teams. Educating teams constantly about what a DS is and what can be done has helped shaping the understanding but not always helped the advocacy necessarily.
28	Less than 1 year	None yet	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	We're still very much working on this but the people who are most genuinely excited for the system are the people who we have involved and communicated with early on. They are able to see the amount of thought and care and rigor that goes into the work we do and they really respect when we come with a simple output that they can use and love that they did not have to be involved in hours of meetings and conversations. Right now we don't have any people who are completely against using the system, but we do have people who are scared about what it will bring and skeptical about if it will work. I have noticed that these are the people who we haven't communicated much at all with so I think communication becomes the biggest thing we can do to create advocacy. We are also looking at making sure we have clear defined metrics that we can track so those who are still skeptical even after learning more can just lean on the data to speak for itself. I'm unsure how this will play out, but our goal is to use a combination of soft skills like communication and collaboration to build trust and hard skills like data and metrics to fill in the gaps where trust cannot be built or is still wavering
29	I had one at my last job.	1 team		I worked at a start-up as the only designer with such a small product team. Getting the developers to adopt the system was not a problem. Maintaining the system and making sure that the guidelines were clear was the biggest challenge for me. I worked closely on the system with a UX Engineer and he was a big advocate of the system. I learned a lot working with someone like him.
30	3–4 years	6–10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	We had a small team, 6 teams. And when a company is small, it is easy to demonstrate the importance of the design system. Additionally, it's easier to give a little push to someone who is not very exited about the design system, because you know the characters and can find a personal approach to them.
31				N/A
32	Looking for work	2 teams		I’m a researcher that wants to learn more how to collaborate with designers and their design systems to create prototypes
33	More than 4 years	More than 10 teams	Neutral (the number of adopted teams is pretty stable)	What worked: 1. Actively pursuing and pitching to teams. Especially when they are planning a revamp. 2. Keeping an extra hour a week for newly adopting teams, actively monitoring their adoption - even when they say everything is fine, there's always some mess to clean up. 3. Heavy focus on design conformance. 4. Strict versioning and supporting older versions upto 2 years for some products. What didn't work: 1. Extensive documentation - we did all we could do, they still had inane questions and issues which would be solved if they'd just read. 2. Trying to have a DS without a dedicated dev team, backfired like crazy, had quite a few dropouts. That was a dark year. 3. Leadership change - and then explaining to them why a dedicated team is needed - thrice. 4. Allowing a fork - the splintering immediately added 1.5x the effort down the line.
34	3–4 years	6–10 teams	Somewhat Positive (other teams have expressed interest in adopting the system)	We have struggled to gain leadership/c-level buy-in for pushing the Design system across the company. Recently this has been easier because we now have an upcoming product feature idea that directly relies on our design system for support. It seems they did not as easily appreciate the benefits of our Design System internally, until it became something that can directly contribute to making £££
35	1–2 years	2 teams	Neutral (the number of adopted teams is pretty stable)	the fact that it is based on open source library didn’t help
36	1–2 years	More than 10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	focusing on our customers at every level of org (from execs to junior designers/engineers). Everyone on the DS team is part of our outreach effort.
37	More than 4 years	More than 10 teams	Somewhat Negative (some teams are choosing to create their own experiences)	Design org believes each of their products deserves to be unique but doesn't understand how the system supports them in this endeavor.
38	1–2 years	3–5 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	Demonstration of value: businesssaw the ability to build quickly and in turn being faster to market, as well as devs noting the DS allowed them to remove 4000+ lines of code drove genuine buy-in from technology and business leadership. Design buy-in was easy.
39	We're still in the planning stages of our system. We're looking to engage our engineers very soon on this exact topic. With a survey to find the common goals to help us try to build advocacy from the start.			Received some negative backlash about the system as it relates to Policy and enforcement, I didnt. have a great answer at the time, but I know that if there isnt a policy in place it will be hard to get people onboarded to the system, no policy = "So you're saying I don't have to do this..."
40	More than 4 years	6–10 teams	Neutral (the number of adopted teams is pretty stable)	Make it the easiest option. Make people AWARE that is an option. Make using it, in real projects, as painless and friction free as possible. Make other stakeholders aware of success that was driven or aided by the toolkit when you are building/ship.
41	3–4 years	3–5 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	To large a question for me to answer right now.
42	Less than 1 year	3–5 teams	Neutral (the number of adopted teams is pretty stable)	The design system I'm currently working on is still in beta so we have only released to a small number of teams for testing. It's too early to really see any genuine advocates to the system yet. I have seen some support amongst a few teams and have been trying to foster those relationship with a lot of handholding as they ramp up their usage of the system.
43	Less than 1 year	None yet		Building WITH them whenever possible; over communicating; consulting with teams to help them make decisions
44	3–4 years	6–10 teams	Very Positive (many teams are planning to use the system, or there is a company-level mandate to do so)	Employing a rigorous visual language process when creating the system. Documenting the DNA so the system has a soul.
45
46
47
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