| 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 067, deep dive hosted on January 29, 2026 with Ben Callahan and Yesenia Perez-Cruz. There are 55 answers. The question this week was: ----- Hello, system thinkers! Last week, Yesenia and I were chatting about how so many design systems miss out on the possibility to support their products’ differentiation in the market. Without intention, adoption of a design system can mean a product is settling for the “plateau of sameness.” Yesenia recently wrote about this challenge, and how she solved it, over on her Substack. This week, we want to explore ways your design system’s architecture may be limiting its expression. And, we want to talk about how to shape your system so that it serves the needs of your specific organization. Welcome to Episode 067 of The Question, with Ben Callahan and Yesenia Perez-Cruz! Where do you most notice sameness emerging in your consuming products as a result of your design system? (Select all that apply) * Overall layout and page structure * Visual hierarchy and emphasis * Interaction patterns and behaviors * Brand expression / personality * I don’t notice meaningful sameness * Other (please describe) Which of the following best describes the primary goal of your design system today? * Operational Efficiency: Reducing "time to ship" and engineering debt. * Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family. * Product Differentiation: Empowering unique features to stand out while maintaining a shared foundation. * Other (please describe) If you had to identify one specific part of your system’s architecture (e.g., tokens, component API, documentation) that currently acts as a "bottleneck" to product expression, what would it be and why? | |||||||||||||||||||||||||
2 | Question 1: Where do you most notice sameness emerging in your consuming products as a result of your design system? (Select all that apply) | Question 2: Which of the following best describes the primary goal of your design system today? | Question 3: If you had to identify one specific part of your system’s architecture (e.g., tokens, component API, documentation) that currently acts as a "bottleneck" to product expression, what would it be and why? | |||||||||||||||||||||||
3 | Brand expression / personality,Visual hierarchy and emphasis | Operational Efficiency: Reducing "time to ship" and engineering debt | The component API is probably the main factor, as it is often restricted to the use cases imagined and controlled for by the team (creative and engineering) at the time of creation. Some flexibility with composability and/or slots helps, but other times it’s restricted deliberately in order to control for intended component use. | |||||||||||||||||||||||
4 | Interaction patterns and behaviors,Overall layout and page structure,Visual hierarchy and emphasis | Product Differentiation: Empowering unique features to stand out while maintaining a shared foundation | Knowledge base (not limited to documentation). More on the decision-making frameworks available in the system that empower teams to experiment with product differentiation. | |||||||||||||||||||||||
5 | Interaction patterns and behaviors,Visual hierarchy and emphasis | Operational Efficiency: Reducing "time to ship" and engineering debt | Documenting creative use of the system is our bottleneck. Our design system serves a lot of different types of pages (with different content, target groups, and needs) and has a lot of built-in flexibility. It’s hard to guide the training of the creative muscle and intuition that a designer needs to be able to use the design system optimally. | |||||||||||||||||||||||
6 | Brand expression / personality,Interaction patterns and behaviors,Visual hierarchy and emphasis | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | We started the design system at Regions Bank in order to create visual cohesion across our digital products and platforms, and we're still working on implementing that across everything, so there's not a lot of effort put in to visual expression or creative differentiation in our work. | |||||||||||||||||||||||
7 | Interaction patterns and behaviors,Overall layout and page structure,Visual hierarchy and emphasis | Operational Efficiency: Reducing "time to ship" and engineering debt | I don't think there is anything that stands in the way of product expression? Our DS components and patterns start with the products themselves, and tackle those interactions that don't need to be different. If anything, I'd say it's an issue of product management and designers consuming the system. | |||||||||||||||||||||||
8 | Interaction patterns and behaviors,Visual hierarchy and emphasis | Operational Efficiency: Reducing "time to ship" and engineering debt | Enforcing a minimal token set tends to be limiting. | |||||||||||||||||||||||
9 | Overall layout and page structure | Operational Efficiency: Reducing "time to ship" and engineering debt | I'm hung up on the word "bottleneck" as I don't think our design system really blocks anyone from product expression but I would say there are areas where we are less flexible (e.g., layout and navigation and tokens). Those more rigid parts of our system are intentional for usability and consistency. We still have some parts of our system that allow for more product expression like theming. | |||||||||||||||||||||||
10 | Visual hierarchy and emphasis | Operational Efficiency: Reducing "time to ship" and engineering debt | Ensuring accessibility is ingrained into all components. | |||||||||||||||||||||||
11 | Visual hierarchy and emphasis | Product Differentiation: Empowering unique features to stand out while maintaining a shared foundation | Our development pipeline. we have a dedicated UX team for the system but a partially dedicated dev team - they are saddled with a lot of additional work outside of the system that they lag dramatically behind the UX team so our team can't get a good rhythme | |||||||||||||||||||||||
12 | Interaction patterns and behaviors | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | We have not yet shipped our v.1 yet so we will know this in probably a year. | |||||||||||||||||||||||
13 | Brand expression / personality,Interaction patterns and behaviors,Overall layout and page structure,Visual hierarchy and emphasis | Operational Efficiency: Reducing "time to ship" and engineering debt | Tokens - on the code side, we still only have primitive tokens in place for our core design system, and semantic tokens are only in place in Figma via variables. Designers want component-level tokens that guide usage by element/component (“When do we know where to use _ color when creating new UI…”, meanwhile there can be confusion with feature handoff files when designers apply our existing semantic variables and there is not parity with code, so QA/devs must translate to the corresponding primitive that matches the hex value. 😬 | |||||||||||||||||||||||
14 | Brand expression / personality,Overall layout and page structure | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | Inflexibility of current components. Not enough basic pieces made separately to be remixed into more custom components easily. | |||||||||||||||||||||||
15 | Interaction patterns and behaviors,Overall layout and page structure | Operational Efficiency: Reducing "time to ship" and engineering debt | Documentation, because to do it right and not just have filling text that looks good, you really have to take a step back with the whole design team, to not just define the right design patterns, but all the explanations as well : Why, where does it come from, to what principles does it have to answer, what else have we tested | |||||||||||||||||||||||
16 | Brand expression / personality,Interaction patterns and behaviors,Overall layout and page structure | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | Individual designers wish to add their own expression, which often leads to disunity of expression on the whole. | |||||||||||||||||||||||
17 | Interaction patterns and behaviors,Overall layout and page structure | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | When the Design team is at capacity, the Product Owners like to use Figma Make for Rapid Prototyping their ideas. Without training and proper setup, they unfortunately do not always have the proper context so the results can be all over the place. We (Engineering and Design) are in the process of defining the Figma Design Library export process and also setting up AI Guidelines to create a more consistent context. | |||||||||||||||||||||||
18 | Overall layout and page structure | Operational Efficiency: Reducing "time to ship" and engineering debt | Our current layout. We work with external partner brands, and our recurring complaint is that we can't add the external partners' branding or expression. The look and feel is stagnant. | |||||||||||||||||||||||
19 | Interaction patterns and behaviors,Overall layout and page structure | Operational Efficiency: Reducing "time to ship" and engineering debt | Component API—we have a lot of strict enforcement that we're working to get away from as it's hamstrung recent efforts to launch more expressive work. | |||||||||||||||||||||||
20 | I don’t notice meaningful sameness | Operational Efficiency: Reducing "time to ship" and engineering debt | I'd have to go further upstream for this as we don't have a shared design language that the design system can consume and promote in more meaningful ways, including brand expression. | |||||||||||||||||||||||
21 | Overall layout and page structure,Visual hierarchy and emphasis | Operational Efficiency: Reducing "time to ship" and engineering debt | Resistance to snowflakes and on-offs. | |||||||||||||||||||||||
22 | Interaction patterns and behaviors | Operational Efficiency: Reducing "time to ship" and engineering debt | tokens | |||||||||||||||||||||||
23 | I don’t notice meaningful sameness | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | Our DS (Skyway) hasn't been released yet (only to a smaller Pilot group), so I'm not able to meaningfully answer this. Also, as such, take the answers above with a grain of salt. I want to attend the session, and need to provide an answer to those. | |||||||||||||||||||||||
24 | Brand expression / personality,Interaction patterns and behaviors,Visual hierarchy and emphasis | Operational Efficiency: Reducing "time to ship" and engineering debt | Figma library - may not be showing designers the full extent of how things are extensible | |||||||||||||||||||||||
25 | Overall layout and page structure | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | Documentation is the bottleneck. If we had more of a comprehensive training package I think we would have more people able to contribute in a creative way to standing up content. Right now we rely on a few very senior and skilled folks to tackle the hard stuff, and everything else gets to remain generic feeling if it doesn't rise to the top of the impact list. | |||||||||||||||||||||||
26 | Overall layout and page structure,Visual hierarchy and emphasis | Operational Efficiency: Reducing "time to ship" and engineering debt | Lack of proper documentation AND lack of resources to produce the documentation that would help capture more complex patterns beyond our basic set of components. | |||||||||||||||||||||||
27 | Overall layout and page structure | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | The biggest bottleneck right now is our semantic token layer. We’re still at a stage where designers are building confidence in how to use the tokens and fully understand the intent behind them. As a result, a lot of time is spent debating whether to introduce one-off color tokens instead of trusting the existing system. These conversations are often driven by visual preference rather than functional or semantic need, which slows decision-making and becomes a bottleneck to efficient product expression. | |||||||||||||||||||||||
28 | Brand expression / personality,Interaction patterns and behaviors,Overall layout and page structure | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | Probably the components API because product expression can have many different forms and the components API reduce those expressions to a handful. When products want to express themselves they often feel that the system is a bottleneck in the cases when they desire visual changes like spacings, sizes of fonts, colors that are (and should?) be standardized across products. For many teams product differentiation means smaller buttons, different colors, different radius. Product differentiation should be in the user experience and in the capabilities of the product, not in having smaller buttons because a PM doesn't like the current ones. | |||||||||||||||||||||||
29 | Interaction patterns and behaviors | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | Not sure, looking forward to learning! | |||||||||||||||||||||||
30 | Brand expression / personality,Interaction patterns and behaviors,Visual hierarchy and emphasis | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | The wide disconnect between product and brand designers is our bottleneck. | |||||||||||||||||||||||
31 | Brand expression / personality | Operational Efficiency: Reducing "time to ship" and engineering debt | Process and understanding of the DS and how its meant to be used, Designers apply the design system correctly, but dont think enough about how they can design them into flows and pages that are unique, | |||||||||||||||||||||||
32 | Overall layout and page structure | Product Differentiation: Empowering unique features to stand out while maintaining a shared foundation | Docs | |||||||||||||||||||||||
33 | Overall layout and page structure | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | Our color token matrix is quite complex and requires a fair amount of effort to customize for each product instance. I am looking to streamline the workflow between defining primitives and applying semantic tokens. The goal is a system with robust defaults where 75% of components are automatically 'styled to fit' upon uploading core brand colors, allowing designers to focus only on high-value customizations rather than repetitive token mapping. | |||||||||||||||||||||||
34 | Interaction patterns and behaviors,Overall layout and page structure,Visual hierarchy and emphasis | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | component API | |||||||||||||||||||||||
35 | Interaction patterns and behaviors,Overall layout and page structure | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | The forever answer, documentation. Though doesn't necessarily stop or bottleneck, but does cause tech debt due to the lack of documentation many unique "we needed this now" solutions have piled up. | |||||||||||||||||||||||
36 | I don’t notice meaningful sameness | Product Differentiation: Empowering unique features to stand out while maintaining a shared foundation | Semantic tokens layer not aligned with diverging creative directions. | |||||||||||||||||||||||
37 | Brand expression / personality,Interaction patterns and behaviors,Overall layout and page structure,Visual hierarchy and emphasis | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | our complex component APIs for bigger layout components (like cells, cards, sheets) lack flexibility to enable a wide range of use cases. | |||||||||||||||||||||||
38 | Brand expression / personality | Operational Efficiency: Reducing "time to ship" and engineering debt | Our bottleneck is certainly documentation. Many of our users don’t understand their ability to extend and customize the system for their product. We support things like theming and recipes, but it has been hard to educate people about how Design Systems work. Most see it as just a collection of reusable components. | |||||||||||||||||||||||
39 | Brand expression / personality,Interaction patterns and behaviors,Overall layout and page structure | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | I think it's an issue derived from how we build the system, manifesting through tokens and component APIs. In the need to havd a design system that is designed fast, is easy to use by final users and is accepted by multiple stakeholders, we start relying on tested patterns, color schemes, layout decision, etc - and are afraid of introducing more opinionated or branded moments in the UI. | |||||||||||||||||||||||
40 | Brand expression / personality,Interaction patterns and behaviors | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | Component API | |||||||||||||||||||||||
41 | Brand expression / personality,Interaction patterns and behaviors,Visual hierarchy and emphasis | Operational Efficiency: Reducing "time to ship" and engineering debt | Component API - we’ve gotten really prescriptive on what goes where and why and people have opinions on how that limits designers | |||||||||||||||||||||||
42 | I don’t notice meaningful sameness | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | My company currently uses a federated design system team structure with no dedicated resources. I would argue that the lack of resources results in a very broken and piecemeal UI toolkit for only the designers. If designers are even choosing to use it, there is operational inefficiency as designers need to often detach components to fix bugs or problems with them. | |||||||||||||||||||||||
43 | Brand expression / personality,Visual hierarchy and emphasis | Operational Efficiency: Reducing "time to ship" and engineering debt | For the most recent, large DS team I was on the team makeup and processes as they hindered the team from being creative and testing interesting ideas that might express the brand better. Too many cooks in the kitchen and a hesitation to try new things that would elevate the design. Also designers feeling like they could only reference things they’ve seen in the wild and not really thinking about the brand cohesion or elevating the visual design. That being said the system was highly accessible which was great. | |||||||||||||||||||||||
44 | Our design system adoption at the moment is almost limited entirely to backfilling existing system design (tokens, shared styles, and accessibility). I would check more of the above, but they're a result of legacy work, not the design system. | Operational Efficiency: Reducing "time to ship" and engineering debt | Tokens - our current suite of tokens replicates legacy availability of themes, which until very recently, was monolithic. Despite hosting 3 apps for unique audiences, only 1 shifts by being purple instead of blue. The organization has never really explored unique visuals across the ecosystem, but we're hoping tokens will help be that gateway. | |||||||||||||||||||||||
45 | I don’t notice meaningful sameness | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | An insufficiently modular definition and implementaiton in design and development that prevents rapid and consistent generation of new components. | |||||||||||||||||||||||
46 | Interaction patterns and behaviors | Operational Efficiency: Reducing "time to ship" and engineering debt | maybe documentation...folks don't understand what and where to flex w/ the system...they seem to automatically think any component has to work one exact way. its either by the rules or don't use it. | |||||||||||||||||||||||
47 | Brand expression / personality,Interaction patterns and behaviors,Overall layout and page structure,Visual hierarchy and emphasis | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | lack of distinctive product strategy to build upon | |||||||||||||||||||||||
48 | I don’t notice meaningful sameness | Operational Efficiency: Reducing "time to ship" and engineering debt | The system (tokens, components, APIs, documentation) has it's issues, but the real bottleneck is the tech infrastructure that the system lives within. Thus far, I've not encountered anyone who fully understands or can explain the ownership of the dependent pieces and the constraints those dependencies place on expression or differentiation. | |||||||||||||||||||||||
49 | Brand expression / personality,Overall layout and page structure | Operational Efficiency: Reducing "time to ship" and engineering debt | Documentation backlog and perception that it is too time consuming and also incomplete. | |||||||||||||||||||||||
50 | Brand expression / personality | Operational Efficiency: Reducing "time to ship" and engineering debt | Components: our core team has such a backlog of work, that when teams need a new or modified component it takes us too long to ramp up and ship that thing. But teams will go and build a custom solution, so it's not so much a bottleneck to expression as much as it is a bottleneck for consistency and reducing tech debt. | |||||||||||||||||||||||
51 | Brand expression / personality,Interaction patterns and behaviors,Visual hierarchy and emphasis | Product Differentiation: Empowering unique features to stand out while maintaining a shared foundation | Aaaah! So many things I feel. I don't think it's something within our DS that is the bottleneck, but more organizational challenges. 1. If we were to improve/change our visual language it would require so much alignment across stakeholders + then the design/tech debt incurred. 2. Currently out DS components and authorable components (we use AEM) have operated separately. We are currently centralizing the front end UI, but the level of effort (time and $$$) is a challenge when it comes to continuously push and evolve. 3. But actually, maybe our components and visual language has become so generic looking, that even though we have a flexible system that allows designers to build their own custom designs, everything is stsrt to feel and look to bland and uninteresting. | |||||||||||||||||||||||
52 | Brand expression / personality,Overall layout and page structure | Brand Cohesion: Ensuring every product looks and feels like it belongs to the same family | Probably the component API. That’s where things tend to get rigid. Tokens are flexible, docs can be fixed, but components often lock in old assumptions. When props are too specific or hard to extend, new product ideas feel “wrong” or hacky to implement, even if they should be supported. You know it’s a bottleneck when teams start working around components instead of with them. | |||||||||||||||||||||||
53 | Interaction patterns and behaviors | Product Differentiation: Empowering unique features to stand out while maintaining a shared foundation | Documentation, because we could always do a better job at explaining the intent of our components and their configuration options. It's a work in progress! | |||||||||||||||||||||||
54 | Brand expression / personality,Overall layout and page structure | Operational Efficiency: Reducing "time to ship" and engineering debt | component API, and token API as well. I inherited a system that was built too prescriptively, for a specific product, not to be iterated on/grow over time. My work is to go through, piece by piece and improve the APIs to be more flexible/modify-able in the right ways to support a growing/evolving organization. | |||||||||||||||||||||||
55 | Interaction patterns and behaviors | Product Differentiation: Empowering unique features to stand out while maintaining a shared foundation | Typography, because designers constantly want to break out of “approved” sizes. | |||||||||||||||||||||||
56 | Interaction patterns and behaviors | Operational Efficiency: Reducing "time to ship" and engineering debt | Right now, I'm seeing designers make adjustments on Figma components all the time. It's happening enough that I don't think it's a one-off problem anymore. With Figma slots now available, it makes me wonder: should we just give them the container and spacing, and let designers control typography themselves? We'd still set defaults and semantic tokens so it doesn't turn into chaos but we wouldn't lock them in. The question becomes: are we trying to enforce consistency where it actually matters, or are we just making it harder for people to do their jobs? | |||||||||||||||||||||||
57 | Brand expression / personality | Product Differentiation: Empowering unique features to stand out while maintaining a shared foundation | Probably that our components and design foundations are quite rigid and we are very prescriptive with how they should be used. This is amazing for efficiency, eliminating ambiguity etc. However, I think the lack of choice can result in quite a "samey" interface. Our users find it challenging to "push" the visuals becuase they are limited by what's in the design tool box. | |||||||||||||||||||||||
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 | ||||||||||||||||||||||||||