Codifying UI Decisions With Decision Trees
Choosing the right UI component for a given context is often harder than it looks. Teams can spend hours debating whether a dropdown, a set of radio buttons, or a toggle is the correct pattern. Decision trees offer a systematic way to document these choices so that once a decision is made, it can be reused without reopening the debate.
A well-structured decision tree captures the conditions under which a component should be used, making the reasoning visible and accessible to designers, developers, and new hires alike. Below are concrete examples from companies that have turned this practice into part of their design systems.
Component Selection Guides: Doctolib
The Doctolib Design System (“Oxygen”) publishes a set of practical decision trees that cover a wide range of UI decisions, from form fields to error messages and help components. Each tree is accompanied by visuals showing what the component looks like, which helps teams understand the trade-offs at a glance.
- B2B Navigation Patterns Decision Tree
- Form Components Decision Tree
- Actions and Calls To Actions Decision Tree
- Error Design Decision Tree
- Help Component Decision Tree
Where these trees shine is in their practicality. Adding references to real-life UI examples and flows of where and how these components are used would make them even stronger documentation than typical design guideline pages.
Context-First Trees: Workday Canvas
Workday’s Canvas design system previously offered a comprehensive set of decision trees for notifications, errors, alerts, loading states, calls to action, truncation, and overflow. Those pages are now only available through the Internet Archive, but the approach remains instructive.
- Notifications Decision Tree
- Errors and Alerts Decision Tree
- Loading UX Decision Tree
- Calls to Action Decision Tree
- Truncation and Overflow Decision Tree
The Workday team paired each tree with context-related questions to consider before entering the tree itself. That pre-step is a valuable habit: it forces the team to clarify the user’s situation before jumping to a component recommendation. Each option in the tree also came with thorough examples and detailed alternative text for screen readers.
Form Controls: A Lyft Example
Form controls are a classic source of confusion. When should you use radio buttons, checkboxes, or a dropdown? Runi Goswami from Lyft shared a decision tree that helps teams navigate precisely this choice.
The tree starts by asking whether the user can select more than one option. For multi-select, toggles work for short options while checkboxes are better for longer ones. When only one option is allowed, the context narrows further: tabs handle filtering, radios suit shorter option lists, switches apply immediately, and a single checkbox works when there is a binary choice. Dropdowns should be considered a last resort in this framework.
Choosing an Onboarding Pattern: NewsKit
Onboarding can range from subtle hints to prominent interruptions. The choice depends on how the team wants to stage the feature: interrupt users to display details, show a feature subtly during the experience, or enable discovery by highlighting a feature within the context of a task users are already attempting.
NewsKit has published an onboarding selection prototype in Figma that walks designers through this thinking.
The toolkit begins by asking about the intent of the onboarding, then suggests components that are likely to perform best in that scenario. This is a lightweight yet effective way to enforce consistency across onboarding flows without requiring each designer to re-litigate the same decision.
Process and Governance Trees
Decision trees aren’t only for end-user components. Several teams codify their internal contribution process as well, defining when to add a new component versus extending an existing one. These process flowcharts typically sit at the heart of a design system's governance documentation.
- Contribution Process at British Gas
- Contributing Guidelines at Nordhealth
- Processes at Aviva
- Contribution Process at OpenCollective
- Contribution Process at Zalando
Teams also publish decision trees specifically for when a new component should be introduced:
- New Component Decision Tree at Boston Scientific
- Handling New Patterns at GitHub
- Design System Governance Process by Brad Frost
- New Component Decision Tree by Louis Ouriach
- Design System Contribution Template by Chad Bergman
- How To Launch A New Component plus a Figma template by Rama Krushna Behera
Documentation Everyone Can See
The real value of a decision tree is that it doubles as living documentation. It formalizes shared standards, includes examples to follow, and shortens the learning curve for new hires joining an established team. Exceptions will still occur, but having a codified, visible process grounds the discussion and stops subjective preferences from dominating the conversation.
Printed posters in kitchens, developer or QA workspaces, and design critique rooms keep the decisions front and center.
Make them visible wherever design work happens and wherever code is written. Keep in mind that each project will need its own customized trees; treat the examples above as starting points to adapt rather than ready-made solutions.
