Episode 025: 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 25, deep dive hosted on July 18, 2024 with Ben Callahan and Jeremy Elder. There are 33 answers. The question this week was: ----- “A design system is a product.” I’ve said this sentence out loud to many clients in the past, but I’ve stopped saying it in the last couple years. Instead, I’ve encouraged my clients to think of design systems as a program instead of a product. Jeremy and I have been chatting about why this is an important distinction: products are expected to move at a certain speed—generally fairly quickly. Design systems can’t and shouldn’t operate at the same speed. They are more foundational and it’s a higher risk for them to change because multiple products depend on them. If you call your design system a product, your organization might expect the same speed, despite the fact that design systems need to move more slowly! Mark Boulton articulated this beautifully back in 2018 by connecting the work of Stuart Brand on pace layers to our work in design. And Stuart expanded the concept from Frank Duffy’s writings around Shearing Layers. Mark’s application is spot on and still resonates with our work in design systems today. This week, we want to explore how you experience this in your organization and learn what it is you’re doing about it. With all of this as context, here is the question for this week: How does the speed of your design system compare to the speed of the products built with your design system? How does this play out in your organization and what are you doing to address these impacts?
2	Question 1: How does the speed of your design system compare to the speed of the products built with your design system?	Question 2: How does this play out in your organization and what are you doing to address these impacts?
3	Our design systems moves slower than our products	Not always, but most of the time, systems teams have many more boxes to check when creating a scaleable system that is useable for a product; this has been the same story in all of the systems teams I have worked in. In my current org, our system has been pushed as the leader in delivering high-quality product work quickly and easily. As a result, it's often seen as a blocker when it does not contain everything a product team needs immediately, including new product exploration work. This has been a common theme in many of the systems I've worked in, as I've always had a lot of teams to support. Because of this, I have always felt adamant that a design system should never be a blocker to product teams' work and should only amplify and support teams, which is why 'custom' should never be seen as a dirty word. In my current team, we've implemented contribution processes that allow teams to go custom so that we're not seen as bottlenecks for the business. This allows teams to build products freely, test experiences, and then bring them back into the system so that we can amplify and scale them across the business. But this also allows us to weed out candidates that don't perform as well in the product before they've even been shared back to us, which has been an issue in the past.
4	Our design system moves the same speed as our products	It's a mixed bag, our DS moves slower than any single product, but it accumulates changes from 12+ products, resulting in changes as fast as a product.
5	Our design systems moves slower than our products	While the design system has moved slower than the products historically, the org of course wants it to move faster. (At least at the same pace). I’m very new in my position (1 month in), and the position itself is new (having a dedicated design system team is a new change for the org, and of course this already makes the design system move along more quickly than before), so I’m trying to nurture good collaboration and communication with the many stakeholders across the business to try to align on how they perceive the design system, and evangelize realistic expectations on the future speed and direction of the design system moving forward.
6	Our design systems moves slower than our products	This plays out a little differently for the design system compared to the product. The design system tends to measurably evolve over time, whereas the product tends to have jumps and stair-steps.
7	Our design systems moves slower than our products	For us it's less a matter of speed, and more a matter of assumptions of _what_ the DS will provide. Many expected the DS to be a component factory and provide whatever they need, when they need it. That was followed by them questioning why we take so long to release something. I'm still surprised how many people (even in the design org) are oblivious to the work that needs to happen to scale something from single-use to a company wide level (and people who should know better).
8	Our design systems moves slower than our products	We've been trying to work out what tooling, processes, flexibility, and communication can do to provide "healthy tension" between teams. We don't want to be a blocker, but we also don't want to introduce instability to the system. Currently, we're thinking about what we're willing to have less control over so that teams feel empowered, while at the same time ensuring that stability, robustness, and flexibility are included by default. We have a large epic (https://gitlab.com/groups/gitlab-org/-/epics/13441) where we've started to capture things that will help make our system into "a design system that helps teams be faster together." It includes everything from rearchitecting our current system site to communication strategy, and defining what is canon vs. expanded universe to optimizing for frontend consumers. I'm inspired by Thumbtack's layered system approach (https://www.figma.com/blog/how-thumbtack-structures-their-design-system/) that provides guidance and flexibility to help their consumers fall into the "pit of success" while always moving consumers in a positive direction of adoption and consistency. In his article, "How to turn ‘slow’ into fast (https://medium.com/@beauulrey/how-to-turn-slow-into-fast-3810ab4c3922)," Beau Ulrey notes that we have to "be a multiplier," and "dedicate time to enable others in your broader design and development team to reuse and contribute." Tapping into team rituals, activities, or resources that have a 1:many reach can also help lessen speed gaps and expose more of the need for slower design system processes.
9	Our design system moves the same speed as our products	I do not know
10	Our design system moves the same speed as our products	Our products move very slow so my answer is more of a testament to our struggles to ship as fast as wed like than it is saying that our DS ships particularly fast. At the start of our DS efforts, we were moving way too fast - we were being asked to create a POC that caused us to move quickly and without enough detail for wider audiences, then we had our product dev teams start around the same time our DS dev teams were ramping up 🤪. this caused them to want something to play with sooner than later and we shipped our first version of components that didnt scale and really werent ready because of that. i had been advocating for more rigor and slower pace but my org needed to experience the impact of too much speed before i could get them on board so after a point i just ran with it. the teams integrating components faced a TON of challenges and then came back to ask that we are more rigorous in our process. Frustrating for me, but glad we arrived at the conclusion together. Now, we are working with more rigor up front on component architecture, design, and illustrating the before and after impact of updates. Since this will take more time, im getting super clear about our roadmap and reiterating the positive impacts this will have on integration teams every chance i get. We are showing them all the thought thats going into the time were using up now and once they begin to pick up the more thoughtful components, my plan is to also get loud on the time saved for those integrating dev teams by not having to stop development and flag missing elements to us
11	Our design systems moves slower than our products	We set a cornerstone pillar of our workstream that we are ENABLERS of work not BLOCKERS and that a consuming team, for example, should never wait on the system to deploy work to production/ship products...even if that means not using as much of the system as they'd like. We treat the design system as a a service team providing core infrastructure for the success of product initiatives. It took some selling, and many conversations, to get us there, but it's allowed us to responsibly grow, advise, support, correct, and pivot alongside our consumers rather than become "the problem child" of the organization. We also try to make it as clear as possible that we have requirements before adding things to the system (or system-atizing an already established decision/component/thing)--we have an "additive threshold" where we require n# of cases of reuse before the system absorbs responsibility of maintaining a resource. We also have an internal team policy of "its easier to add than remove, so we add carefully and thoughtfully to prevent having to remove/tear things out". All of which attempts to best enable our consumers in the best ways while thinking about the larger ecosystem we serve (that product teams aren't chartered to worry about) while making sure we are meeting the current needs in whatever responsible way is possible (even if that means recommending they roll their own one-off solutions).
12	It does not apply to me at the moment but at a past company, I think it would be safe to say that the DS moved slower or sometimes at the same pace as our products. We had a dedicated DS team, but it was a team of 2 - a Staff Product Designer who had design engineering skills he used daily paired with our most recently hired junior developer. The Staff Product Designer/Design Engineer was making edits to Figma files and the code repo daily. The DS was a customized version of Material UI	At a past company, we always identified early in the product roadmap when a feature would require a new DS component. From there the DS team would prioritize the new component so that by the time the feature got to the engineering team it was ready, or almost ready to be released with a new version of the DS package.
13	Our design systems moves slower than our products	The pace of our design system is not really intentional. It’s been deprioritized over the years and we have very few resources working on it. The glacial pace of changes has led to product teams working outside of the system. I am working to get more focus on the design system, but product folks have begun viewing it as more of a problem than a helpful solution.
14	Our design system moves the same speed as our products	Our organization serves an off-the-shelf design system as a product - so it's a bit of an exception. Version control is becoming an increasingly large issue with our system. As we modify and push changes to the system, customers become out of sync since they're working off of duplicates. We're working on Figma plugin infrastructure to programmatically modify the D.S. to match a 'main' branch/version.
15	Our design systems moves slower than our products	A majority of the system is foundations/primitives, that rarely need to change. New components/patterns typically get built in product teams, and we keep a "shared components" Storybook for the product(s). Occasionally those move into the system. 9 times out of 10, newly built things aren't really truly reusable enough to be in the system, IMO.
16	Our design systems moves slower than our products	Our system moves slower, definitely, but we are involved in this trade off w/ product and engineering. Often times a highly visible new feature or workflow will incorporate a new design pattern/component. Ideally, that design will be vetted and incorporated into the system, with enough time for our DS engineers to build out the actual code. Often times, that doesn't end up happening. So there are many context dependent variations that result in something like: 1) Feature team builds out first pass of newly designed component 2) DS Designers review design, vet additional edge cases + align with rest of system 3) DS Engineers take finalized DS design + working version of component from feature team => builds out finalized component 4) Ideally: Feature team refactors to use new DS component
17	Our design systems moves slower than our products	Lots of meetings and encouragement
18	Our design systems moves slower than our products	I like the analogy that the systems team are the tortoises and products teams are the hares there primary goal is to move fast and the systems team is slow and steady, we play clean up, counselor and keep the guardrails strong For our organization, this has been healthy since we still in the early years of a mature system
19	Our design systems moves slower than our products	Because I am the only designer, I'm forced to spend the majority of my time designing new things rather than creating a good design system.
20	Our design system moves the same speed as our products	We prioritize changes that have an immediate need
21	Still in implementation of v1 so I’ll let you know.	The product vs program resonates, thinking about management support and where design system sits in our org / which stake holders feel like they have a bigger stake based on proximity. Not to mention the long term vision that I suspect could play out more holistically if approached as a program.
22	Our design systems moves slower than our products	On the 4 enterprise systems I've been a part of we've: • focussed on the highest value deliveries, sometimes building assets such as patterns, which will need to be updated upon core component updates (taking into account the tech cost) • ensured value of what is being built is clearly communicated and actively supported in integration, especially early in the adoption process
23	Our design systems moves slower than our products	I've seen first hand how speed can be the most toxic experience for design systems teams. As a general rule, design systems should be informed by, but not have decisions made by, product folks. Design systems should be aware of product roadmaps, as it behooves systems teams to attach their work to active product work, for a number of reasons. The danger comes when product folks in leadership positions start mandating decisions for the systems team. It's not their fault, product folks only know the speed of product, so we as systems practitioners have to educate them on how our moving slower will help them speed up, and through that lens ask them to take a step back with decision making for the systems team.
24	Our design systems moves slower than our products	Negotiations towards alignment and strategic ways to integrate feedback loops into workstreams
25	Our design systems moves slower than our products	The last system I was on we were upgrading to a new major version. We had to take a step back and work on our foundations. The goal was to build out our tokens and basic components and then work our way back up to the larger ones.
26	Our design systems moves slower than our products	At Meta, when we have been building on products that already exist, we have a hard time keeping up with feature development within the half. We can however plan ahead and work with you on custom solutions if it's built into our roadmap, so we are slower when we come up with reactive solutions. In the event we need to jam on something reactive, we can provide faster design solutions and partner with the feature team designers and engineers to implement utilizing their eng resources.
27	Our design systems moves slower than our products	There are some fundamental pieces in the product and design system is one of them. Nobody expects the core architecture to move fast, it mast be stable and have phases of refactoring from time to time to keep up with the times
28	Our design systems moves slower than our products	It doesn't play out particularly successfully! Generally speaking, teams are always going to want components faster than we can make them, so they will have to 'roll their own' with the expectation that they should swap this out for ours later down the line. This is easier said than done. We're trying to put in place a system of shared and local libraries, to at least get visibility of the chain of custody and identify when a component, updated feature etc is out of date and needs replacing. But this is slow going to get established, so too soon to tell.
29	Our design systems moves slower than our products	In my Organisation mostly design system changes and other systems are aligned voluntarly by all UI designers out thus not able match it with current development speed.I am looking to get a buy in with my stakeholders to allow me to invest seprate time on the design system to bring it on same pace of the developement
30	Our design systems moves slower than our products	Multiple uncoordinated or aligned mini systems in play. None cater for all. We are consolidating these now as 'a strategic product' for the organization, but struggle to get the funding and resources to do this. While the theory of the advantages of one design system is understood and accepted, the mental model is still that this is a design tool thing, and not a product and workflow that allows all other products to deliver. The struggle is real.
31	Our design systems moves slower than our products	We continue to take in new information from product teams about how they use the system. We meet regularly to decide how to best incorporate that information.
32	Havent built it yet.	we're hoping to release in sprints to ensure we can keep up with the pace of new app development
33	Our design systems moves slower than our products	We can't keep up with the demand and the enhancements to components, so we've created contribution model and light governance for a shared community space we call "Commons", both for designers and developers. We are still in the process of standing it up, but feel good about it's adoption.
34	Our design systems moves slower than our products	It normally means that product teams take it on themselves to build what they need at the time rather than using the system, creating a disjointed customer journey. Creating their own system or overriding ours, normally means issues for them updating down the road.
35	Our design systems moves slower than our products	Its been a bit hard to keep up as changes to the products often necessitate changes to the system but then the system is not given the time to properly update across all verticals. To address we've been limiting changes to the system as a whole and focusing more on general foundational elements - or from an article i just read, the "durable" components - those which can be used in all verticals, but don't / can't change easily and w.out a larger discussion of why and how the change would benefit the system as a whole.
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