Episode 49 Raw Data

	A	B
1	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 049, deep dive hosted on March 21, 2025 with Ben Callahan and Rebekah Wolf. There are 78 answers. The question this week was: ----- Hello, System Thinkers! I’ve been talking with Rebekah recently about how much value content designers can bring to a design system team—trust me when I say, there are a LOT of ways. Unfortunately, many of the design system teams I’m coaching or consulting with simply don’t have a content designer on their team. This week, we’re going to focus on one specific area where this unique skill set can truly make your design system better: decision trees. If you look through your design system documentation, you’ll see that almost everything captured there is written with the desire to help an individual from a consuming team make good decisions. Even the best design systems can be used improperly. When we try to aid in decision making by writing a lot of content, we’re still leaving room for so much subjective nuance. In scenarios where we want more consistent decision making, we can address this by offering a series of small decisions that lead to the right component or pattern for our consumers’ specific situation. That’s what a decision tree will do—guide your consumers to the right assets. With this as context, let’s answer The Question: Do you use decision trees to help design system consumers determine which component or pattern to use? If you answered yes, who is creating those decision trees and how are they working? If you answered no or other, how might they be helpful or hurtful for your consumers?
2	Question 1: Do you use decision trees to help design system consumers determine which component or pattern to use?	Question 2: If you answered yes, who is creating those decision trees and how are they working? If you answered no or other, what’s kept you from doing so and how might they be helpful or hurtful for your consumers?
3	Yes	This content is made by the designer/s and it’s implementation is done by the developers in the DS team. We implemented an interactive decision tree to guide designers on choosing the appropriate notification component for their user journey.
4	We once tried a decision tree to use our messaging types - what type to use when and where. The result was so complex and made us think we need to simplify our messaging if it needs a decision tree to use.	The UX designers created it, it was never maintained or used or widely understood.
5	No	We're using "Use this component if..." and "Don't use if.." to guide consumers on individual components. I imagine a decision tree might be helpful for families of related components, eg in a data-centric org, a decision tree of which Table to use.
6	No	I'm not familiar with the concept, but now I'm intrigued :)
7	I've been trying to describe this "component chooser" for a couple years now! But I like the term "decision tree" even more because what we are choosing is more broad than components, and can easily start at the foundation. I'd love to see how this comes to life on the web.	It has become a low priority among other processes that are weak for our subscribers.
8	No	Decision trees can be very helpful when working with patterns. It is something we are considering to offer in our design system as we are working on reframing our existing patterns
9	No	If the system is too intricate, decision trees can become overly complicated and hard to follow.
10	Yes	We've had a lead designer make them for deciding which type of modal to use. Users love it! We've worked w/ our content designer to make one for deciding which design system to use (its a tangled web). It's proven useful. Would love to make more!
11	No	We haven’t used a decision tree exactly how it’s likely intended and/or maybe we’ve never used something this formal before.
12	No	To be honest, I never thought of using it before. But after reading the question and pondering it for a bit, I can imagine where it would be very useful. As a design systems engineer there are a few complex components that have multiple ways of being instantiated (Toasts, Popovers, SelectionTiles). A decision tree in my documentation could be very useful in helping developers decide which one to use.
13	No	Answered No. But actually its "not yet" We have tried to make some previously, but opted out from it, as the concept of what we were trying to document was revisited. I think for design system in the making, its hard to do as team goes through the UI, component by component. So there would have to be a point when we stop and revisit what we have done.
14	Yes	Qausi-yes. I intend to add them to documentation for my new company, but have used them in the past. System designers like myself have created them in the past. They are part of the documentation in the places where they are the most relevant to help designers choose which component works the best considering design best practices as well as product specific use cases and user needs.
15	No	The idea hasn't come up. The only blocker would be getting buy-in to adjust our process so the decision tree becomes part of the component deliverable.
16	Yes	We have just a few and they're used to help understand the differences of, and choose the right one of, generically named components that are very similar. Or to determine the right pattern like for form validation. I feel they're working moderately well as I've seen them being referenced to others when questions arise. However they're just static right now, and I'm wondering if making them more interactive would make them more meaningful.
17	No	The DS we were building and maintaining was being consumed by more mid/sr designers and we had to trust that they knew their best practices and would choose wisely and our DS team was small so didn’t have time to prioritize documentation like decision trees. But I teach students new to DS systems and they benefit from them a lot or at least I can point them to better documentation
18	No	The last two times I had full control of the design system I was a team of one. If consumers of the design system had any questions they were more likely to ask me directly than to read documentation. I would have preferred they didn't come to me first, but with a small group of consumers they thought it was easier. I found it stressful.
19	Very limited use, but would like to implement more. For a majority of our components we have "when to use" and "when not to use" guidance that will suggest other components.	We have limited use, and more around choosing implementation options than the component itself (like choosing disclosure vs. combobox). I'd like to have more of them, but also consider the perception that using everywhere makes it feel like each decision is more complex than it may need to be. Would like to discuss how to balance this better.
20	No	We have when to use and not to use section but haven't tried a decision tree yet. Its hard to balance the amount of content to put out as evidence comes back people aren't using it.
21	No	A federated design system model. Without a dedicated hierarchy of ownership, anyone can make any changes at any time to the design system. Somewhat recently we had (1) a senior designer change an entire set of map components because he just had a preferred aesthetic and (2) stakeholders have insisted on overhauling and changing to UI that mirrors Google Drive. It's basically negated the whole point of having a design system. Documentation in this space is minimal because no one has time to do it (we've surveyed the team and this is the sentiment). But even if someone were to create a decision tree, I don't trust following it since anyone can go in and change it on a whim. Or still do whatever they want differently in their product, ignoring the decision tree altogether.
22	No	A decision tree appears impossible to document and maintain, like writing a 'Choose Your Own Adventure' book but for every conceivable scenario. https://medium.com/everything-80s/the-story-behind-the-choose-your-own-adventure-books-be214f3d4bf4
23	No	I would love to learn about them!
24	No	More experience design support and clear POV would help us make these. We do have some for governance / intake processes that the PM owns, mostly effective at high level alignment but have seen less use in practice.
25	No	Our documentation does feature "use this component for these purposes..." but we don't see a lot of value in decision trees, so far. I think in our org the main issue is not which components to use when, it's usually done ok, but more about using components together in "creative" way, yet no so great from a UX perspective.
26	No	We use Storybook for our documentation. Even though you can add notes for components, no one really does. We don’t have anyone who owns the documentation. When we first started the design system, we had separate documentation that the design team made, but we got rid of it because no one was using it. We don’t have much written guidance on how or where to use components.
27	Have not needed to yet	It has not come up yet to require me to make a decision tree. Still new to design systems and learning
28	I've used a decision tree internally within the design system team to support naming components and elements.	At this earlier stage in the product, we've been focused on producing components and individual guidance. We've made some information architecture decisions for the ds website that support the user identifying and choosing the right component. We could do more in this regard. A decision tree seems like it could be useful behind the scenes to guide pattern guidance. Interested in the relationship between component taxonomies and decision trees. I like the idea of integrating a decision tree mental model: applying the principles and decisions conceptually in a similar way. Given that a decision trees are larger visual flows, I'd be concerned about adapting them for use with assistive tech. I'd like to understand more about how a decision tree would fit into content so it's available where and when someone needs it. Would it be frontloaded? How it might a decision tree work with (or instead of) a "related components" or "suggested components" section? Could it be integrated into a filtering interaction for components?
29	We use decision trees to help them decide on whether or not they should contribute a component/pattern/enhancement/bug fix	It was a group effort between Content, UX, and UXEs re who created the decision tree. It seems to sometimes help consumers, but it's also questionable if they actually use the decision tree include in our documentation.
30	I've used decision trees to guide designers toward choosing a component of the system, and what to do if a component doesn't exist or does not meet their needs.	As the design system lead (on the design side), I've typically created decision trees in the past as part of our adoption/contribution workflows. We modeled some of the early stuff after things we'd seen Brad Frost doing. While these artifacts were somewhat useful in the context of a conversation, I found that designers rarely used them unless we showed the decision tree to them during a conversation. There are often multiple components that are very similar in nature and would benefit from a type of decision tree to help users decide which to use. One that often comes up is Toggle vs. Checkbox. I'm intrigued to hear how others are using these types of tools!
31	No
32	No	We’ve used decision trees to inform design system contributors whether their feature belongs in the system or not, but we haven’t used them to help people choose which component to use. I’d be very interested in using them to help our designers choose the right element early on.
33	No	I’m excited to learn about design system decision trees! As we are using something similar in our UX Research group
34	currently in the process of creating a decision tree	other tasks have taken priority so far since the consumers have already created a system to determine which component to use. it would be greatly beneficial to have for new onboards and in redefining how we should be using certain components over the others in a concise way
35	No	No, we're still building our foundation and moving into more nuanced work like this.
36	No	We've used a decision tree to guide consumers in content choices.
37	No	Not familiar with these, would love to know more.
38	No	We honestly haven't created any yet because it hasn't been a topic of discussion or priority for our team yet.
39	We've starting exploring decision trees as we're seeing inconsistent use of components.	Capacity has prevented us from creating them and priorities being elsewhere. I think it will be helpful for our consumers as we constantly see designers ask for feedback in crits about 'which do you like better' when choosing between form components eg radios, toggle buttons, tile buttons etc. Having decision trees will (hopefully) eliminate the need for designers to do this, especially as our UX designers are now learning the UI side of design more and our team gravitates to Product Designers as opposed to specialist roles.
40	Yes	I create them. Designers greet them with a general sense of apathy, only sometimes appreciating when they answer a specific usage scenario (e.g., single select: when to use radio vs select). Engineers gobble them up; they love them.
41	Not yet, but we hope to.	We're not using them yet.
42	No	What's kept us from doing this is capacity. We have a small team and other priorities. We let our documentation and designers help with the decision making on what should be used. I think they would be helpful for 1) engineering users that are not as skilled in frontend and don't have UX support; 2) for scenarios to help all users know when to use a modal versus a dialog versus a drawer as an example; 3) it could also help the DS team in refining our offerings...Do we need a menu and a dropdown component or can it just be one? How do we differentiate use cases between what is an alert message component versus an application notification and ensure our users are using them correctly?
43	No	Not yet. I love them, and have them seen them used really well in other systems, but we've found success including component comparison matrices in our documentation site. I'm curious to learn how teams who use decision trees think about maintenance or upkeep they require.
44	No	We leaned on documentation to help consumers decide which component to use, and decision trees for helping decide when to use something that exists, propose an update to something existing, propose a new component, or test at the product level vs system level.
45	No	I didn't know it was a thing, but it seems obvious now. Interested to see how they are implemented.
46	No	We just havent gotten to this level of documentation in our system yet, but definitely see the value of having decision trees as a way to better provide the answers vs longer form documentation
47	No	I haven't considered it and need to learn more about decision trees. Please provide some examples and recommended tools for creating decision trees.
48	Yes	We've made one for different notification methods. One of our designers made the tree for our documentation website when we introduced toasts.
49	No	No time
50	No	We don't use a decision tree, but we have tables that compare similar components and when to use each. It might be worth A/B testing whether a decision tree would be more useful, though.
51	No	Our design system is currently in development. I LOVE the idea of using decision trees to standardize decision making. This also seems like a good way to standardize at least an initial approach to documentation. I’ve never used decision trees in design myself so I’m very curious to learn more :)
52	I am trying to get buy-ins from my design team to build one	I think if we don't have designers to lead this decision tree effort, they might be reluctant to follow through with it in their design.
53	Yes	Product Design + Content Design
54	No	Sounds like a great idea to help improve content consistency and better quality application of components. I’m keen to learn more around this.
55	No	No because our focus/concern right now isn't really on whether designers are using the design system right or wrong. We're still focusing on building out our design system and expanding it to support additional teams' use cases. In addition, most teams are creating totally new features & experiences that we don't want to necessarily be limited by conforming to only using existing patterns that weren't originally built for that intended use case. Our guidelines right now are for designers to utilize our existing design tokens and atomic components. In the future when there are more larger patterns/components built out, then it probably makes more sense to create a decision tree.
56	The usage of component decision trees is very much a proof of concept.	The few component decision trees the team had were created by designers.
57	No	In past experiences as a content designer, time has prevented me of course. BUT I do think it's crucial to organize design systems by applied scenarios in some cases rather than by asset types. Could absolutely see them being helpful to drive compliance / adoption.
58	No	I’m not sure, I want to learn about these decision trees!
59	We have decisions trees in our documentation but it's rarely around component usage	I am as the tech lead with support from designers. I'd like to have more of them but there is legacy tech debt in our components that create nuances that would make the trees complex
60	No	I think we never thought about them as a tool that might help us. It would definitely help us reduce decision anxiety, and won't let opinions get in the way of these decisions as often.
61	No	I made some decision trees to know if we have to create a new component, but not one to choose the right component. I prefer to use the Decathlon approach with their Vitamin Design System of the alternative components or « which other components should I use » which is a very similar approach. I don’t think that DS consumers will take the time to check a complete decision trees, and I think that they’ll prefer a contextualized decision making aid.
62	No	Infinity branch of decisions.
63	No	I think adding decision trees would be a great idea, but we just haven't had the resources to tackle it yet.
64	We have a governance model which is essentially a series of questions to get to whether components should be built at the product or system level, but decision trees feel a bit different.	Our mighty team is tiny, so the only thing holding us back is team size. Docs could currently use a lot of love before we consider something as cool as decision trees.
65	No	CVS did not use fully automated decision tree, but did include in documentation when to use specific components and when not to, the issue became that that documentation was not found or followed, so experts were also made available to manually guide decisions (which lead to more engagement, at the cost of time/resources)
66	No	I'm picturing decision trees as a flow chart – and in general, I just don't like them as they can be quite sterile. However, I hadn't considered them yet in the context guiding designers in design systems to choosing the right path. Excited to learn more.
67	No	We've used a simple decision tree to guide consumers on how to interact with the system when they are designing something new. But it was more about "does it exist in the system? "If not, what to do next" "If so, but it's not a 100% match, what to do next". I can see offering decision trees that are pattern/component-specific may be useful! Especially if they are more concise than the documentation itself and as such can help consumers work faster. Documentation can be very wordy, and we all know many people don't bother reading.
68	No	We haven’t reached that point in the DS yet. We’re just starting to build out the documentation, but we’re really excited to gather information on how to best build these trees for our DS consumers.
69	No	It's been brought up, but never accepted or adopted as a direction or approach/tool. As the system I was working on evolved, the org has moved away from documentation generally. The party line is that everything moves/needs to move so fast that there isn't time for it, but I think there's also an ownership question at play.
70	We have them, but we arectivly trying to move away from them.	These were created by our design team and I totally understand why. When working in a design tool, you need to visually represent different user experiences and that often results in separate components for each visual representation (even though they may be functionally the same). Unfortunately, these have lead to confusion as well as frustration with our developers because they don't have the right combination of features. Instead, we are working on consolidating similar components with properties users can use to enable specific features.
71	Not yet, but I'm working on the first one as we speak!	n/a
72	No	For some reason design system users just directly use whatever there in the library and make their own if sth doesn‘t exist. So that‘s why I‘ve also never thought of usibg decision tree for this scenario.
73	No	I have been working on them a little
74	No	N/a
75	Yes	Decision trees are usually informed by the functional group (design, engineering, content, product lead) with the systems team working through the documentation. Generally they work well. For less consequential decisions they're efficient but for more complex or nuanced scenarios, we encourage collaboration. We also consider heavily the decision's potential impact on outcomes. I worked closely with a data partner who helped our team set up non-inferiority tests for systems components and visual elements and including the resulting data in our documentation proved helpful.
76	Yes	Our design system is new but as we’ve completed some key components and are starting to define patterns, we’ve started creating decision trees. We work as a trio, design system designer, UX writer and lead UX designer. Like I said, we’re in the early stages, but it seemed like the easiest way for the users of the design system to consume the important parts of documentation and easily figure out which components to use in their designs.
77	Yes	I have only created one (I'm the DS designer) for choosing the right variant of a component and designers love it! I got a lot of good feedback that it made it easier to know what to use
78	Yes	Usually it's part of the documentation process, in each usage guideline there is a section of "use X or Y?" and we crosslink to other components as needed. We tried doing a unified flowchart, nobody bothered, they're far more comfortable finding the nearest component and then trawling through the X or Y links to get to the one that they need. -Arko
79	No	I think we just aren’t aware or educated on decision trees!
80	Yes	We only have a few and they stand out in the documentation a being really helpful I don't know who will be able to create more, I'm interested in ways of streamlining that work. Can AI do it for me?
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100