Is it really a design system?
For the past 15 months, I've been working with my team on our company's Design System. We're a small team with 3 designers and 9 front-end developers, and absolutely none of us are working on it full-time. It's still a very important topic, and one we discuss "passionately" throughout the year.
Many of these debates have presented variations along the same lines: "this is not a design system." Frequently, we have to reassess whether what is being suggested or what has been built is "worthy" of a design system.
Why? Are we all working with different definitions of what a Design System is? We shouldn't be. Even if we hadn't fully detailed our needs from the start (which I swear we did), there are many converging definitions out there. The notion of a Design System isn't that new or complicated, is it?
So, let's work backward. What are we building when we're not building a design system? Furthermore, is it okay not to build one at all?
Speaking the same language: what are we talking about?
One of the most comprehensive definitions of a Design System is courtesy of Nathan Curtis of EightShapes , a company created to supply these systems.
Curtis's definition breaks down a design system into large selection boxes.
First, he says that a design system almost always “offers a visual style library and documented components released as reusable code for developers and/or tool(s) for designers”.
This definition opens the door to a system made exclusively for designers or developers. A fully documented collection of Figma components (or your tool of choice) is both a design system and a fully documented combination of matching Figma and React components (or your tool of choice).
These two scopes of delivery and production are completely different. Why? Which one did we choose?
Go to checkbox number two: the system's clients. Who will use the Design System and what are their needs? It's possible that the consumers of the Design System will be only designers or developers, but not both. The scope of delivery would change accordingly.
Now that we can define what we need and who we need it for, one last checkbox remains: how? Curtis's definition isn't about the minute details of how the sausage is made, it's more about who makes it: “a design system is made by an individual, team, and/or community. While some emerge less formally, organizations now dedicate small to large squads to developing and releasing versions and processes of the system over time.”
This brings the design system face to face with the real question: can the company afford to have a team to organize, own, and promote this internal product? The answer directly informs the scope of the possible output.
Therefore, these are the checkboxes we will be working with. Curtis elegantly summarizes them in an elevator pitch definition:
Almost always, a design system offers a library of visual styles and documented components released as reusable code for developers and/or tool(s) for designers. A system may also offer guidance on accessibility, page layout and editorial design, and less frequently, branding, data visualization, UX patterns, and other tools.
A design system is adopted and supported by other teams that are experimenting. These teams use it to develop and ship features more efficiently to form a more cohesive customer journey.
A design system is created by an individual, team, and/or community. While some emerge less formally, organizations now dedicate small to large groups to developing and releasing versions and processes of the system over time.
When are we not building a design system?
Leaving out some of the customers
Let's go back to the branching path. It says that a Design System can be a collection of design code and components, or exclusively one of them. My team had a previous experience where our designers had their own design components, the developers their UI library, and neither were aligned. This situation left us with a long list of problems and inconsistencies, so this branching path made us very uncomfortable. It precisely describes what we want to avoid.
However, as we have seen, this first part of the definition works in conjunction with the notion of customers.
In a company where designers and developers work towards the same eventual payload, both are clients of the Design System. Their needs are fundamentally the same: both professions desire a homogenized, accessible, and efficiently built product. We are not two teams working for each other, but one team collectively building the UI of our applications.
That's why the branching approach seemed wrong. We can't do the "either/or" part of "reusable code for developers and/or tool(s) for designers," we need both or we would seriously compromise that unity of purpose. We need to speak the same language because, eventually, we're building the same thing.
This gives us our first clue to assess when we are no longer building a design system.
It has to be a nexus for all production teams present in the company's workflow. If designers and developers aren't following the same rules or aren't aligned in terms of objectives, then it probably won't be a Design System in the future. It might be a UI Kit and a UI Library (or two separate systems), both vaguely similar but not in sync. One part will end up "lying" to the other. Designers will have an idea of the product, but developers will build it their way.
If this division is okay with you, you're not building a Design System. You're probably building an isolated UI library.
Leaving things open to interpretation.
Everything you read about Design Systems revolves around documentation. Curtis' definition presents it as a 'documented and released library of visual styles and components', but you can look at... any of the popular Looking at design systems out there, you'll see that they don't skip over the guidelines and complete documentation.
This serves a crucial purpose. Imagine you've designed a button component. You've done your job well; each interactive state is detailed, and you've provided different lengths and content types to demonstrate the component's behavior. It's then selected by developers and transformed into a web component.
At first, everything is fine. In the playground (like a Storybook) where the new component is displayed, it looks and behaves exactly like it does in the design software.
But then it needs to be used within the application. How should it behave when placed next to the copy, for example? Is the copy broken, or is the content inside the button broken when space becomes limited? Furthermore, what happens when I need more than one button in the same location? You could offer variants, a "Secondary" or even a "Tertiary" button, but then you get even more questions: when should you use Secondary or Tertiary? Can I use Tertiary alone because I like how it looks a little better here? Also, can I just create the primary and go straight to the tertiary?
With each component comes a long list of possibilities, and with them, a long list of options. The thinner the documentation, the greater the scope for interpretation, whether by other designers or developers. This is in direct opposition to the mission statement of "developing and shipping features more efficiently to form a more cohesive customer journey." Any interpretation is a risk to the cohesion of the product as a whole.
It's also much less efficient: for each new component, the design team will have an endless stream of questions and answers from developers trying to ensure the answers are built into the code. However, later on, another designer who has no idea that these limits exist can use the same component and break those implicit rules. The coded component is unable to adapt to the requested design, and the back-and-forth begins again.
Documentation and guidelines exist to prevent this. Theoretically, one can "learn" your Design System and build any feature simply by applying it without compromising the homogeneity of the product. If you remove the documentation, what is there to learn? Only individual components and choices to be made.
If that's okay with you, you're not building a Design System. You're probably building a user interface kit that splits.
Initiatives that harm the system
The definition we're working with revolves heavily around people using the design system. Let's first discuss the last part, about having a squad working on the system. This is important for ownership, allowing teams to move quickly along a clear path. It's easier to establish a path as an identified team, rather than needing to question everything as a large committee at every step. It's also important because having owners for the design system means they "embody" this internal project.
In software engineering, we're used to having teams handling artifacts for other teams. We already do this with "infrastructure teams" behind the platform where other teams run their services, or with "quality assurance teams" focused on testing pipelines and tools needed by other teams, etc…
Why does this apply here? Well, now we're returning to the second part of the definition: adoption, support, and use by consumers who create products. These consumers (our colleagues) also contribute: they are closer to the products and are perfectly aware of the technical requirements, among other needs. Their communication and contribution are essential for most companies. Having a central team identified as the System leader allows all other teams to defer and centralize most of the tedium of collectively building a company-wide product.
That's the plan anyway. But what happens when the developers or designers don't sign off on the System?
Let's say that, as a developer, you don't want to participate in the collective effort required to build a component that will meet not only your needs but also the needs of another feature team. You'll code a single-use component outside the scope of the design system. Sounds easy, but the other team can do exactly the same. Now that the designers analyze the two features and see two components that appear to behave the same way, they have every right to think that this component can be safely used at scale. After all, it's generic for them, why wouldn't it be for developers?
By choosing not to use the design system, the developer created a loophole in the basic contract of a Design System. It works in exactly the same way when designers try to circumvent the design system.
You're tasked with designing a new feature, but the Design System doesn't seem to provide exactly what you need. You think a little more margin would work better, or perhaps you'd prefer to use a Secondary button without having a Primary one. The temptation to break the pre-existing rules of the design system (or never define them) increases, but the contract would be lost, and the development team wouldn't be able to fulfill it without friction.
If the design system doesn't provide what the designer needs, perhaps the design system isn't adequately equipped and additional work is required, which is fine. Ask the design system team about it. It's a dynamic and iterative process. The point is, it's not something you do half-measures. Either you build the product with the design system or you don't. If you consistently don't, especially when you could, why does a design system exist? The whole structure collapses. There are no more customers and no use for a production team either.
If you're okay with undermining your Design System, you're not building a Design System. You may be actively destroying it.
When is it not worth building a design system?
As we have seen, defining what a Design System is takes into account more than just the deliverable. Who your customers are and what they are looking for clearly defines more than just the type of component it documents.
With that in mind, there may be situations where investing in a design system can be too costly. As an internal product, the value of the design system is only what your customers say it's worth. If your teams aren't interested in collaborative creation, curating the single source of truth, systematic methodologies… then the adoption cost may be too high for them to pay.
Your organization might also reject the idea of changing its production pipeline from a “from scratch” model to a “system first” (and eventually “system only”) approach. The former has an air of total creativity and unlimited potential. It’s also why many products have visible “layers” where you can see sudden changes in design directions. You might even find two buttons that look the same but don’t have the same styles when focused on. Airbnb itself had this happening for a while.
This last point involves much more documentation work. It is often mistakenly seen as a simple box of Lego pieces, ready to be used. It is decidedly more than that: it is the Lego bricks and the detailed, carefully crafted booklet that comes with the kit you bought. It is the bricks and the way to use them. It is the bricks, not the magic pencil, that will make any brick look like whatever anyone wants at any time. It is the brick and the legal bond that nobody should do anything with the bricks or the Lego company will sue. It is the brick, the team that builds the brick, and the other team(s) that use the brick, and the communication between them all.
Adopting this mindset takes time. It's an investment, both in the talent it will require and the methods it will dictate. Whether they are worth your team's time (and the company's money) depends on what you (as a company, design team, and/or developer) are trying to achieve. If cohesion and rapid industrialization of best practices aren't at the top of your list of objectives, you might not be in the market.
But perhaps you should.
You can build a design system.
If there's only one thing to remember about all this, it's that a Design System is a methodology before it's a final product. Its objectives are... always The same: to provide homogenized, high-quality user interface elements at scale to consumers who use them to build products.
To achieve this, you can try continuing to do what we've all always done: divide your design and development teams and work as if one were building for the other. Probably, by doing the things we've always done, you'll run into the same problems we've always had.
The idea is to move from this isolated exchange of "us" and "them" to an exchange of "needs" and "means." The needs are the same for both professions. The means must, therefore, be aligned.
It comes at a price, like most changes. The need for a central driving team is no laughing matter. Perhaps that team doesn't need to be dedicated to the design system full-time at the start? Remember that nothing needs to be a big bang. Don't rush. Identify your priorities, make sure everyone is on board or ready to get on board. Document how a design system would have helped solve recurring problems.
A Design System isn't necessarily the solution to all your problems, but when it solves most of them, staying true to its principles is the best way to avoid falling into the same trap again. It's crucial not to make ourselves believe we're building one when, ultimately, we're just putting a label on a different set of rules.
The illustrations are courtesy of Greg Dlubacz. Whoooa .
