Recently, Brad Frost wrote an article on his blog to talk about a new revolutionary idea: to create one neutral, super design system shared by every company. The main goal would be to stop producing design systems over and over for each company out there and free designers’ and developers’ time and effort.
This idea split a lot of virtual ink and even led to a podcast episode exchanging ideas around this theme. Between disruptive ideas and killing some time discussing the concept, there is yet no clear future for the super design system. What can be said about it? What are the pros and cons that come to mind when we consider a global design system? Here are my thoughts about the concept.
The idea for a super design system wasn’t formulated by just anyone. Brad Frost is a renowned name in the design community. He is the founder of the atomic design methodology, a way of working that all designers largely adopted. It consists of building interfaces by assembling simpler elements. This logic helps scale apps by modifying core elements of their design system rather than modifying every element one by one.
All principles of this methodology are explained in the best-seller book Atomic Design, available for free online. Working as a web developer in Pennsylvania, Brad Frost has applied his methodology for more than ten years to make design systems from scratch for large companies:
For years, designers had to create and maintain dozens of elements in a design system. Changing the main color of a button would take hours to review and modify every button in an app. By coming up with the atomic design logic, designers upscaled their work and can now modify elements everywhere in a project by modifying one core element. The only cost to do so was to first work on creating a solid design system before working on any product.
The problem is that every company wants its design system. Designers are thus repeating their work again and again for different clients.
Brad frames it like this: “We have a meta-design problem.” His logical answer to tackling this situation and freeing designers all over the world from designing buttons and carousels would be for companies to share one design system and only focus on customizing it through CSS.
Fundamentally, a button is a box with a label inside of it in any design system around the world. And even with something as simple we often find accessibility errors either due to mistakes we’ve made at the creation phase or during a customization phase. Coding one perfectly just once and letting people use it seems logical.
To the general idea, I’d say: why not?
Having one global product that companies personalize afterward to match their brand isn’t unheard of. On-shelf software is basically that. One software focusing on usability pimped to suit a company’s needs.
For example, Amadeus is a company editing an airplane reservation app that is used by all major companies from Japan Airlines to Air Canada. If all airplane apps and websites feel the same, it’s because they are the same, only slightly modified to match each brand’s identity.
The scale of which Brad envisions his idea is huge, and that is the main source of criticism:
The best way to prevent web developers from rewriting HTML to code over and over for the same things would be to make elements like buttons, accordions, and carousels as neutral as possible and let them be accessible to anyone. In one sentence, for the author, it could take the form of a “web component library, maintained by a neutral organization like the W3C.” People could pull every component of the library into their projects and style them.
Brad also thinks of his idea as a new layer over HTML. HTML is a raw material that can become anything. The super design system would be a premade element based on HTML. To give a metaphor, HTML would be like Lego bricks: unrestrained and simple to use but prompt to make mistakes. The new layer is like Playmobil, premade starter packs preventing errors.
What’s funny is that people overreact because one kind of solution was suggested in Brad’s article. Following the design thinking methodology, we should focus on the pain point (not having to remake the design system) rather than on one described possible way of solving that pain point.
The main constraints to note are that:
The idea could and will become multiple solutions at once. To start, it could be just like atomic design becoming a habit for designers. Nothing prevents us from making our own personal, neutral library to copy, paste, and personalize for any project, especially in tools like Figma. That’s already what a lot of UX designers do by using open-source libraries like Material Design as a basis of work. The only problem with that is that the look and feel aren’t neutral and that customizing the components without making a mistake is hard — they were not made with customization in mind.
And just as stated in the initial article, there are probably a lot of projects that are already in progress. This means that multiple solutions will probably be born in a few months. One could use a web component, another could use something else for whatever convenient reason. Nevertheless, it’s important to be doubtful in regard to a large-scope idea like this one — that’s why people are questioning it.
Even if a lot of people see a benefit from this idea being realized, others think it’s useless for multiple reasons. I like that Brad Frost answered some of this criticism, proving that he is aware of the challenges his idea poses.
The first one is that it would be too hard to make. Indeed, designing, coding, and maintaining a universal library possibly used by dozens of companies would be hard work. Not investing enough energy into it would result in a counterproductive project.
Then there is the risk that the new standard just becomes another standard. After all, a lot of companies and NGOs already have open source DS that anybody can use, so why bother? Well, first, because all those companies have a specific look and feel. Using material design is a good basis, but the app will ultimately look like a Google app. The same can be said for Apple’s or Microsoft’s design system. Brad’s goal is to offer something neutral, the simplest possible.
As for the risk of becoming another standard, well that’s a risk, but that’s the point of the new layer above HTML. Being made with html and being highly customizable it should be something different from other open-source design systems. The current problem with open-source design systems is that they are not made to be modified, so many errors occur when we try to fit the brand’s identity in it.
Lastly, one of the main criticisms is based specifically on Brad Frost’s idea. Adding a layer to HTML will just add complexity for nothing. HTML already has a lot of attributes, and guidelines already exist, so why bother? Why should we fix something that works?
Contrary to atomic design, which is just a work logic, a global design system would be something concrete that has to be made by one entity that should then market it so a lot of people use it.
Maybe the idea seems logical but isn’t in the end? As I wrote earlier, we shouldn’t focus on this point. The idea for a super design system was proposed recently. Nobody can be sure what form it will take if it becomes real. We might get another way of achieving this goal without touching HTML:
To this point, with the main pros and cons I’ve cited, what do you think?
The first thing I think after reading Brad Frost’s article is he is the main persona of his idea. Brad, being a frontend developer working on a design system for multiple companies, is trying to become more efficient while killing all boring work in one go. The secondary persona would be UX designers who would have a simple base to work with to construct pages.
My main concern isn’t about the feasibility or even the sovereignty of the project. As said, there are already projects in progress like OpenUI, so we will probably be able to use them in a few years, and I’m sure that counterparts will be made in other big countries like Russia or China.
No, my main concern is … will it benefit people? Even if we acknowledge a new HTML layer and developers can pull them into any project using any coding language, will people keep doing that? The main persona is a professional working with multiple clients with a high level of demand. But we are seeing the rise of new ways of doing things like no-code platforms and AI-generated websites.
Sure, the shared library would benefit highly qualified web developers who have better things to do than coding a button, but coding isn’t a burden if I develop a website with a no-code platform or with AI. I feel like this idea is coming too late to have a disruptive impact on the industry with so many other disruptions underway.
Anyone working in IT and design should aim to simplify his/her work. As Bill Gates said, lazy people are the ones finding the best solution to a problem:
Even if I don’t believe in Brad’s vision, I do really like his idea. For me, the right thing to do now that we have this discussion would simply be to follow a design thinking methodology. Do research; get data on how deep the identified pain point goes; focus on the most prevalent aspect of that pain point; ideate as many ideas as possible; and then let’s design a solution to this problem.
It will most likely not follow the web component library imagined by Brad Frost. In the best-case scenario, we solve a deep problem and invent a new fundamental brick to build things better.
LogRocket's Galileo AI watches sessions and understands user feedback for you, automating the most time-intensive parts of your job and giving you more time to focus on great design.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Asking better design questions means fewer vague answers and more progress. Here’s how to replace dead-end prompts with feedback that works.
These 10 hands-on UX challenges train your brain to design better flows, build stronger instincts, and think like a real problem-solver.
This post breaks down what design debt is and gives you 6 smart ways to fix it, without killing team velocity.
Learn how to build a weather app using Claude, from setting up infrastructure to creating a functional UI that displays city-based forecasts.
Learn more →
