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 24, deep dive hosted on July 11, 2024 with Ben Callahan and Edward Liu. There are 32 answers. The question this week was: ----- Edward and I were chatting this past week about how much impact the context of a specific organization has on the “right” approach to their design system work. I’ve felt this tension for a long time—each system my team and I have built has been unique. This is largely due to the fact that each organization we’ve built those systems for has been unique. One big takeaway from this recognition is that what works for one design system team may not work for another. This week, we’d like to try and quantify and understand potential correlations. To do so, we’ve chosen areas for you to identify about your organization which will help us plot your context. Let’s dive in! Area 1: Product Maturity The premise here is that digital product companies operate on a scale from “startup” to “enterprise”. Of course, not all products fit one of the two, but our theory is that an organization with a startup mindset will have a very different set of concerns (“fail fast”) than one with an enterprise mindset (risk averse). Area 2: Design Maturity Invision (now out of business) developed a design maturity spectrum which plotted organizations into one of five stages: - Producers (41%): design is what happens on the screen - Connectors (21%): design is what happens in a workshop - Architects (21%): design is a standardized scalable process - Scientists (12%): design is a hypothesis and an experiment - Visionaries (5%): design is business strategy Area 3: Design System Maturity I’ve worked for a few years now to articulate a maturity model for design systems. In my research, I’ve identified four primary stages of design system maturity: - Stage 1 is Building Version One: everything that happens before the system is consumable by your subscribers - Stage 2 is Growing Adoption: making the system easy and obvious to adopt (begins as soon as your release version one) - Stage 3 is Surviving the Teenage Years: building a product team and mindset (begins with an mindset shift of the design system team, from focused on adoption to focused on other challenges) - Stage 4 is Evolving a Healthy Program: proactive maturity into stable leadership (begins with a mindset shift of the organization, seeing the design system team as an influential leader in the organization) By understanding where folks fit into these three areas, we’re hoping to gather some compelling insights. With all of this as context, here is The Question for this week: Where does your organization sit on the product maturity scale? Where does your organization sit on the design maturity scale? Where does your design system sit on the design system maturity model? In considering these three areas, what are some insights you can share about your approach to design systems? | |||||||||||||||||||||||||
2 | Question 1: Where does your organization sit on the product maturity scale? | Question 2: Where does your organization sit on the design maturity scale? | Question 3: Where does your design system sit on the design system maturity model? | Question 4: In considering these three areas, what are some insights you can share about your approach to design systems? | ||||||||||||||||||||||
3 | We operate somewhere between a startup and an enterprise mindset | Producer: design is what happens on the screen | Stage 3: Surviving the Teenage Years | I realized that the maturity of your leadership in terms of design often clashes with the maturity of your design system team, especially when the culture of your organization is not aligned in values. To make things worst when the maturity of your designers is low (when it comes to UX and design systems) it is very hard for a design system team to work on standardization and reusability (because the focus is what happens on screen). It seems in this case that only a reorg of the company and a more design oriented manager (rather than business oriented one) can shape things up the right way. | ||||||||||||||||||||||
4 | We operate somewhere between a startup and an enterprise mindset | Connector: design is what happens in a workshop | Stage 1: Building Version One | just started a new role, and adjusting to the change and trying to work out whats what. Which is a challenge in itself. | ||||||||||||||||||||||
5 | We operate with an enterprise mindset | Architect: design is a standardized scalable process | Stage 4: Evolving a Healthy Program | Please note that my insight about my approach is not directly correlated to these 3 areas but is something that exists all across the 3 and morphs in scope based on the 3. I've seen multiple approaches work, I've seen multiple approaches fail at multiple maturity scales levels. The biggest issue is always lack of communication and decisiveness - which can, at any stage - make a design system crash and burn. My personal approach is to try and create/grow/evolve a system while always mitigating outcomes which introduces cracks in the system. The approach to do it varies according to the maturity levels and models. As I've seen, a design system is something which is always under strain, and any crack can and will widen into a schism which can and will break the system eventually. In more practical terms - with each scenario where the system meets a requirement that can be divisive, we have three options: 1. Go to the root of the requirement and eradicate the requirement itself. 2. Go to the root of the requirement and transform it such that it is not divisive to the system anymore. 3. Evolve the system such that the requirement fits into the system without creating a crack. Which of these 3 is feasible, expedient and sustainable - depends on the maturity of your system and product, and one might construct a complex decision matrix - but overall my approach is to not deviate from these 3 outcomes as it often becomes the wrench in the cog which breaks the system. | ||||||||||||||||||||||
6 | We operate with an enterprise mindset | Producer: design is what happens on the screen | Stage 3: Surviving the Teenage Years | Another way to describe our Enterprise mindset would be "Fail slowly" In terms of our DS maturity, I chose "Stage 3: Surviving the Teenage Years" but it would be more accurate to say that we are metamorphosing into a new iteration: Single brand, to theme-able multi-brand support. It's hard to comment on "Where does your organization sit on the design maturity scale?" as I'm basing this on my outsider interpretation of how other teams work, and also it may be a mix of these things in each product area, or between them, and I'm also doing a lot of interpretation. So, my answer here is low confidence. | ||||||||||||||||||||||
7 | We operate with an enterprise mindset | Architect: design is a standardized scalable process | These are very helpful in aligning primary needs and classification but are most often applied in parallel, with emphasis and resources placed toward the 'stage' where they are most needed and based on opportunity or constraint. For example, building 1,2 & 4 can all happen at the same time when a high-value (or high-value improvement) are implemented. | Aligning the system to a) user, organizational and business needs b) the existing and developing skillsets within an organization and c) changing opportunities and constraints (esp in regards to technology) has been very helpful | ||||||||||||||||||||||
8 | We operate with an enterprise mindset | Producer: design is what happens on the screen | Stage 2: Growing Adoption | We live between a number of categories, which can cause challenges in prioritization. We are tasked with adoption numbers and NPS scores, but we have not completed a real Version One (with code). There have been previous iterations of the system and other systems, but for this true Enterprise efforts, we have not gotten a full set out in native or web, yet are constantly pushed for adoption and contributions. So, for a stretched-thin team, where do we focus our time? Across the org there are different views on what Design does. Our team is understaffed across the board, so many of our designers lean into product roles, which is OK, except that is fewer folks delivering component designs. We have new design leadership that wants to work like a startup, but our org being in the financial industry is extremely risk averse. So, there is a tug and pull to move faster, but adhere to all the risk processes and protocols....fast or slow. | ||||||||||||||||||||||
9 | We operate with an enterprise mindset | Connector: design is what happens in a workshop | Stage 1: Building Version One | Answering many of the questions about architecture have been hard considering there are so many options to sort through. | ||||||||||||||||||||||
10 | We operate with an enterprise mindset | Architect: design is a standardized scalable process | Stage 2: Growing Adoption | Perception is key for us - we're driving home the message that the DS is critical infrastructure. We're aligning that with ways of thinking we know would make sense to the enterprise. We stopped saying the DS is a new culture of working/thinking about products, and instead focus on acceleration and accessibility compliance. | ||||||||||||||||||||||
11 | We operate with a startup mindset | Visionary: design is a business strategy | Stage 1: Building Version One | As always, the design system should come from the use cases in the application. At my former company (a very large software company with multiple design systems) there was always a want from management to have a design system in place before knowing what the usage patterns would be. This approach will not work. | ||||||||||||||||||||||
12 | PRODUCT MATURITY: Supposing startup/enterprise is a spectrum of acceptable risk (high/low). In that case, I believe we bypassed this by a senior leadership mandate of adopting a design system made internally in the parent organization. Therefore, our dynamic was Dow Jones was the client of a Design System made by NewsKit (an independent BU of NewsCorp) where NewsKit was the Vendor. | Architect: design is a standardized scalable process | Stage 3: Surviving the Teenage Years | We were fortunate to have both a strong executive mandate and an 'off-the-shelf' internal Design System solution with a team of designer/engineers we could call on for help. Imagine adopting Material Design but you could Slack one of the programmers to answer any question. A big help. The dynamic between Dow Jones and NewsKit resembled that of a client/vender. Now that NewsKit has disbanded, it's apparent they were and invaluable set of training-wheels. This dynamic also had a unique advantage for the Dow Jones UDS team. Because we did not have an emotional attachment to NewsKit Design System, we were free to NOT LIKE the system. The challenge was to understand WHY we didn't like X, Y, or Z so we could improve. Often we discovered a foundational oversight by NewsKit architecture. Other times, there were fundamental principles that were insanely smart but non-obvious and difficult to communicate. For a new team, I highly recommend client/vender approach by adopting a pre-made system (not build it from scratch). But, also challenge the system and find ways to improve it. Lastly, it seems to me rebuilding design systems for individual companies is darned inefficient and unneccissary. If we only scope to 'The Universal Design System', and define what properties it should have (TBD), we can provide one design system. The individual consumers may adjust as they feel best. | ||||||||||||||||||||||
13 | We operate with a startup mindset | Connector: design is what happens in a workshop | Stage 2: Growing Adoption | Our process is disjointed. We have products that are a couple of years old, that came about BEFORE a design system. v1 of the system was created in 2018-2019, and everyone tried to retrofit the products to use the system, but it was never fully matched in code now we are 99% finished with v2 of the design system, which is a much more mature version, but we are trying to implement it while also switching platforms, outdated AEM to the newest AEM. We are looking at different maturity models for different elements. The UX team has fully embraced the design system, BUT since waiting for the platform shift is a major blocker for enterprise adoption. | ||||||||||||||||||||||
14 | We operate with an enterprise mindset | Architect: design is a standardized scalable process | Stage 4: Evolving a Healthy Program | Something that we have found that is important for the design system to move from one stage to another the maturity process is that it requires two important influences: 1. Trust - users need to feel confident that the system will quickly solve their problems 2. Management buy-in - without management understanding the value of and guiding products toward the design system, it can be very difficult to get teams to diverge from what they are already comfortable with. | ||||||||||||||||||||||
15 | We operate with an enterprise mindset | Connector: design is what happens in a workshop | Stage 1: Building Version One | We're marginally better than our org, but it is somewhat of an upper limit on what we can achieve. That means the design team must consider the wider culture of the org and how it must eventually be pushed/changed. | ||||||||||||||||||||||
16 | We operate with a startup mindset | Producer: design is what happens on the screen | Stage 1: Building Version One | Maturity is so important. In the beginning (or if restarting a design system program), -someone- thought the design system was a good idea but not -all- people may care. Often in the smaller organizations, every day is a struggle so the design system must enhance productivity but clearly "get out of the way". I would focus on vibes and simple rules so feature development feels like it fits the same style. Over time, as the design system becomes a way of doing things, then it is about refinement of roles and responsibilities. We must ensure that the integrity of the design system is upheld. This is the tipping point where building a dedicated design system team many roles on it works well. I would focus on building processes and checkpoints, especially around QA. Good DX helps the system build out faster. But then there's the point where 3rd parties are adopting the design system and even "rogue departments" should adopt. Now, documentation and templates take the forefront. Here people believe the design system Is The Way and just want it to save time and effort. I would focus on training, docs, roadshows, and a champions program. I'd also start paring back any unnecessary components and make the "Core" of the design system strong with a "Labs" or an "Alpha" program for upcoming components/tokens/patterns/etc. | ||||||||||||||||||||||
17 | We operate with a startup mindset | Scientist: design is a hypothesis and an experiment | Stage 4: Evolving a Healthy Program | Conversely to what might be expected, it's my experience that having a move-fast, experiment-friendly startup mindset has helped our design system be heavily adopted and considered a critical part of our work. Instead of feeling like the DS has to be complete and separate, and then sold to the team, it started more grassroots, and devs adopted it because it used MUI, making it quick and easy to use. Now, adoption isn't a problem, and we can focus on more systemic efforts rather than selling. We know that components can come and go, and change, and while I'd say the DS is a fairly stable set of foundational components, "stability" isn't the primary concern. | ||||||||||||||||||||||
18 | We operate somewhere between a startup and an enterprise mindset | Architect: design is a standardized scalable process | Stage 2: Growing Adoption | One thing I'm noticing within my team's approach to design systems is that we're teetering between Stage 1 and Stage 2, I think because the business/leadership team is asking for us to get to stage 3 before we're ready. | ||||||||||||||||||||||
19 | We operate with an enterprise mindset | it is a mixed bag of mainly the first 4, then very little of 5th (from top to bottom of this list) | Stage 3: Surviving the Teenage Years | Even though we are enterprise, many in our org speaks in terms as if we were a startup, ignoring the organizational mammoth we need to move to operate like that. Currently we are good on execution of work but relative to how we do things now. This doesn't help to do things better because that means something different than how we do it know. This evolutionary type of work is very hard for large organizations to solve for because change happens very slow. This is also something we are dealing with our design system. We are currently dealing with many people assuming that it will elevate the quality of our designs > products... but that needs to be designed first, then we can systemize it | ||||||||||||||||||||||
20 | We operate with an enterprise mindset | Architect: design is a standardized scalable process | Stage 2: Growing Adoption | I think for maturity, there's potential to view them more as pillars than as stages, and plan your focus along what pillar you would like to grow maturity. | ||||||||||||||||||||||
21 | We operate somewhere between a startup and an enterprise mindset | Scientist: design is a hypothesis and an experiment | Stage 3: Surviving the Teenage Years | For a company with many products that don't have any consistency, build the design system for the first 3 prioritized products to adopt, then the others will follow. | ||||||||||||||||||||||
22 | We operate somewhere between a startup and an enterprise mindset | Architect: design is a standardized scalable process | Stage 1: Building Version One | My approach is that collaboration is key and communication is everything! :) I recently joined a new organization (just 1 month in), and my role in design systems is new for the company as well. | ||||||||||||||||||||||
23 | We operate with an enterprise mindset | Visionary: design is a business strategy | Stage 4: Evolving a Healthy Program | Because I primarily focus on the design tokens for our design system, I see our organization as being in the "Architect" category. Still, to the broader organization, we would probably appear to be "Visionary." The maturity scale categorization feels particularly relative to the individual's point of view and level of interaction with the design system. | ||||||||||||||||||||||
24 | We operate with an enterprise mindset | Producer: design is what happens on the screen | Began building a design system and it was stopped at the turn of the new year. | Buy in from existing developers is crucial. Without it there is no chance the design system will see production code. | ||||||||||||||||||||||
25 | We operate somewhere between a startup and an enterprise mindset | Visionary: design is a business strategy | Stage 3: Surviving the Teenage Years | Is it possible to have a well-functioning design system without a design system team, but only with a product team? | ||||||||||||||||||||||
26 | We operate somewhere between a startup and an enterprise mindset | Producer: design is what happens on the screen | Stage 3: Surviving the Teenage Years | Surround yourself with people and design system consumers that provide candid and balanced perspective. Be honest and transparent about the state of the system. Always be learning. | ||||||||||||||||||||||
27 | We operate with an enterprise mindset | Scientist: design is a hypothesis and an experiment | Stage 3: Surviving the Teenage Years | Working as a consultant, we encounter a lot of different organizations and departments within that want to be separate. While we would love to always recommend and spin up a design system, in many cases it's not sustainable. We start with repeatable, accessible patterns (design and dev). When there is commitment to consistent usage, guidelines and governance, we can start building out a design system with a team or v-team to add, improve and support it. The two biggest challenges we face are what happens when the design system isn't supported after the product is live or every department wanting their own design system because they have "unique design and development needs." The best success has come from executive leadership driving the required usage and teams collectively contributing to improving it. | ||||||||||||||||||||||
28 | We operate somewhere between a startup and an enterprise mindset | Connector: design is what happens in a workshop | Stage 3: Surviving the Teenage Years | - | ||||||||||||||||||||||
29 | We operate somewhere between a startup and an enterprise mindset | Producer: design is what happens on the screen | Stage 1: Building Version One | This might be non-sense but it's a realisation from a few years back: How you manage and organise work (agile, waterfall, anything in between) can vary depending on the organisation's maturity and a combination of the other (design and design system). For instance, for an enterprise mindset, there's no point in doing "agile" because you just want enterprise-grade quality for a set of boring components. | ||||||||||||||||||||||
30 | We operate somewhere between a startup and an enterprise mindset | Producer: design is what happens on the screen | Stage 1: Building Version One | In our current state, you really have to be passionate about design systems. People will question it, and some might even talk down about it. But if you believe what you're doing is making an impact, you keep going. Stay open to failure, and be ready to own it when it happens. Accept that everyone will have their own opinions about the team and how the product should be done. You'll find yourself repeating the message over and over again because not everyone will listen or understand right away. Don’t let that bother you—just keep moving forward. Keep doing what you're doing because some people will want it, and some will continue to do their own thing. | ||||||||||||||||||||||
31 | We operate with a startup mindset | Visionary: design is a business strategy | Stage 2: Growing Adoption | In a startup environment design systems can be hard to get buy in from management as it can be seen as time that could be spent elsewhere. I am a PM who loves design systems and know that they ensure best practise and consistency in the future, so I always do my best to sell the benefits to management. | ||||||||||||||||||||||
32 | We operate with a startup mindset | Architect: design is a standardized scalable process | Stage 1: Building Version One | When organizations are in their early days, design systems can seem daunting. It's common for version 1 to use an off-the-shelf component library to speed things up. This generally comes from product folks who are acclimated to the speed of product and unfamiliar with pace layers and how design systems move slower. It makes me want to pause, consider how to best approach communicating this to product folks, and go on a 6-month awareness campaign across the org. | ||||||||||||||||||||||
33 | We operate with an enterprise mindset | Connector: design is what happens in a workshop | Stage 1: Building Version One | I consider myself a design strategist. I’m bringing strategy to senior leadership from a design perspective. While my organizations design system may be at stage one, I believe that I can influence how quickly it gets adopted. I would say my biggest challenge with the design system is the team itself right now. They are worried that if too much of the organization adopts it at the same time that they won’t be able to support it. While I understand the hesitation, I am pushing for wider adoption now. There is a lot of momentum in the company for having a consistent experience for our customers and I’m using that business strategy to drive design system adoption. My question to the design system designers is why would you hesitate to allow teams to adopt the system? Weighing the benefits and risks of fast adoption. I believe that it’s better to allow it to run than to hold it back. | ||||||||||||||||||||||
34 | We operate somewhere between a startup and an enterprise mindset | Connector: design is what happens in a workshop | Stage 2: Growing Adoption | Different parts of the organization can be at a different maturity level both for how design operates, as well as how the design system operates. And that's ok. The harder part is, given these imbalances, how to describe the overall maturity for your company in order to measure & communicate about the team's work, quality, to get the appropriate resources at each stage. | ||||||||||||||||||||||
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 |