Thoughts on a Global Design System

Dave and I just had Brad on ShopTalk Show to talk about his idea for a Global Design System. I love Brad’s optimism on all this. From Brad’s perspective, he’s seen, and helped build, the same set of components over and over over (and over) for design systems. On a very professional level! While design systems themselves have been a great success for individual organizations (they prevent repeating effort internally and bring consistency though a shared set of components), there is still a lot of repeat work being done across organizations.

I’ve had this thought many times over the years. How many times do developers need to write a <Tabs /> component? (If we can even agree on what Tabs are.) Surely, the world is wasting the brain power of too many smart people solving the same set of problems again and again.

Here’s a smattering of thoughts I had while reading Brad’s article both before and after talking to him about it.

• Isn’t every open-source design system a “global design system”? Aren’t the people making them trying to make them as useful as possible for as many people as possible? If that’s right, and thus they have failed, why did they fail? What are they doing that doesn’t map to the philosophy of a global design system?
• What percentage of organizations is the goal for ideal adoption? Or that could at least theoretically meet the needs of those organizations? It’s not 100% (Brad said so directly) because that would need to solve for every niche edge case there is. It’s also not, say, 50%, as that’s shooting low for something that’s supposed to cover so many core needs. Is it 80%? Where do you have to turn the dial of opinionated-ness to get there? Probably pretty low, right? You can’t dictate the structure of a Dialog or a Card component to get to 80%.
• It seems tricky in that the lower you turn down the dial of opinionated-ness, the less useful you’re making the system. Sure, you’ll get some nice perks, but if you’re leaving people largely on their own to structure markup, you’re delivering less consistency, less design, more potential accessibility fails, and overall less value.
• Maybe a way to summarize those last few points is “does a design system that tries to meet everyone’s needs actually meet nobody’s needs?”
• If there was a perfect component that solved the needs of a ton of people in certain situations… wouldn’t we already be using it because the incentive is there? Is the problem that those components don’t exist yet, that there is no such thing, or that nobody knows about them?
• The closest the world has come to this is probably Bootstrap. It has the quality, the marketing, and the mindshare already. Could this effort be consolidated there? Or is there something Bootstrap is doing that isn’t aligned with this?
• Are Web Components the deliverable? As far as reach goes, it seems like a big winner, as it should work on literally anything web based. Is the styling story of them ready for this? Is the SSR story ready? Is the accessibility and form-participation story ready?
• If it’s Web Components, how close is something like Shoelace already? If that’s not the right direction, why not?
• Is the goal of this system web-only? Or ‘Is the goal of this system web-only? Or will there be an attempt made to be producing components that run in other environments like native mobile or desktop platforms? VR? Point of sale devices? Canvas-rendering systems like Flutter?
• How does this thing get delivered to the people that want it? Do you put it on npm, or is that a problem for any reason? Would you put it on many different package managers to increase reach? Do you just download a .zip file of stuff? Is it just recommendations of copy-pasteable HTML and CSS like Boostrap or Tailwind UI? Is it a CLI tool like shadcn/ui?
• Native HTML, CSS, and JavaScript seems to be evolving to account for more design-system-like usage. We have native accordions now, we have native switches now, we have native dialogs now, we’ve had native datepickers for a while, stylable selects are coming, etc. OpenUI seems very interested in all this. It seems like the intention here is explicitly not to be HTML, but a layer on top of HTML, so perhaps that choice is already clear, but I’d say it bears consideration.
• Unstyled was called out as a requirement of this, because it needs to work for any organization. Coming pre-styled will clash with too many brands and put it in conflict with the goal of being as close to universally useful as possible. But many people pick a design system because of the design it offers, and would be un-interested in an unstyled system. Would themes account for this entirely? Unstyled is another door for accessibility problems, since so many are caused by CSS.
• Can a system without a benevolent dictator avoid becoming the Homer Car? Who says “no, this Menu component will never have an option to detect edges and open in different directions accordingly because it’s outside the scope of our goals?”
• If you’re building a Button component that has very few opinions and no styles, why is that a component at all? Isn’t it just a <button>? But a ButtonWithIcon component is a really common style worth adding, does that become a component, or is it again unnecessary as if you’re largely unopinonated (you don’t care where the icon goes, if there is text or not, etc), then it’s still just a <button>. Is the ButtonGroup complex enough that it’s worthy of componentry? If you compentize all of them, are they composable? Is composability required? Like a ButtonGroup only accepts Buttons? Do you need to build a linter to help with this sort of thing?
• It feels like every decision you make will chip away at who will use it. Say you start out with 1,000 organizations who would use this thing. You make the decision to use Web Components, but 27 organizations just don’t like ’em so they’re out. You’re going to use Lightning CSS to modernize CSS, but 19 organizations can’t fit that into their stack, so they are out. Ninety organizations really just want what they consider to be really slick polished design out of the box, so they are out. Fifteen need a really specific open source license so they can’t do it. There are four organizations that just follow the lead of one that already ruled it out, so they are out. You haven’t finished your Code of Conduct yet so that turned off 8 orgs. What 13 organizations really need is a photo carousel component that has zooming and that’s not really on the roadmap right now so they are out. You’ve decided to go really heavy with CSS custom properties for customization but the way you’ve done it doesn’t slot in nicely with 3 organizations token strategy, so they look elsewhere. On and on.

That feels like I’m being awfully critical. Sorry! Like I said, I like the enthusiasm and I do think there is potential here. But to realize the potential, I think you need to ask really hard questions and have really strong answers. Ultimately I sincerly hope it can be done. Having a super robust go-to set of components that are essentially vetted by the world would be awesome. I think it will take very strong set of principals and leadership to get there.