🌳 Decision Trees For UI Components
Decision tree flowcharts for UI components, by Doctolib's wonderful design team.

🌳 Decision Trees For UI Components

How do you know what UI component to choose? Decision trees offer a systematic approach for design teams to document their design decisions. Once we’ve decided what UI components we use and when, we can avoid never-ending discussions, confusion and misunderstanding.

Let’s explore a few examples of decision trees for UI components, and how we can get the most out of them.

Meet Design Patterns For AI 🔮 and How To Measure UX 🍎friendly UX courses with practical techniques for product designers and UX leads. Use code 🎟 NOVEMBER to save 20% off today.

B2B Navigation and Help Components: Doctolib

Doctolib Design System is a very impressive design system with decision trees, B2B navigation paths, photography, PIN input, UX writing and SMS notifications — and thorough guides on how to choose UI components.

One of the many decision trees on Doctolib: from B2B navigation to help components.
One of the many decision trees on Doctolib: from B2B navigation to help components.

I love how practical these decision trees are. Each shows an example of what a component look like, but I would also add references to real-life flows of where and how these components are used. A fantastic starting point that documents design decisions better than any guide would.

Decision Tree For Notifications Messaging: GitHub

GitHub has published a decision tree for notifications messaging, a little flowchart on how to choose the right notification type — modal, banner, inline message, progress updates, error message — communicate an error, an event or updated information. Discovered in GitHub design system, via Charlotte Hadley and Adam Silver.

Success messaging flowchart 
Is the success of the action evident on the page? If yes, Additional visual messaging not needed, but state must be conveyed to screen reader users. If no, Is the action a results of pressing a save or submit button? If no, display success in a Banner or inline messaging on the page in a logical place. Link to newly created item if needed. If yes, Does pressing the save or submit button take you to a different page? If yes, Is success is not evident from the change in URL, display a Banner indicating the success. If no, Display InlineMessage in close proximity to the save button.
Error messaging flowchart 
We know what went wrong branch 
Do we know what went wrong? If yes, is the error in a form or a text input? If yes, use Primer form validation guidance. If no, Is the error from a failed drag and drop action with a mouse? If yes, Use a simple modal error dialog that can be dismissed with close button or click-outside. Include guidance to correct the error

While on it, I'd love to also point out a very helpful section on "Degraded experiences", which lists "fallback" design patterns — to ensure that a page still renders and primary experiences are still available during downtime of optional service dependencies. A fantastic section that's often forgotten or overlooked.

Decision Trees For UI Components: Workday

The team behind Workday’s Canvas design system created a fantastic set of design decision trees for notifications, errors and alerts, loading patterns, calls to action, truncation and overflow — with guidelines, examples and use cases, which can now only be retrieved from the archive:

"Decision Tree for What Notification Should I Use?" Top of chart begins Q: "Is action required?" If “Yes” to Action Required, then Q: Is immediate attention required? If “Yes, immediate attention is required”, then “Use a Modal component” If “No, immediate attention is not required”, then “Use a Banner” If “No” to Action Required, then Q: Does the notification communicate status? If “Yes, notification communicates status”, then “Use a Toast” If “No, notification does not communicate status”, then Q: Is the notification an alert? If “Yes, the notification is an alert”, then Q: Can the alert be easily dismissed? If “Yes”, then “Use a Toast” If “No”, then “Use a Banner” If “No, the notification is not an alert”, then “Use a Dialog component”
A decision tree for the selection of a notification type.
“Decision Tree for What Button Should I Use?” Top of chart begins Q: "Is the Button the main call to action?" If “Yes, this action is the primary CTA”, then Q: “Do you need an icon to reinforce the action?” If “Yes”, then Q: "Do you have space available?" If “No, space is limited”, then “Use a Primary Button” If “Yes, space is not a concern”, then “Use a Primary Button with Icon Right or Left” If “No”, then “Use a Primary Button”  If “No, this action is important but not critical”, then Q: “Is the action relevant to the primary CTA?” If “Yes, action is related to the primary CTA”, then Q: "Does the action require a lot of emphasis?" If “No, this action does not require a lot of emphasis”, then “Use a Tertiary Button” If “Yes, I’d like to really emphasize this action”, then “Use a Secondary Button” If “No, action is related to the page/contents of the page”, then Q: “Does this action require a lot of emphasis?” If “No, very little emphasis is needed for this action”, then Q: “Do you have space available?” If “No, space is limited”, then “Use a Tertiary Icon Button” If “Yes, space is not a concern”, then “Use a Tertiary Text Button” If “Yes, this action should be emphasized”, then “Use a Secondary Button”
A decision tree for the selection of a call to action.

For each decision tree, the Workday team has put together a few context-related questions to consider first when making a decision, before even jumping into the decision tree. Plus, there are thorough examples for each option available as well and a very detailed alternative text for every image.

Form Components Decision Tree: Lyft

A choice of a form component can often be daunting. When to use radio buttons, checkboxes or dropdowns? Runi Goswami from Lyft has shared a detailed form components decision tree that helps their team choose between form controls.

