| 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 056, deep dive hosted on June 27, 2025 with Ben Callahan and Brad Frost. There are 103 answers. The question this week was: ----- Welcome to Episode 056 of The Question, with co host Brad Frost! As we were chatting last week about what to ask you all, Brad shared a bit about a kind of funny thing he’s seen happen. As design systems folks, we often think we’re building systems to make the products more consistent. The odd thing is, our organizations are trying to support a variety of digital products, many of which need to look different! When our expectations of the design system clash with consuming teams’ expectations, a lot can go wrong. Lucky for you and me, Brad wrote an article explaining the various dimensions of complexity we’re facing in design systems work today. This week, let’s talk about The Mulit-All-The-Things Organization and what to do about it! To start with, give this article a quick read. Then, answer the questions below to join The Question. Which of the dimensions of product/organizational diversity do you deal with regularly? • Checkboxes: • Multi-product • Multi-brand • Sub-brand • Rebrands, refreshes, & redesigns • White-labeling • Campaigns • Multiple product families (e.g. marketing site & web app) • Multiple color modes • Multi-framework • Multi-platform • Other How are you addressing this complexity? On a scale from “failure” to “success” how would you describe your attempt to address the complexity? | |||||||||||||||||||||||||
2 | Question 1: Which of the following dimensions of product/organizational diversity do you deal with regularly (check all that apply)? (If you’re unsure what these are, check out the article where Brad explains them in detail.) | Question 2: How are you addressing this organizational diversity? | Question 3: On a scale from “failure” to “success” how would you describe your attempts to address this organizational diversity? | |||||||||||||||||||||||
3 | Multi-framework,Multi-product,Multiple product families (e.g. marketing site & web app) | Web components is our answer to multi frameworks. For product families we have our core DS and a theme that targets the products (majority of needs), with a theme for marketing and a library of additional components. | 3 | |||||||||||||||||||||||
4 | Campaigns,Multi-framework,Multi-product,Multiple product families (e.g. marketing site & web app),Sub-brand | by having layer 2 product-specific component libraries handled by teams while having a core design system with core components used by many teams. | 3 | |||||||||||||||||||||||
5 | Multi-brand,Multi-platform,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,White-labeling | A multi-tiered structure (Figma) that feeds off into different product types. Brand 'primitive' files that feed into a 'multi-brand semantic layer' that then feeds a 'Core' component library, an 'App' component library and a 'Web' component library. The collections are split into 'multi-brand style' (colours, corner radii etc), multi-brand structure (for granular brand level spacing and sizing) and responsive structure (less brand granular but allows for responsive control for web). So web uses multi-brand style + responsive and app can use multi-brand style + multi-brand structure. | 3 | |||||||||||||||||||||||
6 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | We are still planning our governance approach for a new DS, using satellite libraries for some products and platforms. These annexes to the core design system can contain just a snowflake or two, or a full set of components unique to a 3rd party platform like ServiceNow. | 3 | |||||||||||||||||||||||
7 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app) | We have multiple teams. Each handles a different part of our design system - specific to the product (in framework and platform). We then have a central "core" team that works on Tokens etc that are implemented by each system team. | 3 | |||||||||||||||||||||||
8 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand | Generally, by sharing low level commonalities via design tokens. As we make use of style dictionary, we’re able to transform and output the same base values for different technologies so that we can keep the building blocks consistent - at least in theory! | 3 | |||||||||||||||||||||||
9 | Multi-product,Rebrands, refreshes, & redesigns | At the stage of our design system, what I'm finding most effective is: 1. Communicate clearly on the hierarchy of components: Design System components, Product components, Snowflake components 2. Build UI/UX Patterns and actively discussing them with the team 3. Making sure our infrastructure is usable across Figma and code to make it as easy as possible for designers and developers to build Product and Snowflake components using the design system (i.e., having solid foundations) | 3 | |||||||||||||||||||||||
10 | Multi-brand,Multi-product,Rebrands, refreshes, & redesigns,White-labeling | We publish our design system as an NPM library to be installed by any product in the company which needs it. We allow brands/products to use different themes to change the colours etc. | 2 | |||||||||||||||||||||||
11 | Multi-brand,Multi-platform,Multiple color modes,White-labeling | We're addressing our organizational diversity by segmenting our design system efforts into two distinct areas, each with unique needs: B2C Design System: - Serves our white-label e-commerce platform. - Supports web, iOS, and Android platforms. - Covers desktop, mobile web, and tablet screens. - Supports 12 brands through flexible theming. - Dark mode is currently in development. B2B Design System: - Serves numerous internal products and teams. - Web and Android support are actively being built. - Accommodates various screen sizes. - Maintains a consistent single "brand" and mode. | 4 | |||||||||||||||||||||||
12 | Campaigns,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | brand design is basically a plan. Executing on a plan solves so many organizational issues. | 4 | |||||||||||||||||||||||
13 | Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app) | We are focused on the basics, html, css, js and inviting our users to extend the design system to meet their specific platform needs | 1 | |||||||||||||||||||||||
14 | Campaigns,Multi-framework,Multi-platform,Multi-product,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,White-labeling | We're a small organization (<15 total) and we just deal with it. People have to wear multiple hats and we transfer ownership of items from time to time so everyone learns everything. Each new owner is responsible for updating the documentation if things don't go as planned. | 3 | |||||||||||||||||||||||
15 | Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | To get a handle on it all, consolidation and streamlining to a foundational set of tokens with plans to expand and adjust as we establish stronger guidelines and governance. | 3 | |||||||||||||||||||||||
16 | Multi-platform,Multi-product,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | We got a main set of libraries with foundations and components that are present across products (Figma and codebase managed by DS team). Then we have a separate set of libraries that are for specific products (the design libraries are managed by DS but updates are less frequent. Codebase is managed by product stream. I know we are an odd case as we have a decent-sized DS team with many designers and awesome dedicated web and app engineers. The team tries to be as present as possible on product streams crit sessions so we can address their needs as much as possible and as quickly as possible. We give product teams several ways to reach out to us and contribute to the system. | 3 | |||||||||||||||||||||||
17 | Multi-platform,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand | Defining tokens and explaining the rationale behind our design decisions, along with clear dos, donts, and visual demonstrations | 3 | |||||||||||||||||||||||
18 | Rebrands, refreshes, & redesigns | n/a to not skew data | 3 | |||||||||||||||||||||||
19 | Multi-platform,Multiple color modes,Rebrands, refreshes, & redesigns,White-labeling | Rather ad hoc without a consistent approach | 2 | |||||||||||||||||||||||
20 | Multi-brand,Multi-platform,Multiple color modes,Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | Token architecture and DevOps. | 3 | |||||||||||||||||||||||
21 | Multi-brand,Multi-product | Ignoring consistency between different brands. Almost every project in the company has its unique brand, and we treat each product as an individual. Aiming for an honest and authentic design. | 4 | |||||||||||||||||||||||
22 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | Calling out the advantages of consolidation when possible | 2 | |||||||||||||||||||||||
23 | Multi-framework,Multiple color modes,Rebrands, refreshes, & redesigns,Sub-brand | We're trying to "platform-itize" our product offerings. | 3 | |||||||||||||||||||||||
24 | Campaigns,Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | Branding - Theming (pulled directly from figma variables -> API) in cases where design tools capabilities = User Needs & Code (such as color). Platform & frameworks - currently common variables are shared where appropriate and can be translated to framework, though we lean toward different libraries for different platforms | 4 | |||||||||||||||||||||||
25 | Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand | We are looking into what Brad calls a tiered system. We believe extensibility is key alongside democratization and autonomy. Our team is and has been a bottleneck, so this approach is what we believe will help us help our consumers in a more efficient, sustainable and appropriate manner. | 4 | |||||||||||||||||||||||
26 | Multi-framework,Multi-product,Multiple product families (e.g. marketing site & web app),Sub-brand | The design system's code components are built for web interfaces, so the mobile app has its own "technology-specific implementation of the core design system. We export an explicit style sheet for our .com / marketing site so that they can adopt our CSS within their CMS. Products and sub-brands create their own sets of recipes for components not suited for the enterprise-wide nature of the core design system. | 3 | |||||||||||||||||||||||
27 | Multi-product,Multiple color modes,Rebrands, refreshes, & redesigns,Sub-brand | Currently very poorly since we don’t have solid foundations and theming support in place yet | 2 | |||||||||||||||||||||||
28 | Campaigns,Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,White-labeling | The company has also recognized how complex things have gotten due to some recent leadership changes and decided to tackle it head-on with a "globalization" initiative. We're basically auditing everything we have out there, looking for ways to optimize, and working toward a unified back-end tech stack that'll actually scale with us. It sounds great in theory, but the reality is we're deep in the weeds trying to figure out how to consolidate 200+ websites and applications spread across the globe - which, as you can imagine, is no small feat. I've been tasked with creating a scalable design system that can handle all these different areas and platforms. This journey actually started during our first re-platform about 3 years ago. We've always dealt with multi-brand work, but now we're adding multi-region and multi-framework into the mix, which has definitely ramped up the complexity. Right now we're focusing on a few key areas: standardizing white-label components for the design system, getting our high-level tokens organized and distributed properly, and building solid relationships with all the external teams we'll be collaborating with. We're also running proof-of-concepts across different frameworks and exploring a headless approach for both our core and design system architecture. Honestly, we're still in the early stages of all this, so if you ask me about it again in six months, the whole landscape might look completely different. | 3 | |||||||||||||||||||||||
29 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | We use design tokens to support 10 brands across 40+ websites and mobile apps. We are currently in the process of modernizing our sites so that they are actually leveraging the system components. | 3 | |||||||||||||||||||||||
30 | Campaigns,Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | Tokens and governance model planning | 2 | |||||||||||||||||||||||
31 | Multi-platform,Multiple color modes,Rebrands, refreshes, & redesigns | With the usage of divers components, for the sake of simplicity for designers, and then figma variables and design tokens (as json) to factorize the component into modular components | 3 | |||||||||||||||||||||||
32 | Multi-brand,Multi-framework,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,White-labeling | As Qualia's solo designer, I'm tackling multi-product families (marketing vs. enterprise software), multiple color modes, and multi-framework challenges by building what Brad calls a "tiered layer-cake architecture" with design tokens as the foundation. Being solo gives me advantages like moving quickly between contexts without coordination overhead, but it also means I'm constantly context-switching and have to be strategic about where I invest my limited time and energy. I'm focusing on flexible design token systems that let me serve different aesthetic experiences to different products while keeping the efficiency benefits of shared systems - this approach helps me scale my impact across Qualia's diverse landscape without burning out trying to custom-design everything from scratch. | 3 | |||||||||||||||||||||||
33 | Campaigns,Multi-framework,Multi-platform,Multi-product,Multiple product families (e.g. marketing site & web app),Sub-brand | Multi-framework offerings through web components and other packages. Design tokens. Style variables. Open repositories. Regularly meeting with DS and delivery teams throughout the organization to better sync and align on strategies and roadmaps. Storytelling to advocate for specific ways of working. | 2 | |||||||||||||||||||||||
34 | Campaigns,Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | I’ve addressed it via tokens, component libraries, and the occasional platform-specific style guides. | 4 | |||||||||||||||||||||||
35 | Multi-product | Not very well. | 1 | |||||||||||||||||||||||
36 | Campaigns,Multi-framework,Multi-product,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand | Design Systems in my company has been experiencing increased expectations to bring consistency to our multi-all-the-things world. It comes up often as a problem - each product team sharing their unique frustrations within the problem spaces that they're working in but it usually stops there without a manageable solution. That being said, there is an initiative around improving general design to dev parity through AEM which would be utilized my multiple product teams and dev partners which is promising. | 2 | |||||||||||||||||||||||
37 | Rebrands, refreshes, & redesigns,Sub-brand | This has been challenging for us. As a company, we are sort of in disagreement over how similar the different sub-brands should be. We've gotten a lot of push back from product teams who want to make customized, updated looks for their sections. It's resulted in different looks across the site that haven't exactly been centrally planned. | 1 | |||||||||||||||||||||||
38 | Multi-platform,Multi-product,Multiple product families (e.g. marketing site & web app),White-labeling | We are addressing organizational diversity by having our DS team gather essential information from the various product design teams and development teams to develop our design system through a structured approach using biweekly iterations, and phases aimed to foster collaboration, flexibility, and knowledge transfer as we roll it out. Each of our products will have unique systems user requirements in order to adopt the DS. We are also considering rolling out several different code bases to support the various products already in our suite. | 3 | |||||||||||||||||||||||
39 | Campaigns,Multi-brand,Multi-framework,Multiple color modes,Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | Historically different teams have had to cover separately. We are trying to bring it together, but it also involves a lot of conversation with the brand team on strategy. | 2 | |||||||||||||||||||||||
40 | Multi-product | We are just starting this process. Our primary UI Library is in an older version of PrimeNG that needs updating, and in order to apply our styles to the update, the front end team needs to start using tokens. Meanwhile we purchased a Design System UIKit for Figma from PrimeNG to start a new product with a new look/feel and it is full of tokens. Hopefully the 2 will align as tokens are created.. working on a plan. | 2 | |||||||||||||||||||||||
41 | Multi-brand,Multi-framework,Multi-platform,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand | In my most recent system, cleaning up tokens and setting up consumers for customization, designing components that can be broken down to their smaller elements and customized, relinquishing some control/governance to consuming team ownership. | 3 | |||||||||||||||||||||||
42 | Multi-framework,Multiple color modes | Design tokens and providing assets for multiple platforms/frameworks when necessary. | 5 | |||||||||||||||||||||||
43 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand | Tokens, mainly. But I think perhaps frameworks are preventing wider adoption of our system, especially internally (I am not a dev though, so take that with a grain of salt). Our design system is also not set up for robust data display to properly support very complex internal work. | 2 | |||||||||||||||||||||||
44 | Multi-product,Rebrands, refreshes, & redesigns | We're basically addressing organizational diversity by getting rid of it. We're unifying our main website and companion app under the same design system so users get a consistent experience across both. Instead of trying to juggle different visual styles, we just decided to align everything. | 4 | |||||||||||||||||||||||
45 | Multi-brand,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,White-labeling | Right now for us its taking a little bit at a time. Its really easy to feel overwhelmed with everything moving at the same speed.... URGENCY! But nothing will be accomplished if you work on it all at the same time. Its good to take a second to figure out what is most important, finish it and then move to the next item. its also good to start allowing other teams to be working on design system things too. | 3 | |||||||||||||||||||||||
46 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | Through a layered approach - Layered theming capabilities and separation of a core design system from a more specific "configuration " for different product families. | 3 | |||||||||||||||||||||||
47 | Multi-brand,Multi-framework,Multi-product,Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | I'm new to the org (~6 months), working as a UI Engineer, so my initial approach to this problem is: 1. Get the history of Design System attempts and failures from the tenured Designers and Developers. 2. Identify the common pieces across all the different products. 3. Create a Design-to-Code proof-of-concept for the smallest common pieces (atom, molecule, component etc). 4. Apply new tools (Figma APIs, AI, etc) and approaches that will help make the Designer / Developer collaboration more robust and efficient. 5. Let the conversation grow from there, leaning on the proof-of-concept as objective confirmation. I believe my approach is the best way to address this issue because it's new-hire friendly and can help me become a contributing member to the team. It also promotes communication and understanding among the team, which is beneficial to the company as a whole. | 5 | |||||||||||||||||||||||
48 | Multi-brand,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | Broad and context-specific tokens that can be changed based on context, platform, screen size, brand, etc. | 4 | |||||||||||||||||||||||
49 | Multi-framework,Multi-platform,Multi-product,Multiple color modes | Product area owners and design systems teams are largely responsible for identifying and addressing incoherence that stems from all the siloed work streams. | 3 | |||||||||||||||||||||||
50 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand | Having multiple design system, connecting the devs and pushing forward that they need to sync in order to have an effective system. | 2 | |||||||||||||||||||||||
51 | Campaigns,Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | Currently, with a multi-design system approach - each brand has its own system, and there are separate systems for public-facing (app and web) and internal (contact center, retail) tools. I actually think there are some advantages to this approach - it allows each system to adapt to the needs of its users, customers and stakeholders more accurately and rapidly than a multi-everything system would. Multi-everything was tried and abandoned within a year as it was impossible to get anything done. But budget holders do still see the many system approach as inefficient so multi-everything comes back to the table regularly. I can see that sharing some things - tokens, personnel - might have efficiencies - but definitely believe there need to layers that are more tailored to the brand, product and platform. So very interested in this episode! | 1 | |||||||||||||||||||||||
52 | Multi-brand,Multi-product,Multiple color modes,Rebrands, refreshes, & redesigns | Depends on the organisation we are working with, but the standard approach we take is single design system/multiple design token sets. We have also taken to web components from a dev perspective as they work across products, frameworks and platforms. | 4 | |||||||||||||||||||||||
53 | Multi-brand,Multi-framework,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,White-labeling | It's a struggle. I've dealt with diversity issues primarily in large enterprise settings where the company has acquired multiple different products or teams. Design systems have come into play for modernization efforts, aimed at unifying and rebuilding multiple disparate systems into a more cohesive platform with a "seamless UX/UI". That mandate typically helps push things toward a systematic approach to the front end, but managing the coherence across feature teams in the overall UX is another significant aspect. That's more tied to the research and design of a product vision, which is usually pushed out of the schedule in parallel with skepticism about the need for a design system in the first place. We've seen the best ROI when enough up front investment is made to a code-centric approach with centralized component library (3rd party or headless), themed, and 'wrapped' or "custom-componentized" so that we can control the scope of molecules and organisms, and even push versioned feature updates out that teams can opt into when they choose as it relates to any past features leveraging those evolving components. I’ve been on projects where I’ve tried to extoll the value of the above. Still, decision-makers choose to shortcut against advice for perceived speed, and in the end, it eventually catches up with them. They’d subsequently learn their mistake and want to do the component release method, which becomes harder to retrofit into the work mid-dev. | 3 | |||||||||||||||||||||||
54 | Multi-framework,Multi-platform,Multi-product,Multiple color modes,Rebrands, refreshes, & redesigns | Poorly. Leadership wants consistency and to update the look and feel but we have limited technical capability to do so and even more limited resources. We HAD a design system team, engineers and design working side by side and they removed our engineers for resourcing other initiatives. We were doing a good job at setting our system and processes up for being able to support the organizational diversity, we were just seen as too slow. | 2 | |||||||||||||||||||||||
55 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Rebrands, refreshes, & redesigns,Sub-brand | By clearly defining and communicating the problem domain where the design system will try to focus on from the beginning. Mainly in terms of internal users, products and end customers. Making sure that solving the most common pain points for efficiency, velocity and coherence are aligned with the organization's business goals. In my case, the org's goals were aligned with larger investment happening on the consumer side. That meant that my team would focus on the consumer facing experience, rather than on internal tooling, so that we could focus on building a system that served 9 brands across 3 different platforms, supporting 30+ digital products and three parallel re-brandings. This approach naturally started to create boundaries between systems (consumer and internal) to deliver focused value, and highlighted the need to think of an ecosystem of design systems. Where a scalable design token architecture could eventually support the rest of the "multi" asks from the business. | 4 | |||||||||||||||||||||||
56 | Campaigns,Multi-platform,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand | It is a bit messy, much of our complexity is new as our org is growing fast. Aa better token strategy is a priority to wrangle before it grows more debt. In the past I've worked on whitelabel systems that served a variety of sub brands, to help standardize the technology and create real efficiency. At the start it felt a bit tight and constricting but as time went on we were able to get more brand specific and build in more autonomy for designers to iterate through specified brand themes. | 3 | |||||||||||||||||||||||
57 | Campaigns,Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Events | Leaning heavily on design tokens, leaning towards flexibility in our components, starting to establish recipes, working towards understanding various teams “under the hood” tech stack and driving influence to align tech stacks when it makes sense to | 3 | |||||||||||||||||||||||
58 | Multi-brand,Multi-product,Rebrands, refreshes, & redesigns,Sub-brand | With hundreds of products using our design system, we have to remain somewhat flexible to allow products to customize their UI and maintain their brand but also govern some UX and A11y guardrails. We offer system of systems tokens for size, spacing, color, border radius, etc. This allows products some customization but also maintains some governance. We also provide custom theming for products that have their own brand. In addition, we work on educating our consumers to make the most of the design system (e.g., use the card we built so you don't have to build it over and over) and where they can configure things to their liking (e.g., use more dense size and space to maximize the UI real estate; customize the color theme but maintain A11y contrast requirements). | 4 | |||||||||||||||||||||||
59 | Multi-framework,Multi-platform,Multiple color modes,Rebrands, refreshes, & redesigns | Imperfectly. Working on Web primarily, trying to make other platforms match as much as possible, and when it differs, hoping Figma variants can show the differences. And other parts of the experience (marketing site) are out of scope. | 3 | |||||||||||||||||||||||
60 | Campaigns,Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | No real secret, just a lot of tooling we’ve built to simplify the work over the years, a bunch of projects to make sure everything is aligned and processes don’t let it degrade over time + an amazing team excited of digging deep into the implementation details of the components | 4 | |||||||||||||||||||||||
61 | Campaigns,Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | Through standards and purpose. By thinking deeply about why the parts exist, the needs of the user, and how to think systematically towards a solution. | 4 | |||||||||||||||||||||||
62 | Campaigns,Multi-product,Multiple product families (e.g. marketing site & web app),Sub-brand | Creative leadership tries to keep a pulse on wide-spread visual sprawl, but not everyone at the organization shares what they are doing or creating. There are some checkpoint for high-visibility outputs. Tickets have to be submitted and a group of reviewers have oversight to deny or approve activities. Policing is hard and time-consuming though, so its not an ideal way to solve alignment issues between creator group. | 1 | |||||||||||||||||||||||
63 | Campaigns,Multi-brand,Multi-platform,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | Hmmm. I suppose with a design system. But each of these diversions are handled by highly siloed work groups that hardly collaborate. | 0 | |||||||||||||||||||||||
64 | Campaigns,Multi-brand,Multi-framework,Multi-platform,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | Whoops. Disregard this one. | 0 | |||||||||||||||||||||||
65 | Multiple color modes,Rebrands, refreshes, & redesigns | Tokens | 2 | |||||||||||||||||||||||
66 | Campaigns,Multi-platform,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | Leveraging variables and figma api | 3 | |||||||||||||||||||||||
67 | Campaigns,Multi-framework,Multi-product,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | no consistency, no system, just building it from scratch for each channel | 1 | |||||||||||||||||||||||
68 | Multi-product,White-labeling | Our component library detaches look from logic. Components are mostly concerned with the logic and accessibility. They are all themable to support b2c/B2B and white labeling. | 4 | |||||||||||||||||||||||
69 | Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | By aligning with the leading teams and working in a co-federated model. It can be quite a pain and lead to a lot of dependency | 3 | |||||||||||||||||||||||
70 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | We are trying to keep the "enterprise" system as flexible as possible and focused on the tokens and smaller atomic items. We have multiple other systems that have spun up to handle the multiple products, white-labeling, frameworks, etc. We are now trying to convince leadership that while they want convergence (to reduce arbitrary uniqueness) that one system can't solve it all or go as deep and provide more value as a system of systems - they layer-cake Brad refers to. So, we're piloting a system of systems w/ some of the smaller and more "willing" systems to prove out the concept. We've struggled w/ starting with high-impact sub-systems and they are proving more finicky and difficult to wrangle. So, we'll see if this approach of starting w/ the smaller, willing groups will help us learn, iterate and then expand/scale. In the further past we've tried a "stick" approach to telling other systems they need to converge and put their system "to bed." but that did not work, just caused rifts. We have new leadership and many new folks in the various systems who now seem ready to try to work together again and partner vs put each other out of business. | 2 | |||||||||||||||||||||||
71 | White-labeling | We are creating component tokens to allow product customization with flexibility | 3 | |||||||||||||||||||||||
72 | Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,White-labeling | We're moving from a specific framework (Angular) to standards based web components. | 3 | |||||||||||||||||||||||
73 | Multi-brand,Multi-product,Multiple color modes | We have no real strategy, different teams are siloed and making their own decisions. | 3 | |||||||||||||||||||||||
74 | Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | More discussions than anything else. There is no fundamental framework to handle all of these variations. | 3 | |||||||||||||||||||||||
75 | Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Sub-brand | Through a very siloed process | 1 | |||||||||||||||||||||||
76 | Campaigns,Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | Working towards a theme-able design system | 3 | |||||||||||||||||||||||
77 | Multi-framework,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | I've dealt with all of these in past systems roles! At my current job we have a foundational system to support all products and then we support product teams in building expansion packs to support their specific needs. It's working for now but I wonder about the long-term maintenance to keep everything up to date. We're also doing a lot of 1:1 support, which isn't scalable. We're working to educate product teams on using the system and expansion packs but this is also ongoing because of staffing turnover. | 3 | |||||||||||||||||||||||
78 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns | We are in the early stages of formalizing a "systems of systems" approach. We have one official specialized library that provides assemblages of enterprise library components to solve for common user interactions within a specific platform. This enables the enterprise system to focus on broader needs while the specialized library focuses on the needs of a specific platform. There are other similar specialized libraries that we are in the early stages of co-creating a more defined specialized library model. | 3 | |||||||||||||||||||||||
79 | Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,White-labeling | It's nearly impossible at the size of the org and it's complexity. The way to address it is constantly shifting. Last year, there was a huge emphasis placed on governance and mitigating any divergence from the design system. This year, better collaboration and orchestration to allow for certain product deviation. | 2 | |||||||||||||||||||||||
80 | Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app) | We've embraced theming via "Figma varaibles" on the design side and have dedicated 'design kits' for each framework. The problem is that maintaining parity between frameworks is a challenge as teams build cross-framework features; it's easy for divergences to pop up. Additionally, it takes a long time for new versions of a compoennt to be adopted when we push out fixes and we haven't figured out how to manage that because we're still attempting to get teams and other products across the company to start adoption. | 3 | |||||||||||||||||||||||
81 | Multi-platform,White-labeling | I joined the company (white-label events) as a (sole) DS designer 9 months ago to build a design system from scratch. The state of things was very messy, with the product implementing client colours all over the place (CTAs, all sorts of inputs, highlights, backgrounds) without any consideration for accessibility or aesthetics. Our product is available on web, and as an app (they do slightly different things). I established foundations (typography, colours, icons, spacing) which already proved to be a huge improvement. The dev team is very busy, so we have yet to see all the elements in production, but designs have become much more consistent. The components built upon the foundations help solidify the consistency. I don't have a good and working solution for how we are addressing the diversity, but I shall try anyway. Re multi-platform: Working with the design team has been lovely, they were very excited to have some support from the DS. It has been very difficult (impossible?), however, to release the DS updates to the app and the web product at the same time. This is because different teams/developers work on the web vs the app, and these platforms have very different roadmaps and release schedules. The devs are already overworked, so the best way we have found to introduce DS components was to include them in designs for new features (vs going in and retrospectively updating components). What helps with the app is a very DS-keen developer, for whom I am grateful. We had a strong start with the web dev, but he got roped into some very intense feature work so has not had time to do DS work in the past few months. Re white-labelling: We agreed to strip out client colour from all interactive elements and make those monochrome, and to include their colour as an accent colour/highlights only. Logos and assets are still there, which provide enough brand presence. This has helped with a lot of accessibility issues with colours. We aim to make the copy very neutral. | 3 | |||||||||||||||||||||||
82 | Multi-brand,Multi-framework,Multi-platform,Multiple color modes,Rebrands, refreshes, & redesigns,Sub-brand,White-labeling | The design system is a language expressed as design tokens. The diversity is seamless given strong architecture, taxonomy, and transform technology such as Style Dictionary. | 4 | |||||||||||||||||||||||
83 | Multi-brand,Multi-framework,Multi-product,Multiple color modes,Rebrands, refreshes, & redesigns | Routing Figma Variable Collections | 5 | |||||||||||||||||||||||
84 | Campaigns,Multi-brand,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand | A core system revamp and a systems of systems approach across the org | 4 | |||||||||||||||||||||||
85 | Multi-brand,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand | With pain. Organisation still under impression it can be solved by man power, where smart system is the more efficient form. | 2 | |||||||||||||||||||||||
86 | Campaigns,Multi-framework,Multi-platform,Multi-product,Multiple product families (e.g. marketing site & web app),Sub-brand | Our design system has an MVP of components that should be applicable to the different situations we have on campus. From there we ask people to create unique components following the look and feel of the design system. | 3 | |||||||||||||||||||||||
87 | Multi-framework,Multi-platform,Multi-product,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,White-labeling | I've mostly dealt with diversity of product, platform, product families and framework. In many ways each challenge requires its own considered approach. I've found that it helps to be clear about the purpose of each experience. If there's ambiguity in the 'why' then the 'how' becomes much more difficult. If the purpose clear, then the next step is to determine if the identity is clear. Building a good relationship with brand leadership helps in this area. Once purpose and identity are established or at least clarified, it becomes easier to decide if a system of systems model, a hybrid model or a unified model makes sense. I've had success implementing a system of systems model where there's a lot of purposeful org diversity but have also found that it takes longer and is more difficult to govern effectively. | 3 | |||||||||||||||||||||||
88 | Campaigns,Multi-product,Multiple color modes,Rebrands, refreshes, & redesigns,White-labeling | Adopting is still bad so we are only focusing on theming and it’s not the best solution. Right now there is a re branding going on and since there are still hardcoded colors on the app is impossible to move forward | 2 | |||||||||||||||||||||||
89 | Multi-product,Multiple color modes | Local systems, but working on graduating that to core system. | 4 | |||||||||||||||||||||||
90 | Campaigns,Multi-brand,Multi-framework,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,Sub-brand,White-labeling,multi-org/mutli business entity? our DS serves my company, with our own business, product, ops, legal and design teams but it also serves our parent company who has their set(s) of those teams. We share a front end in some cases, not all, but have sep goals, vision, staffing, etc. | Two main strategies are layering and escalating. Layering to help make sure we dont have a system that is too rigid, and can evolve as our platform strategy evolves. We have our token system and dumb global components right now but have thoughts to evolve to smart component sets as we scale. i try to only layer what i can feel confident in and leave the future layers alone until we get clarity we need. getting clarity hinges on my ability to escalate my POV that our platform doesnt support diversity - so how can we build a system that does if the platform cant deliver it? I spend a ton of time identifying the gaps i see and escalating so that we might get to a point where we can address the diversity needed and architect this with more thought and confience | 2 | |||||||||||||||||||||||
91 | Multi-product,Rebrands, refreshes, & redesigns,White-labeling | Flexibility due to impact of needing to align everything and managing how much change our customers take on over time. | 4 | |||||||||||||||||||||||
92 | Multi-brand,Multi-product,Multiple color modes,Rebrands, refreshes, & redesigns,White-labeling | We try as best we might to manage this with a design system team made up of folks from each product with leadership involvement. We’ve worked to align on tokens using consistent naming conventions etc. We are currently experimenting with tooling to leverage both token studio and figma variables to help scale. | 2 | |||||||||||||||||||||||
93 | Multi-brand,Multi-framework,Multi-product,White-labeling | Essentially by embracing the strengths of the related platforms and brands but also ensuring that there is, as Brad has indicated, a multi-layered stable underlying architecture to fall back on so that commonalities can be reused when required. However, it is stressed that is in my opinion to "use the platform" as much as possible to take full advantage of the power and speed of the platform. That includes embracing tools like web components to achieve that in addition to a tough decision regarding frameworks like React Native. | 4 | |||||||||||||||||||||||
94 | Multi-framework,Multi-platform,Multi-product,Multiple color modes | With a smile | 2 | |||||||||||||||||||||||
95 | Multi-brand,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,White-labeling | We’ve recently set up a theme for a second product, which was a big milestone for us. It allowed us to extend our design system, Gamut, to another part of the business without needing to fork or duplicate work. The rollout went well and actually helped build more internal momentum around the system—teams could see how flexible it could be while still maintaining consistency. While we’re still early in supporting multiple brands/products, this experience is helping us shape clearer guidance around what should be themeable, how we manage shared vs. product-specific styles, and how we govern contributions as adoption grows. | 3 | |||||||||||||||||||||||
96 | Multi-framework,Multiple product families (e.g. marketing site & web app) | Working for a government entity we are pretty rigid requirements when it comes to brand identity and customization. Citizens of the state need to know the applications/sites they visit trusted entities. We try to convey that through our design system and common patterns. We understand teams will have different needs and we work with them to understand the problems they face and how they can leverage what we have already created to build something that fits their needs. | 3 | |||||||||||||||||||||||
97 | Multi-brand,Multi-framework,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app) | Our DS is in web components so we can support multiple frameworks. This has worked out pretty well for us and we are able to support web apps, content management and CRM systems. In terms of supporting other brands/products, we have custom themes using design tokens and that also works well, although we could be more efficient in the design/dev handoff for token changes, which today is still a manual process. | 4 | |||||||||||||||||||||||
98 | Multi-framework,Multi-platform,Multi-product,Multiple color modes,Sub-brand | Our company is a startup that was purchased and folded into a large, 100 year old national company, so there are a lot of siloed systems, platforms, and processes. We are currently working to find place where we can streamline efforts, which chiefly consists of starting a shared design system with robust token architecture that can span just the two platforms under our umbrella (still totally separate from the large corporate teams). | 3 | |||||||||||||||||||||||
99 | Multiple product families (e.g. marketing site & web app) | At this point just trying to understand the lay of the land, we have a native app in works at the moment and we're trying to figure out how to align the two design systems. | 2 | |||||||||||||||||||||||
100 | Multi-brand,Multi-framework,Multi-platform,Multi-product,Multiple color modes,Multiple product families (e.g. marketing site & web app),Rebrands, refreshes, & redesigns,White-labeling | Largely platform agnostic practices and "the product is the product everywhere" principles mostly. But frankly, I've also strongly advocated for maintaining independent code and design when the product lines are too dissimilar or on independent product development treks. Ask me about Venmo and PayPal sometime, lol | 3 | |||||||||||||||||||||||