| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 38, deep dive hosted on November 14, 2024 with Ben Callahan and Marianne Ashton-Booth. There are 71 answers. The question this week was: ----- Hello curious people! Have you heard the saying, “The only constant in life is change?” In my experience, there’s quite a bit of truth to this idea. And, the same seems to be true of the organizations for which we work. In fact, according to a study by Accenture, the rate of change for businesses has risen 183% since 2019. Our organizations are feeling the pressure to change just to stay relevant, as indicated by this quote from the article linked above—“Incremental changes in ways of working and performance are no longer sufficient to compete.” In this landscape, how can a design system program both help an organization to align on a common way of working and support the need for the business to shift toward new ways of working? This is one of the many topics Marianne and I have been considering this week, and it’s the seed for Episode 38 of The Question! This week we want to dig into the approaches design system teams can take to both pivot alongside the business and stick up for ways of working that still hold value. Let’s get to it! Has the company where you work had a major change of some kind in the last 12 months? Have you experienced the failure of a design system because it couldn’t adapt to a major shift in the organization? What strategies have you seen work to make sure a design system can pivot as the business needs it to? | |||||||||||||||||||||||||
2 | Question 1: Has the company where you work had a major change of some kind in the last 12 months? | Question 2: Have you experienced the failure of a design system because it couldn’t adapt to a major shift in the organization? | Question 3: What strategies have you seen work to make sure a design system can pivot as the business needs it to? | |||||||||||||||||||||||
3 | We'll have a major change in 2025 | No | Reassess the flexibility model | |||||||||||||||||||||||
4 | Yes | Not failure, more like some serious hurdles | Communication more than anything tactical | |||||||||||||||||||||||
5 | Yes | Yes | Keeping the (technical) dependencies of design systems as minimal as possible so that it is more flexible to changeable stacks and frameworks, and so that it is possible to adapt and migrate quickly when needed. The changes that are most damaging in my experience are always people based, for example when businesses fail to see the value in delivery and project management staff as a whole they tend to be removed from DS teams very quickly. This is difficult to recover from as the practitioners on the team then need to try and plug gaps that they're often unsuited to, aren't involved in, and that are extremely time consuming when trying to create the system at the same time. | |||||||||||||||||||||||
6 | Yes | No | Don't take anything for granted; exec support for your entire team is just one resignation away from evaporating unless you build a broad base of supporters beyond the exec who currently supports you | |||||||||||||||||||||||
7 | Yes | Yes | Pay more attention to the system and system logic itself: when planning the design system, it should be planned in a way that its modular (new branding? color design tokens!, new product line? great, if have a modularized token and compononent library already, since you can quickly create any app or service concepts based on that and the branding). So when planning the logic, naming, component structure itself, we should always take into consideration that the business is changing. But generic UX concepts will not change so frequently (cognitive human functions) so we can detach these layers. | |||||||||||||||||||||||
8 | Yes | Yes | I want to say ruthless prioritization and close alignment with the business, but even then we always seem to be too slow. Perhaps its about being more pragmatic - advising teams how they can build what they need right now, even if it's not 100% with the system? | |||||||||||||||||||||||
9 | Yes | However, there is management a perception the DS needs to be more flexible. | Haven't seen one. However, I suspect we need to set expectations better. | |||||||||||||||||||||||
10 | No | Yes | Continuous testing of new assets, tools and strategies (esp GenAi) | |||||||||||||||||||||||
11 | focus to what components are needed more in the coming months | |||||||||||||||||||||||||
12 | Yes | Yes | I wouldn't say that the design system couldn't adapt to a major shift. More that, as a result of some major shifts, the design system lacked clear guidance from executives and leadership. The company structure is complex with multiple, disjointed teams. There's a parent company that owns our company after a merger. Different teams use different frontend frameworks (Vue3, React) and different visual designs. Without leadership spearheading an effort to unify these, it's very challenging for a design system to create a cohesive UI/UX. We're still waiting for the dust to settle after several staffing changes at the executive level. Which strategies have I seen work? I've only seen a design system succeed when everyone was aligned and on board. If the company pivots, leadership needs to facilitate alignment between feature teams and the design system. | |||||||||||||||||||||||
13 | Yes | No | Keep business logic out of the design system | |||||||||||||||||||||||
14 | No | No | When the company made a strong pivot to AI (like everyone else), we connected with the team building those interfaces, to make sure we either provide them with existing components they can use, or partner with them so the new features can be standardized into the DS later. | |||||||||||||||||||||||
15 | Yes | No | I'm not sure it's a strategy as much as it is a state of mind - be flexible and willing to pivot. Working for a retail company, things move quickly and priorities can shift without much notice. We have to be willing to continue to serve our consumers and the needs of the business whatever comes our way. I anchor back to looking at things from a macro level and what will benefit the company. | |||||||||||||||||||||||
16 | Yes | Not yet…it’s a looming fear though. 😅 | - DS team being looped in to upper leadership plans early so that we can also strategize on identifying DS gaps that may hold us up and setting up the DS to be nimble enough to support big changes across the org BEFORE they come. - For multi brand design systems, aligning DS roadmap to platform roadmap across brands so that DS can be prepared to make improvements as needed to support pivots and changes across products as they arise. - Tokens & theming!!! Such a lifesaver when the business pivots in a big way! | |||||||||||||||||||||||
17 | No | Yes | I would love to hear some. | |||||||||||||||||||||||
18 | Yes | It didn't fail/stop but it was deprioritised due to major shifts and a business refocus. | • Getting the design system to lean into and understand what changes the business is making, so to reprioritise the design system to work with the org rather than against the tide. • Forward think and plan ahead to mitigate potential challenges the business might have. • Make more rational choices about the scope and compliance that the system users should maintain whilst pivoting i.e adopt a flexible mindset and approach... Change is not really a time to police or hit hard with design system rules • If you have a large DS team (can also work with small teams), sometimes embedding within cross functional squads can help with speed and pace. • Find out as much as you can as early as possible, if you can't get that seat at the table then figure out another way to get the information needed to understand business priorities. • Measure what matters! | |||||||||||||||||||||||
19 | Currently only contracting. | Yes, sort of. I have witnessed designers and engineers walking away from the design system because it didn't fit their current needs and/or they just couldn't wait. | Let people create any number of new components and variants! BUT, make sure they disclose what they've been up to so you can track it. Then, later on, guide those design and code changes back into the main system (if it's worthy). Let's normalize it's OK to have "non-standard" components until the components prove they are useful to other teams. | |||||||||||||||||||||||
20 | Yes | I work in an agency, so not firsthand experience. but some companies come in because the design system has been left behind by changes | If the design system is mature it needs to be a philosophy and practice spread throughout the company, in particolar design and developement need to be align, this way the change is faster on all parts. Otherwise the practice needs to be spread starting from small projects, and once the business sees the result it can be implement in other project an so on. | |||||||||||||||||||||||
21 | Yes | Yes | We have faced 3 leadership changes, the time we couldn't convince leadership to invest in maintaining the DS, it failed. The other times we managed to convince them, it survived, and in one case, thrived. | |||||||||||||||||||||||
22 | No | No | Companies will always need to change and shift, so the DS team should plan ahead for this. This requires good relationships with teams looking forward. The best case Ive seen is when a DS leader is in the conversations that design/product executives are exploring a new direction. When integrated into exploratory work, the DS team shouldn't be enforcing systems at that stage, they should add value to the concepts and demonstrate how they can be a partner on vision work. Then later when/if that concept becomes real the DS team already knows it and can quickly apply it to a next version of the system. | |||||||||||||||||||||||
23 | Yes | No | Our org has seen a lot of change recently—multiple back-to-back reorgs, new domains created, some of those new domains merged, leadership shifted around, etc. Our goal with the DS team roadmap each half is to support the current business needs, but remain broadly systems-focused, attempting to stay focused on the needs of the system users who support a dynamic business, with shifting business needs. We've found success in listening to our designers and engineers, understanding their broader needs, not focusing on a single feature or initiative. At the end of the day, the design system provides consistency and a sense of solid footing during uncertain times. That said, we have had to shift priorities and roadmap items to match business needs. We have also been pulled into certain product initiatives, either as a whole team, or as individuals, to support specific top-down product initiatives, and temporarily pause DS work. One of the areas we've found success is by relying on our bi-annual sentiment survey to gauge impact to the business, reflecting the sentiment of designers and engineers who are using Pedal, our design system at Turo. We have three main questions we call "Pedal Impact Indicators" that help us communicate the value of the systems work we do back to execs (thankfully they've had good sentiment scores): 1: Pedal components, tokens, tooling and documentation allow me to deliver a better experience to Turo customers. (94% favorable sentiment) 2. Pedal makes me more efficient when building the Turo product.(88% favorable sentiment) 3: Pedal streamlines collaboration across Turo product development. (88% favorable sentiment) The survey more broadly, but these Pedal Impact Indicators specifically, have given us much more coverage when making the case that we should stay systems-focused to execs. The product development teams will be better able to focus on impacting those elevated metrics, even as the org, teams, and elevated metrics change. | |||||||||||||||||||||||
24 | Yes | Yes | I'm relatively new in my design system tenure so I can't speak much to my experiences, however, my organization's design system is currently experiencing a business need shift that will require messaging pivots from the ds. Our design system has just been released, however, with organizational changes, our message has shifted from "let's migrate as soon as possible" to "migrate on a timeline that works for you, whether that means migrating in parts or later on". Basically ensuring that we are working collaboratively with designers while migration is no longer the #1 priority for design teams. | |||||||||||||||||||||||
25 | Yes | Yes | I think the thing I’ve seen work the most is having branches of the design system so that it isn’t so massive trying to meet the needs of an ever expanding business. For example, in some companies these might be application branches but in my current company this will be a portfolio level branch. I tend to think branches happen depending on the amount of users it is trying to serve. | |||||||||||||||||||||||
26 | Yes | No | Matching our team's OKRs and goals to the company's overall OKRs, business goals, design standards of the industry as well as DS survey results we get from sentiment surveys. | |||||||||||||||||||||||
27 | Yes | Not yet, but we are trying to adapt to avoid this | Looking for key strategic initiatives to partner with and enable, limiting unnecessary components (e.g. try to limit maintenance overhead that can slow down a system tram, continue refining the broadly reusable atomic parts. | |||||||||||||||||||||||
28 | Yes | No | We've been very lucky to be 'correctly under-resourced' since our team formed 3 years ago. We think our team is too small to adequately support the size of our current organization (we're biased), but we've had dedicated, full-time engineering and design coverage for iOS, Android and Web since day one. The team has the same number of engineers today (one per platform) but we now have 2 designers (up from one at the start). The campany has grown from a headcount of 200 to over 1000 since we formed. Luckily, we were resourced to well enough to be able to consider all platforms' Figma and coded components together from the start. We always ask 'will this scale' for every decision we make. We started with components that were highly opinionated and offered only configuration. We're now introducing components that follow a composable model to give teams more flexibility and design control while still providing system structure. Teams can now generate complex components by remixing our composables, letting them flex with product domain needs. Our scale challenge now is helping product teams skill up to manage and maintain these components so we don't become a bottleneck. We're moving beyond just delivering kit-of-parts. We're looking to build an advocate network that can help domain product teams self manage the system parts they own. We're very picky about what we put in the core Design System — only broadly useful, stable elements make it in. Everything else lives in other layers owned by product teams. | |||||||||||||||||||||||
29 | Yes | No | Supporting teams through migration process | |||||||||||||||||||||||
30 | Yes | The failure came from the lack of understanding leadership had about how the DS could support the organisation through the changes. | A proactive approach to go after where the DS could make the most impact. Reaching out to different product teams beyond design level. Go nurture relationships with PMs, Engineers and practice leads, etc. | |||||||||||||||||||||||
31 | No | No | Constantly partnering with teams is vital. We're always looking to provide assets to support upcoming team initiatives. This gives us an excuse to build our library of assets and gives us visibility (hopefully) to the company when the initiative successfully launches. One of the biggest things I've learned in my career recently is that your design system has its unique way of working—one size doesn't fit all in the design system world. You have to have the mindset of exploring and trying things out—even if they aren't best practices according to the DS community—if they empower the company you work for. | |||||||||||||||||||||||
32 | Yes | No | Build a really flexible system that prioritizes building blocks as opposed to very complex components that meet different product team's needs | |||||||||||||||||||||||
33 | No | No | Not sure, but as someone who admittedly is resistant to change, I'd love to hear what strategies might work in the future | |||||||||||||||||||||||
34 | Yes | Yes | Being adaptive and understand that things take time. People are understanding, there doesn’t need to be an explanation or an immediate answer for things. Sometimes the best route is to listen to the users of the design system and see their recommendation on how to progress through the bug change. | |||||||||||||||||||||||
35 | I am too new to my company, but this is of interest to me. | No | I have none. | |||||||||||||||||||||||
36 | I don’t think of anything as a major change but rather constant small changes and evolution. Acquisitions, reorganization of teams, adding new products etc. so…yes and no ;) | No | We have 2 design systems that have been successful within their product teams but have not been able to reach full enterprise scale. The bet we are taking is on web components so we aren’t locked into a framework. Also, on themeable tokens. TBD… | |||||||||||||||||||||||
37 | Yes | No | Having a strong foundation – both at the component level as well as from a governance perspective – is essential while keeping your ears to the ground to capture and act on any feedback you receive from users. Measure the impact of the system not just from a component usage perspective, but also in terms of how efficiency has increased due to workflow changes, for example. Lastly, design system work can often go under the radar, so keep banging the drum for your design system across the company, spreading the word about all the great work you and your team have been doing, and building relationships with cross-functional partners. | |||||||||||||||||||||||
38 | Yes | No | Redesign/rework of the Design System to support the rebranding. As nothing was develloped and the Design System was more a UI Kit, the pivot was easier | |||||||||||||||||||||||
39 | Yes | Yes | We've had to really define what we own and what we do not and ensure teams understand this. It's a WIP. But essentially stick to our guns and process for the DS on a core set of components that are used globally across multiple platforms & those across a single platform and moved out the way as much as possible for product or domain specific components which teams need to move fast on. We provide guidance and recommendations in this space but don't block progress f stringent DS standards are not fully upheld. The tricky part for us as a DS team is facing into this change as it means owning less and coaching more. This has led to some concern within the team of their roles remaining relevant in the long term which I feel simply needs to be seen through a longer term lense. Coaches and mentors and enablers are needed no matter how often a business is changing, in fact they are probably needed MORE the more an faster a business is changing to provide some stability and strong foundation upon which to pivot. | |||||||||||||||||||||||
40 | No | Design system is new, and not released yet. | N/A | |||||||||||||||||||||||
41 | Yes | No | Always leave breathing room in your design system. Make adaptability a significant pillar, principle and definition for execution. | |||||||||||||||||||||||
42 | No | No | Gff | |||||||||||||||||||||||
43 | I just joined my current job one month ago, but the answer to that for my previous position is YES | No | getting the research right and asking stakeholders the right questions in advance | |||||||||||||||||||||||
44 | Yes | No | Multi-framework code offerings; adoption of web components and design tokens; adaptive governance frameworks; establishing champions and advocates in teams (for decentralized organizations). | |||||||||||||||||||||||
45 | Yes | No | Not sure | |||||||||||||||||||||||
46 | Yes | Yes | We had a team dedicated to building development components, and they were full steam ahead—launching over 40 web components in no time. But here’s the kicker: almost all the teams across the company rejected it. I grabbed the Design System Product Owner and got into the weeds with interviews, talking to different teams across the company. Surveys backed us up, and we realized something crucial: most people were used to working in C++ and were already transitioning to C# and Blazor. Adding a whole new layer of web components felt like one hurdle too many. What did I take from this? Start with solid foundations that support a broad audience first—keeping things more universal. Then bring in the specifics, like tokens and development components, without overwhelming the teams. That’s the best way I’ve seen to keep a design system nimble and useful as the business shifts. | |||||||||||||||||||||||
47 | Yes | Yes | I work for a struggling late-stage startup that has let go of approximately 1/3 of the engineering team in the last year. Contributing to and maintaining the design system was pushed to the side as the need for a leaner team to push out new features took priority. I'm looking forward to joining The Question this week to learn how others prioritize and pivot, rather than abolish their design system when there's a disruption within the organization. | |||||||||||||||||||||||
48 | Yes | I don't think I would call it a failure. The design system has to learn and grow too. It may have shortcomings for a season, but not a failure. | Focus on abstraction and things that scale. Realize that not everything belongs in the system. Guidance is just as important as parts. | |||||||||||||||||||||||
49 | Yes | Yes | All the obvious things like scalable architecture, naming conventions and patterns that allow for change you anticipate and hopefully some of what you don't. But what i've found to be most helpful and productive in times of change has been cross-functional relationship management, keeping lines of communication open and work visible, and honestly a fluid positive attitude on "how we keep jamming, even though x...". Not championing toxic positivity or blowing smoke, but sitting where we sit, at the convergence of multiple disciplines and teams, ensuring that teams want to work with us and continue to use the system (or still exist in some cases 😬) is crucial. | |||||||||||||||||||||||
50 | No | No | More focus on communicating up | |||||||||||||||||||||||
51 | Yes | i wouldn't say failure...but we've seen the system pulled into particular work b/c of org changes (end up feeling more beholden to a particular platform than global needs) | i'm not sure i have...i'm excited to learn a lot on this one! | |||||||||||||||||||||||
52 | Yes | Yes | I created a spreadsheet called CHURN after 3 years at a prior employer because the rug kept getting pulled out from under the design systems team by decision makers outside our team. Everything from the core technology use to build components in code, design token tooling, design token naming, repos, docs site tools, showroom tool, etc was in a constant state of change and it was a waking nightmare. What strategy did I employ? Find a new employer. | |||||||||||||||||||||||
53 | No | No | I don't have experience in business pivots at the moment. | |||||||||||||||||||||||
54 | Yes | Yes | Not imposing the design processes onto the coding part of the system. Rather finding a common language and processes | |||||||||||||||||||||||
55 | Yes | Yes | Tight collaboration and communication with product and design leadership as well as the individual contributors doing the daily work. | |||||||||||||||||||||||
56 | Yes | Yes | Listen to your people. That should be the case from day one. It should be the case when you're standing a system up in the beginning, but also at every milestone along the way. Beyond that, be adaptable enough to take whatever comes your way and be able to implement it in a way that works for as many teams as possible. | |||||||||||||||||||||||
57 | Yes | Does it count if the "major shift" was a really bad idea, everyone knew it was a bad idea, was vocal about the bad idea, but the leaders pushed the idea through, regardless? | Remembering that we (design systems) are a TOOL for others; flexibility has to be built in the DNA (and I don't mean "yeah, we allow people to flexibly override the whole system"; I mean flexibility in how work is slated, scoped, prioritized, defended, and changed). Positioning the work stream as core infrastructure across design and engineering takes serious leadership buy in, but "buys" the air cover when change needs to happen! | |||||||||||||||||||||||
58 | No | No | Flexibility, the ability to be extended or themed. Tooling that can be federated. | |||||||||||||||||||||||
59 | Yes | The organization went through structure changes due to lack of revenue, and considered design system as a first place where the resources should be cut off. | Throughout my past experience, design system seemed to be taken into consideration by leadership whenever company thought about strengthening their brand or changing the visual language. Also would receive investment whenever engineering department or directly CPO advocated for that. Often design only advocacy was not enough. | |||||||||||||||||||||||
60 | Yes | No | Get as much lead time as possible when it comes to understanding the changes. Having more info up front allows the DS teams to prepare for pivots and even help with change management since DS teams can make sure other teams have support as needed. I dont see core teams like this involved enough in understanding business pivots before they roll out to the rest of an org and that makes it tough to get ahead of the curve. Dont make goals or OKRs so rigid that you cant adapt. The DS is meant to serve the business at the end of the day - if the business needs change, system people need to be okay with their work changing as well. | |||||||||||||||||||||||
61 | Yes | Yes | Continuous testing of adjustments, synchronous and asynchronous communication channels, and a culture that embraces change. | |||||||||||||||||||||||
62 | No | Not quite a failure of the whole system, but failing to discover in time that what was most important to leadership at the time was a visual evolution of the system versus the priorities we had set, which were more foundational in nature–take accessibility to the next level, develop a token set to increase adoptability by sub-brands, etc. Because of this, the design systems team was seen as "not wanting change" and "too slow". That wasn't necessarily fair, but it made us realize we had been heads-down too much, and hadn't been spending enough time communicating with our top-level stakeholders. | The whole premise of a design system is that it makes it easier and quicker to do major pivots! 1. Number one strategy: stay ahead of what is likely GOING to happen by having really close relationships with the people who make decisions about new product/features/any other big changes. That way you can come prepared once it actually happens. 2. Be open-minded about change, and you'll immediately be seen as more relevant. In our efforts to combat snowflakes, we can easily be seen as the people that "don't like change/don't want to innovate" 3. Reduce the complexity of your design system. The simpler it is, the easier to make major changes. 4. Haven't seen this yet personally, but with every company jumping on the AI bandwagon: stay up-to-date on new technologies and see how they could advance the DS. read articles, take courses, have discussions with experts, and become the expert. | |||||||||||||||||||||||
63 | Yes | It remains to be seen :) | In my role as design system lead, I make it part of my job to be informed about where priorities are shifting and prioritize design system work to support the new priorities. I do this by paying attention in town halls to the work being highlighted, attending leadership meetings/reading memos about prioritization even when it doesn't directly impact design system work, and asking questions about shifts in prioritization. | |||||||||||||||||||||||
64 | Yes | No | Flexibility | |||||||||||||||||||||||
65 | Yes | Not yet | That’s what I want to learn about | |||||||||||||||||||||||
66 | Yes | Yes | Make it more analogous to the organizational needs rather than to a specific project or edge case. Ideate against an unknown circumstance where the design system would not meet the needs of the moment and strategize what could be done in that scenario. | |||||||||||||||||||||||
67 | Yes | No | Being as slim and efficient in styling and component naming as possible. Having a nimble process of contributing from local components to the DS library | |||||||||||||||||||||||
68 | New to the company in the last 6 weeks. | Yes | Controlling scale, strong focus on internal user needs and training. | |||||||||||||||||||||||
69 | I'm a consultant | Yes | Relentless connection between design system "owners" and the product teams, with great support from leadership. However, I've also seen this burn out the design system folks--so even while it was effective, it wasn't sustainable. | |||||||||||||||||||||||
70 | Yes | We are in the process of building the org's first design system. | Be collaborative. Take interest in the users that are interested. Be empathetic and open-minded to how others in different teams, departments and even regions work. | |||||||||||||||||||||||
71 | Not sure yet! | The DS I used to work on became a federated model due to covid layoffs, politics, and restructuring. The system never advanced and reverted to using MUI due to engineering director preferences/lack of understand of design system’s value. | Communication | |||||||||||||||||||||||
72 | Yes | Yes | Collaboration | |||||||||||||||||||||||
73 | Yes | Not yet.. | Try to stay in sync with product roadmaps and build future-friendly foundations | |||||||||||||||||||||||
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 | ||||||||||||||||||||||||||