?? 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.
As always, you can find more design patterns in Smart Interface Design Patterns ??? — with a shiny new live UX training coming up later this year. Use the coupon code LINKEDIN ??? to get 15% off.
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.
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 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:
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.
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 .
领英推荐
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.
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.
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! ????
Meet?Smart Interface Design Patterns
This section is an upcoming part of Smart Interface Design Patterns , a friendly 10h video library ?? and a live UX training with live sessions, real-life UX challenges,?personal 1:1?feedback?and?UX certification. Ah, use the coupon code ?? LINKEDIN to save 15 off.
Thank you so much for your support, everyone —?and happy designing! ????
Product Owner of Eletro Design System | Design Ops | Design System
1 周Sophia Machado
Product Owner of Eletro Design System | Design Ops | Design System
1 周Leonardo Fagundes Benevides muitas ideias de decision tree que podem nos ajudam a entender melhor qual componente precisamos para tal situa??o.
Lead UX/UI Designer | SaaS | Product Design | E-commerce | 7+ Years Experience
3 周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?
Product Designer
5 个月Insightful!
Senior UI Designer at THE ICONIC
5 个月Brilliant documentation and decision making method! ????