A decision tree for form controls: notably, use dropdown as a method of last resort, with many long options.
A decision tree for form controls: notably, use dropdown as a method of last resort, with many long options.

We start by exploring if a user can select more than one option in our UI. If it’s indeed multi-select, we use toggles for short options and checkboxes for longer ones. If only one option can be selected, then we use tabs for filtering, radios for shorter options, switch for immediately applicable options, and checkbox if only one option can be selected. Dropdowns are used as a method of last resort.

Choosing Onboarding Components: NewsKit

Onboarding comes in various forms and shapes. Depending on how subtle or prominent we want to highlight a particular feature, we can use popovers, badges, hints, flags, toasts, feature cards or design a better empty state. The Newskit team has put together an Onboarding Selection Prototype in Figma.

A decision toolkit for onboarding UX: the more integrated the onboarding is, the more effective it is.
A decision toolkit for onboarding UX: the more integrated the onboarding is, the more effective it is.

The choice depends on whether we want to interrupt the users to display details (usually isn’t very effective), show a feature subly during the the experience (more effective), or enable discovery by highlighting a feature within the context of a task a user tries to accomplish.

The toolkit asks a designer a couple of questions about the intent of onboarding, and then suggests options that are likely to perform best. A fantastic little helper for streamlined onboarding decision.

Design System Process Flowcharts

How do you decide to add new component to a design system or rather extend an existing one? What’s the process for contributions, maintenance and the overall design process? Some design teams codify their design decisions as design system process flowcharts, as shown below.

The design system maintenance process by British Gas design system.
The design system maintenance process by British Gas design system.

And here are helpful decision trees for adding new components to a design system:

Make Decision Trees Visible

What I absolutely love about the decision tree approach is not only that it beautifully visualizes design decisions, but that it also serves as a documentation. It establishes shared standards across teams and includes examples to follow, with incredible value for new hires.

Of course, exceptions happen. But once you have codified the ways of working for design teams as a decision tree and made it front and center of your design work, it resolves never-ending discussions about UI decisions for good.

Article content
The entire process at GitHub summarized as a flowchart.

So whenever a debate comes up, document your decisions in a decision tree. Turn them into posters. Place them in kitchen areas and developer’s and QA workspaces. Put them in design critique rooms. Make them visible where design work happens and where code is being written.

It’s worth mentioning that every project will need its own custom trees, so please see the examples above as an idea to build upon and customize away for your needs. Happy decision planting, everyone! 🎉🥳


🥁 Just Released: Design Patterns For AI

Article content

Meet Design Patterns For AI Interfaces 🔮 — a brand new video course (10h) with me on design patterns for AI products, with 100s of real-life examples, live sessions, practical techniques and everything designers need to know to design AI experiences that people understand, use, value and trust. Ah, use the coupon code 🎟 NOVEMBER to save 20% off today. Jump to details.

Thank you so much for your support, everyone — and (as always!) happy designing! 🎉🥳



Leonardo Fagundes Benevides muitas ideias de decision tree que podem nos ajudam a entender melhor qual componente precisamos para tal situação.

This is such a valuable resource! I love how decision trees simplify complex design decisions and promote consistency across teams. It’s a great way to onboard new team members too! I’m particularly interested in the Error Design Decision Tree, errors can be tricky to navigate. Have you found any common pitfalls when implementing these trees in teams?

Like
Reply

Brilliant documentation and decision making method! 🙌🙌

Like
Reply

To view or add a comment, sign in

More articles by Vitaly Friedman

  • 🧠 How To Reduce Cognitive Load In UX

    People are complex. We are often impulsive, and typically juggling between dozens of things at the same time.

    15 Comments
  • 🎯 Six Key Components of UX Strategy

    For years, “UX strategy” felt like a confusing, ambiguous, and overloaded term to me. I would be asked to draft a…

    19 Comments
  • Your vs. My? UX Writing Guidelines

    When you design an interface, which pronouns do you usually use to address your users? Do you write “My account” or…

    30 Comments
  • Why Stakeholders Resist Your UX Work, And How To Fix It

    You've probably been there before. You might have spent weeks iterating on an idea that tackles one of the most…

    13 Comments
  • 🪴 Design Patterns For... Almost Everything!

    If you are anything like me, you might also find yourself getting lost in your bookmarks — searching for just the right…

    46 Comments
  • 🌟 UX Job Interviews Playbook

    When talking about job interviews for a UX position, we often discuss how to leave an incredible impression and how to…

    15 Comments
  • 🍞 Toasts & Snackbars UX Guidelines

    Toasts and snackbars might seem like a simple component to design, but they come with plenty of usability challenges —…

    17 Comments
  • 🧠 How To Name Things

    Naming is hard. Language we use shapes the way we think about things, but also the conversation we have about it.

    27 Comments
  • 🐌 Why Is Everything So Slow In Large Companies?

    If you work in a large organization, you might find yourself puzzled by how slow and seemingly inefficient they can be.…

    19 Comments
  • 🌟 Data vs. Findings vs. Insights in UX

    In many companies, data, findings and insights are all used interchangeably. Slack conversations circle around…

    15 Comments

Others also viewed

Explore content categories