Design Systems for Consistency

🌳 Doctolib Healthcare Design System (B2B + Decision Trees) (https://lnkd.in/e5Q_w5DU), 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. B2B Navigation Patterns Decision Tree https://lnkd.in/eE88VQrH Form Components Decision Tree https://lnkd.in/e9SG6hRv Buttons vs. Links Decision Tree https://lnkd.in/eW8w-RkJ Error Messages Decision Tree https://lnkd.in/eJqWRzve UX Writing Decision Tree https://lnkd.in/e2g_E_dt Help Decision Guide https://lnkd.in/e-T8X9iJ What I absolutely love about this 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 practical examples to follow. Of course exceptions happen. But once you have codified the ways of working for design teams as a decision tree, and make it front and center of design work, it resolves never-ending discussions about UI decisions for good. Whenever a debate comes up, document your decisions into a decision tree. Turn them into posters. Place them in kitchen areas. Developer’s and QA workspaces. Put them in design critique rooms. Make them visible where design and coding work happens. Yet again, HUGE kudos to the wonderful Doctolib team Jérôme Benoit Reveau, Michaël Blancon Tardi, Nicolas Declercq, Victor Michaud, Hélène🔸 Pruvot, Matthieu Vignolle, Emyly Võ, Flavie Journet, Alizée Roubach, Chloé Thibaux for putting it all together 👏🏼👏🏽👏🏾. Every project will need its own decisions, so please use these trees as a starter to build upon and customize away for your needs. ✤ More resources: Notifications Decision Tree (Workday) https://lnkd.in/dDdaWTNQ Errors and Alerts Decision Tree (Workday) https://lnkd.in/dyvF9gsV Loading UX Decision Tree (Workday) https://lnkd.in/dWyhsZF4 Calls to Action Decision Tree (Workday) https://lnkd.in/d3hM65tP Truncation and Overflow Decision Tree (Workday) https://lnkd.in/dGsA3FMb Onboarding UX Decision Tree (NewsKit) https://lnkd.in/eWn5FPWA Checkbox vs. Radio Buttons (Lyft) https://lnkd.in/e4NM5sgk All Decision Trees, in one article https://lnkd.in/ejjEhK6y Happy decision planting, everyone! 🎉🥳 #ux #design

I have spent hundreds of hours analyzing design systems. One of the things that confused me for many years is how to structure color scales and tokens. I have experimented with multiple structures at different sizes of design systems, and at a high-level recommend the following approach: 1. Primitive Colors Your design system foundations should always start with a full color scale that is based on your brand identity. We call these colors Primitives, and your variable/token collection should look like this: - purple-600 - purple-500 - purple-400 - And so on.. To create a Primitives palette you will want to start from your main brand colors and use a tool like UIColors, Supapalette, Colorbox to expand to the full scale. (links in comments) This is a great foundation to have, as it gives you a set of shades that can be used in different ways, and ensures all of them have consistent hues, saturation and brightness. However, Primitive colors are simply not effective when used directly in your designs: - They create ambiguity - Their names have no contextual meaning - They are often misused due to similarity If you have had the “why are there 20 different shades of gray?” conversation with an engineer, you know what I mean. So let’s see how we can improve that. 2. Semantic Colors This is my default recommendation to all product design teams that don’t have a highly complex design system. What you will want to do here is create a new variable collection named Semantic, which is what’s visible in your design files, and comprises of: - Brand / Action - Text - Link - Border - Icon - Surface / Background - Bias - Data / Charts Each color should point to a primitive value, e.g. - text-primary → gray-800 - text-secondary → gray-600 - text-tertiary → gray-400 This takes a bit of setting up, but creates immense long-term value. A great example of a simple, theme-level Semantic structure is Shopify’s Polaris (link in comments) 3. Component-level Semantic Lastly, if you are working on a design system with a lot of complexity and, ideally, a dedicated design systems team, you might want to add another level of hierarchy and specify colors at a component-level. In this structure, you would want to create color tokens based on how they are used in each component. - input-text-filled → text-primary - input-text-placeholder → text-secondary - input-text-disabled → text-tertiary This eliminates all guesswork, but also increases the complexity exponentially. It does serve a purpose though. As design systems scale, you may find that: - A theme-level semantic structure is too restrictive - There is still some guesswork - Decisions need to be documented. An example of this is Uber’s Base and Adobe’s Spectrum design system, linked in the comments. I’m curious to know, what structure are you using for your design system and what has worked well for you? — If you found this useful, consider reposting ♻️ #uidesign #designsystems #productdesign

You have done this a hundred times. You try to plug in a USB. It doesn't fit. You flip it. Still wrong. You flip it back. Finally it goes in. Annoying. But notice something. You can only plug it in the right way. The wrong way is blocked. That is not an accident. It is a 60-year-old idea from a Toyota factory, and it has a name: poka-yoke. In plain English, mistake-proofing. It came from a Japanese engineer named Shigeo Shingo in the 1960s. He noticed workers on one line kept forgetting to put a tiny spring under a switch button. Every manager's first instinct is the same: tell people to be more careful. Retrain them. Maybe write them up. Shingo did the opposite. He changed the process. Instead of grabbing each spring directly, workers first placed the springs in a small dish. Then they took each one from the dish into the product. Now if a spring was left in the dish, anyone could see it instantly. Defects dropped to zero. Overnight. No extra training. No blame. He first called the idea "baka-yoke," which means fool-proofing. Then he dropped that name. Calling workers fools, he said, was the wrong way to think. Everyone makes mistakes. A good system catches them. Here is the useful part. Shingo said you can mistake-proof almost anything in one of three ways. Worth keeping somewhere: 1️⃣ Make it physically impossible to do wrong. Shape it so only the right way fits. (The SIM card. The USB. The diesel nozzle too wide to enter a petrol car.) 2️⃣ Make the right count obvious. Set it up so a missing or extra piece shows at a glance. (Shingo's dish of springs.) 3️⃣ Lock the steps in order. Build it so a step cannot be skipped or reversed. (The ATM that returns your card before it gives you the cash.) Notice what all three have in common. Not one of them depends on people trying harder. They depend on better design. So before you retrain someone for an honest mistake, ask one question: ⁉️ Could I redesign this so the mistake simply cannot happen? That single question is one of the quietest superpowers in Lean and Six Sigma. Now I would love your help with something. I have only ever seen a small slice of this. What is the smartest piece of mistake-proofing you have come across, at work or in everyday life? Add it in the comments. I want to learn the ones I have missed, and I have a feeling this thread could turn into a brilliant list for all of us. Follow Rahul Iyer for Lean, Six Sigma, Project Management & AI Insights.