I’m done building components. 🙅
This feeling was already strong for me. Teams are always in need of their own components for experiences that are unique to the platform. That means they need their own infrastructure for component development. These get built in isolation and don’t have the same level of communication that components in the core design system would have. This is something that a design system can’t stop and really shouldn’t stop.
That’s why I see a future in the “component marketplace”, where all components are meant to be built which gives visibility not only across teams who want to use existing resources other teams have built but for leadership to clearly understand the landscape of their design language. Its consistency or its lack thereof. This would require some sort of desire for teams to start building on the marketplace. Maybe it gives them auto-docs or a testing harness that is easy to use. Maybe it gives them metrics into how people are using their stuff. Maybe there’s some other attraction that I’m overlooking.
I know what you’re thinking, this is how we get a dozen different buttons across the organization because anyone can put them there. And that’s the point. If the organization wants all of those buttons, they can have them. And that’s often how a design system starts. We do the classic “button audit” find that there’s 12 different kinds and the design system team is born. But what if that audit was not a moment in time, but a dashboard? What if your design leadership could open it up at any time and decide if this was acceptable?
I think this visibility and access would clearly describe the behavior of design leadership. Organizations that want consistency would take actionable steps against the resources found in the marketplace, potentially sending out their design systems team to work with those creators for alignment. On the flip side, organizations that don’t care will continue not caring and it’ll show very clearly. Until then, design leadership can blissfully hide behind not having enough resources to do the audit and no one can be sure there are inconsistencies at all. 🫣
The last straw
This past weekend, my disdain for building components was solidified. I realized what a definitive difference is between a design system and a component library was.
I’ve always said that a design system is a matter of agreement. It’s what the organization collectively agrees should be the overall strategy when it comes to design. However, what happens when that agreement is objectively wrong? This can be compounded by larger organizations proudly displaying poor choices. Those choices are replicated and then defended by the bandwagon effect. This results in a component library. They’re just components based on feelings. People want components, so they get components.
Does a design system have a component library? Sure, but the difference is the thoughtfulness of their inclusion. Is it easy to make your own button? Sure, but it probably doesn’t account for the 3-part blog post published by Adobe Spectrum about handling touch devices due to various browser inconsistencies.
But who cares right? The deadline is tomorrow, and you just need a button that LooksGood™. You have no time to understand all that goes into it. You just see that it isn’t exactly the button that you need so you make your own. How hard could it be? It works on my machine and everyone uses a Mac 16” Pro Ultimate HD Max (I have no idea what the names of these things are). Button #13 is born.
That’s why I’m now making a clear distinction between a component library and a design system. The collection of various shiny objects and the thoughtful curation of related usable resources.
Importantly, just because thought was involved doesn’t immediately make it a design system. You could think that a certain use-case is an exception, but oftentimes that’s where the thinking stops. The design system is meant to have the resources to take all of the information and synthesize it down to the perfect component. Realistically, we don’t have resources to do this. Either we don’t get the time, cooperation, or complete requirements. It’s garbage in and garbage out. No wonder people are losing faith in design systems.
But I haven’t. That’s why I’ve dedicated my free time to them because I’m confident there are perfect versions of them. Versions that could work for everyone. And continuing to copy existing systems strapped for resources themselves isn’t where we’ll find improvements. We need to pivot for universal solutions.
This is because I’m a user too. And every time I visit a site with wild inconsistencies and poor usability I know I have the experience to make an impact and you can too. 💪