Episode 29 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 29, deep dive hosted on August 22, 2024 with Ben Callahan and Adekunle Oduye. There are 27 answers. The question this week was: ----- What a week! Adekunle and I are just back from Pittsburgh where we joined 40 other design system nerds at Symmetry and celebrated Brad Frost’s 40th birthday at Frostapalooza. It was wild and I am 100% certain the photos and videos will start rolling out soon… 🙂 While there, we chatted a bit about the idea of turning our failures into lessons. In the design system space, we tend to have a lot of failures. There is so much to consider that it’s easy to find yourself in a situation where you realize you’ve missed something. A failure to communicate, a failure to engage with your users, a failure to build something helpful—they happen more often that we like to admit. This week, we want to dive into some of our failures. But we also want to hear how you’ve used those failures to mature your approach to systems. With this as context, here’s The Question: Describe a design system failure from your past. Describe how that experience has impacted your approach to design system work.
2	Question 1: Describe a design system failure from your past.	Question 2: Describe how that experience has impacted your approach to design system work.
3	The failure to communicate properly jumped right out. Example 1: early in my DS career when communication (asynchronous and synchronous) wasn't explicitly focused on as a primary source of adoption and solutioning, and as a result a design system took much longer to stand up than it should have Example 2: later in my career I was tasked with turning around a DS and an overwhelmed & frustrated DS team member responded: "it's not my job" to a high-value problem (ensuring the alignment of front end standards)	Solutions: focusing on synchronous and asynchronous communication channels as a parallel track to asset delivery has become a part of my DS process and has vastly improved all the value of all DSs I worked on since the failures.
4	I've made the mistake of attempting to make the design system everything for everyone all at once; which was doomed to fail from the start.	We now approach things slowly with the knowledge that iteration will be necessary down the road. Components don't need to be perfect from the start as there is no way to account for every possible circumstance you'll run up against down the road.
5	To paraphrase others, focusing on the ingredients instead of the cake. In other words, too much emphasis on the parts and not enough emphasis on what the parts create.	Thinking and communicating more about what consumers and stakeholders want, while leaving the details on how we get there for the design system team to work through.
6	So the difficult part of this question is trying to get one particular instance! Let me think..... Let me introduce you to the MPRUS component (pronounced Empress). Or if you prefer its full name: The Multipurpose Responsive Utility System. It was over-engineering at its finest. You see, when we created this in 2018 we were not only creating design system components in Figma with web components, but we had to create components that could be used in a drag an drop web editor too. We used grapes.js to help us build the pages which to this day still has a clunky interface. But what does it do? It essentially allows the user to be able to visually add content and fully affect how that content would change fluidly on the page. There was an enormous amount of business logic that was apparently required in order to meet the flexibility needs of our marketers so this got translated into an abomination of a component that poor site builders had to use. Turns out though that they couldn't really. So the savings that we thought we'd have with our nifty drag and drop site building experience that anyone could use turned out to be a little false. Developers still had to build the sites but now not using code and using a clunky GUI instead. Oh such fun! I do believe though that the MPRUS component lives on.	Thinking holistically about the entire development cycle that the design system may be a part of is critical to it's success. But the design system team need not just be a bystander. No, it's important for these experts to actually have a say in the way the end product will be delivered too. Whether that be constructed using Drupal's page builder; NextJS; or even Grapes.js it's important that the engineering all fits together in a sane and healthy way. If one part of the system has friction then these grumblings caused by that could cause ripples throughout everything. This can harm adoption at best and at worse even kill a design system.
7	I once worked on a design system where we focused too much on the technical aspects and neglected to engage with the end users. As a result, the system didn’t meet their needs, leading to low adoption and frustration.	This experience taught me to prioritize early and ongoing user engagement. I now involve end users from the beginning and continuously gather their feedback to ensure the system truly meets their needs.
8	I’ve been working on the same design system for about 7 years. My team worked really hard to get tech resources, product buy-in, and large scale adoption. For a few years, it was going really well. But over time, people left, enthusiasm dwindled, and resources were moved to other projects. At this point, we don’t have dedicated developers, the system has gotten bloated and unmanageable, and product teams are seeing it as more of a blocker than a helper. We are currently working on making some improvements, but it’s been hard to talk leadership into giving us more resources when the system has turned into such a mess.	I had been very enthusiastic about working on our design system and was all in on the benefits. But at this point, I’m seeing it as more of a failure and wondering if it can be saved. This is the only design system I have worked on. That’s why I am coming to these talks, to hear about other folks’ experiences and to learn from them.
9	Not taking time to research and understand design system users’ pain points & experiences (due to business budget/resource/time constraints)	I’ve gotten a lot better at advocating for the value and importance of taking the time for research in design systems…how it can impact adoption, improve collaboration and ultimately save the business time and money.
10	A laundry list of strategies is not a strategy.	I’ve become more honed in design strategy to apply to shaping design system strategy
11	When it comes to launching large updates, it's easy to forget the sweat and tears it might cause consuming teams. Focusing on the big release without regard for the upgrade path and making tools to make that process smoother was a past mistake that I'll take with me. Another mistake around support - support time needs to be outright planned so that the design system team is set up to be successful and avoids being stretched too thin across a full workload and a queue of grumpy customers. Put story points to support rotation and set aside time specifically to help the community like office hours. Launching things without a complete picture of requirements from all stakeholders can make releases fall flat. Build stakeholder interviews into the process and have a plan for when you realize you missed a scenario.	It opened my eyes to the service design aspect of design system work. Making the system is less than half the battle and less than half the value we can provide. Think about migration journeys, onboarding journeys, support process, intake and governance as well as community communication.
12	Consensus culture where you are trying to align multiple frameworks and find a solution but everyone is so focused on their framework specific implementations rather than a shared solution with slight tweaks aligned around a central design philosophy.	You need to align on concepts and principals at the core but don't worry about a naming convention or something specific because best practices of a framework should be the first priority.
13	Two forks of our design system gained too much momentum, took away funding from the DS, then lost momentum themselves.	We monitor adoption very strongly, allow flexibility, but no forks. -Arko
14	Our entire team ended up leaving/being forced out of an org because of various levels of misunderstanding between leadership, stakeholders, and our executive partner about how to evolve toward the next-gen visual aesthetic.	Bringing folks along the way, at different levels of fidelity, is essential to make sure folks understand (or, at least have documentation/content/presentations to point to) so when THEY are making their decisions, we can be sure to show the work, be part of the conversation, and be able to pivot to support organizational initiatives that drive change (in budget, and many other things)
15	Spending 4 months working on a complete redesign of our color system to enable, scale, and pursue a theming-centric model of products only to have it rejected by sales and our development teams.	This has taught me to start by removing any and all assumptions that I might have around my and other teams’ knowledge about and/or expectations for a give initiatives’ outcomes and/or ROI for the organization.
16	In my last job, The front end dev and I inherited a Tailwind design system from the CEO and engineering manager. When we had time to create our own system we debated abandoning Tailwind but in the end we kept it since it was easier for the backend devs to stumble their way through. We also needed our system to be theme-able. I hated that decision for every single project we created because it just doesn't play well with Figma components and with just two people it was too much to update for each new theme.	I avoid Tailwind but also am more realistic about what a team of two can accomplish while also producing new websites and features.
17	When trying to build our card component we decided in the design system team to add a free slot as content but to fix the card headline at the top with a fixed size. This decision seemed good to us also discussed with our designers but after a few months many teams wanted to create a different card headline and technically there was not possible because the headline area was reserved. This led me to think about flexibility versus restrictions as well as consistency versus total freedom.	I am now much more careful in when deciding to reserve or fix certain elements in our components but at the same time I’m also more sensitive to the fact that more freedom and more flexibility means also more work for the developers because many things when they are flexible require developers or publishers to build in responsiveness and accessibility themselves which is not necessarily a fast and optimized workflow.
18	A common header component was created by an engineering team attached to a particular brand/dept and shared with multiple engineers/teams for a project. When designers reviewed coded product(s), inconsistencies in form, typography and color were obvious. We discovered the component provided didn't work for other teams. Rather than saying something, the teams proceeded forward to match visual handoff as best they could.	Trust but verify.
19	Designing a design system without input from engineers. Oops	Deep partnership with engineering since then has been essential and fun.
20	Design systems need to exist to help solve the application design problems, or to provide a system for consistency across the application design. However, there are typical problems with design systems: 1. putting the cart before the horse, that is developing the design system first without knowing the scenarios. Typically this is forced by management on the design system team. 2. thinking that design systems are an end-all-be-all solution to every problem faced by application designers. They are not and there needs to be escape hatches for application designers to innovate on their unique solutions. Not every problem is a nail that is solved by a hammer.	I typically think about the design system as a living entity. The first draft is just that, a draft. You use it to start developing or refining the design of an application. As we learn more, the design system evolves and so the cycle continues.
21	A. Issues with getting proper executive sponsorship and allocating proper resources to make adequate progress. B. Being too ambitious.	A. Feeling cautious and anxious about investing time and energy into something that may not see the light. B. Cutting back on ambition and adjusting guiding principles to be more grounded in the current state of the product. Following a "kaizen" approach, where we focus on small incremental improvements vs big change.
22	Introducing a design system to a startup that wasn't ready for it. The first failure was that we didn't have system designers working on the project when we started creating the system, so while we thought it was okay to set up engineering infrastructure, as historically I've experienced development falling behind design due to this, it became a waiting game for designs. During this time, the company made a non-negotiable deadline for a product rebrand launch that the DS had to support to prove our ROI. Once product redesigns were ready, we still didn't have the designs systematized and struggled to get components built fast enough for product teams. Additionally, during this fast-paced rollout, we hadn't considered the additional support we would need to provide with the new technology that rolled out with it. We introduced web components so as not to inherit the legacy framework version used in the product. While they were technically compatible, using the components required a different thought process for developers. Combining that with the rollout was just too much for the product engineers, which led to the application having a poor overall experience as they simply tried to hack things together as best they could.	It was from this experience that I introduced the concept of "playgrounds" to allow more rapid development and exploration within startup design systems. It also built a lot of empathy on the impact of trying to do too much with a design system. While I do believe a DS can help modernize a product's infrastructure, the level of training and support that it's going to add needs to be considered. Since then, I've looked for more bite-size approaches for introducing new techniques to iteratively provide updates instead of larger sweeping goals that can really cause risks with unforeseen roadmap changes.
23	The biggest failure is trying to please all teams by including all fixes in the design system because you can't accept the fact that your design system can't cover everything and you can't let go of some features to be on product side.	When you have all the mess from all the different requirements, then the users don't want to use the system anymore, because it's too complicated. So, it's better to find a compromise or to let the product to handle some parts on their side
24	One of our past failures was in clear communication and not following through on what was communicated.	Now, we’re focused on making sure everyone’s on the same page and that we actually deliver on what we promise.
25	A systems team I worked on was implementing a new typographic scale. It wasn't a huge change but provided more flexibility for productive UIs vs some of the marketing applications. We made the decision that the naming convention for classes for the new scale would be different than the existing scale so that we weren't forcing a change but would allow engineers to adopt over time. Post release we discovered that an engineer on our team attempted to automate the change by modifying the existing type scale and we didn't catch it in QA. We had to roll the release back, revise and then communicate clearly to all engineers what had happened.	In large-scale enterprise systems there are very few "simple" changes. Best to over communicate and review your strategy repeatedly with your core team. With remote and distributed teams working quickly, it's critical to document and discuss almost all decisions with an eye on unintended consequences.
26	I was a part of a design system where design and engineering leadership constantly battled over control, authority, and who was leading who. There was no arbiter, and it meant the teams were never aligned. We ended up with a Figma library and a component library that influenced each other, but were never in sync.	I don't think I've figured out a solution to the problem of who leads who, or when conflict arises who the arbiter is between design and engineering, but I spend a lot of time making sure we feel like one cohesive group, and that designers and developers work closely enough together to avoid an us vs them mentality. We still have conflict and struggle but it's much more diplomatic.
27	At an old company, we required that everything had to come from the design system. Even one-offs that we weren't even sure would be successful once in the hands of the customers. This slowed down the process of getting new features into production and forced us into a bit of a waterfall approach.	After learning that requiring everything to be in the Design System was not the way to go, the DS and production teams came to a compromise. The Design Systems team created a component named the layout component, which had a vast array of properties tied to our design tokens - essentially allowing the frontend engineers to write CSS without actually writing CSS. It also allowed for the component to stay in sync with the rest of the Design System.
28	In a past design project, I spent too much time on a single component, trying to find the perfect solution. While it’s important to make sure a component is flexible and meets all its use cases, this focus ended up consuming a lot of time that could have been better spent developing other components.	That experience taught me the importance of balancing depth with efficiency in design system work. While it's crucial to ensure each component is flexible and meets its use cases, I learned that spending excessive time on a single component can delay overall progress. Now, I focus on finding effective solutions without over-engineering, allowing me to allocate time more efficiently across all components and maintain a steady workflow.
29	We had properties that matched in Figma precisely with what is in the code for component variants. Although it was great for Engineers, it confused designers and led to a not very user-friendly experience for Designers who didn't understand the properties or know what they were.	We should have done a better walkthrough of why we named the properties as such, but we also gained user feedback from designers on better naming conventions that we could compromise on with engineering. This led designers not to want to adopt components they didn't understand how to use but also to be unsure how they related to engineering. Overall, there was a loss of trust, and Designers felt confused when these tools were meant to help them work faster and smarter.
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
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