Hot take for my fellow design system folks: adoption is not the goal. Neither is consistency. The goal is a coherent, high-quality user experience, delivered efficiently. Adoption and consistency are usually how we get there, but they're means, not ends. When we confuse the two, we start measuring the wrong things and defending the system instead of serving the people who use it. Consistency is a great default. But rigid consistency can actively get in the way when a product has genuinely different needs. A data-dense internal tool and a consumer onboarding flow shouldn't be forced into the same mold just so a dashboard can report 100% component coverage. This changed how I think about resistance. When a team won't adopt the system, I've stopped treating it as opposition. I treat it as information. In my experience there's almost always a legitimate reason behind it. Maybe the components don't fit their use case. Maybe migrating would eat a quarter of a roadmap they're already behind on. Maybe the system is missing something they need. Or maybe they tried it a year ago, it broke something, and they haven't trusted it since. Every one of those is feedback. Every one of those is a chance to make the system better. The fastest way to lose a team is to show up with a mandate. The fastest way to win them is to show up curious: "What's not working for you?" A design system earns adoption by being genuinely useful. If people are routing around it, the system is telling you something. Listen. www.forresttindall.com