I vibe design/coded a design system in a few hours!
I see a post like this everyday on LinkedIn. In a world where AI is taking the industry by storm, it’s meant to show how powerful these tools are. But it also shows how little the industry understands about the work that goes into design systems.
Design systems are for people
This is a quote by Jina Anne and the word “people” is important. First, a design system is not for a single person. It’s the reason why none of the sites I create have a design system. They have reusable resources, but not a system. The reason why they don’t have a system is because many of my personal projects are built by a single person; me. I don’t need to communicate the do’s and don’ts with anyone else. Do I have pieces of design systems like variables and components? Yes, but these things do not immediately make a design system. What I’m missing is what I find to be the defining quality of a system: agreement.
To get agreement, you need to have people. People who have different opinions on design, the way things should work, the way we represent ourselves. This is where the role of a design system maintainer comes in. Are we experts in tokens and components? Yes, but the hidden role that we discuss as a practice is that of a diplomat. We need to be able to communicate with different teams, different stakeholders, and different people. We need to be able to understand their needs and their perspectives, and synthesize that into a system that works for everyone. This is not something that can be done in a few hours, or even a few days. It takes time to build trust, to build relationships, and to build a system that people will actually use. I could have the perfect typography ramp in my eyes, but what good is it if it isn’t adopted? At best it’s a proof of concept or something for my personal work, but getting people to agree on it and use it, that’s the hard part. That’s the beginnings of a design system.
So, if you made a styleguide for yourself in a few hours and that helps you visualize the plan for your project, that’s great! But I’d argue it isn’t a system unless you have stakeholders. People who can affect the decisions of the system, and people who can be affected by the decisions of the system. If you don’t have those people, then you don’t have a system. You have a styleguide, or a pattern library, or a component library, but you don’t have what I’d call a design system.
How to vibe a design system
Let’s say you want to really crack this nut. What does vibe creating a design system actually look like?
From my perspective, the goal is to get the agreement of the stakeholders and make that available as a reusable resource. What this means is you need some way of collecting the decisions of the organization into a central location which is later used to inform design and development work over product lifecycles.
One of the pieces to this puzzle is most likely some hosted MCP server. This allows your AI tool to connect to a central location where it can look up resources of the design system in order to make informed decisions. This is the new “docs site” so to speak, except it’s not meant for humans to read, it’s meant for machines to read. This is where the agreement of the organization lives and how AI tools would reference what the agreements are for the organization. The challenge from here only becomes getting the organization to connect to the MCP using their tool of choice. This is no different from what we do today, promoting use of the system.
The question is what does that agreement look like? Right now, there’s lots of talk about the DESIGN.md file popularized by Google’s Stitch project. This is a markdown file that is a hyped-up styleguide. It’s not a design system for the reasons we mentioned above. But it could be. If that DESIGN.md file was created by collecting the decisions of the organization, then that’s when it becomes a representation of a design system.
The final piece to the puzzle is what getting agreement looks like. I’ve always said that a design system is a reflection of the people who use it. This means that if the organization wants purple gradient buttons, then it gets purple gradient buttons. However, other organizations have design systems teams that operate with stone tablets, carrying down the agreements from high atop a mountain of design wisdom. They might have gathered feedback from the organization, but the final decisions are curated by the design system team.
In some of these cases, this is a good thing. This is the team responsible for making sure the resources provided by the system are of high quality and are consistent with the organization’s brand. In other cases, this can be a not-so-good thing. This can lead to a disconnect between the design system and the organization, where the design system is not actually serving the needs of the organization. This is where people outside of this team start going rogue, and where other decisions start making their way into the product without aligning to what was bestowed upon them. Stakeholders begin to take notice and might choose a side, defunding the design system because they are moving faster without it or because they vibed one up themselves. What’s so hard about making some color variables and a few components, especially now that generating them takes seconds? This isn’t agreement any longer, it’s just another vibe project gaining some temporary traction.
The way to vibe a system is to capture what the organization is doing and making that available as a resource. This is the modern button audit. Traditionally, a design system blossoms from roaming around the product, gathering the decisions that have been made organically, and then making sense of those decisions as a collection of resources for the organization to use. This is that reflection idea from earlier. In areas where we find things in conflict, we get to the bottom of it. We ask stakeholders, complete research, and come to some conclusion on what the path forward is so that we’re all on the same page. Generally speaking, the design system team are moderators of that debate. We typically have very little stake in the outcome, as long as the final decision is beneficial to users. This is where we find out if the organization wants purple gradient buttons or not.
So, what if the process of capturing the system was not a manual walk-around but a swarm of agents traversing the landscape of the product on a regular basis? As new decisions were made, they would be captured and considered a new design decision. This doesn’t necessarily mean that every small change is immediately a shared agreement, instead it provides a small amount of influence to how the design system evolves. As more people view other people’s decisions, they will themselves decide if that change they saw elsewhere is appropriate for them too. Now there’s two places where that decision was made, gaining more influence on the design decisions. More people see this new direction and start adopting it, further influencing the decisions. Before long, the design system is truly reflecting what we’ve all individually decided to do. A self-fulfilling design system that is truly a reflection of the organization, growing organically through the work that people are doing daily. This is the vibe design system, and it’s not something you can do in a few hours, but it is something that can be done with the right tools and the right approach.
Admittedly, I don’t know what that looks like from a technical perspective. What does the infrastructure look at, how does it capture the decisions, and how do you fine tune the amount of influence each morsel of information has on the design system? What does the process of a rebrand look like? Do you turn the influence up to 11 for a specific file? I know some products are claiming that they take your existing system into account when vibing, but currently they are looking at existing resources. I don’t think any system is looking at the product as a reflection of the system. But that’s exactly what they should be doing. It’s what the design system team has been doing, or at least trying to do.
So, if you want to make a vibe design system, get it to look at the existing product and make the DESIGN.md from that. That’s where the people are and their design decisions. Keep that up-to-date with how the people are working and the growth of the product. And the thing that you generated in a few minutes that you call a design system, it’s not. However, with a few people and some smarter infrastructure, it could become one.