What is a design system? You’ve probably heard lots about them. You may have even worked on one, but you still struggle to define it.
There are many great design system books out there. Let’s see what their authors have to say about design systems:
A set of connected patterns and shared practices, coherently organized to serve the purposes of a digital product.
Design systems bring order and consistency to digital products. They help to protect the brand, elevate the user experience, and increase the speed and efficiency of how we design and build products.
A collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.
Here’s what other industry experts had to say about design systems:
The components are the trees. The design system is the forest.
The official story of how your organization designs and builds digital interfaces.
Any set of decisions governed across an organization.
A library of visual style, components, and other concerns documented and released by an individual, team, or community as code and design tools so that adopting products can be more efficient and cohesive.
There are lots of different definitions of design systems out there. Why is that?
I think it’s because there are a lot of different definitions of the word “design” and of the word “system,” and both are very broad.
My favorite definition of “design” comes from Jared Spool:
Design is the rendering of intent.
My favorite definition of “system” comes from Donella Meadows:
A set of things—people, cells, molecules, or whatever—interconnected in such a way that they produce their own pattern of behavior over time.
Put those two things together and it says something to the effect of “An intentional set of connected things that create repeated behavior.” That could apply to almost anything!
In my design systems work, I’ve noticed 6 different kinds of things that can be described as design systems:
Brand identities and design/visual languages are the oldest and most common version of what people in general know as a design system. This has been around from as early as cave paintings. A design language refers to all of the different visual elements that make up a brand or a particular user interface design. That could be the colors, the typography, the spacing, the layout, all of the different visual components that combine so that a brand is recognizable.
Tools are some of the most common instances of digital design systems we see. UI kits are great examples. We see these a lot when we talk about software applications like Figma or Sketch, where we have these libraries of visual components that we can drag and drop into other interfaces to make it easier to design those interfaces all at once. Websites like Design Systems for Figma display a gallery of UI kits that different teams have used and open-sourced so you get a sense of how these libraries are connected with symbols and components that can be reassembled.
Component libraries are another great example of a design system as a tool. Just like we have UI kits in design programs, component libraries are the code equivalent to that. In the same way that you can drag and drop components into artboards in a design tool, with a component library, you can use shorthand snippets of code to reference other code that lives elsewhere. Component libraries are popular in frameworks like React, Angular, Vue, where you can use smaller sets of code (APIs) to reference larger sets of code in a systematic way.
Products as design systems the one type that I like to talk about most when it comes to design systems that big organizations can use to be more efficient, more consistent, and more of a relief at scale. This is my preferred definition of a design system:
A connected, package-managed, version-controlled software product that contains the smallest set of components and guidelines an organization needs to make digital products consistently, efficiently and happily.
A lot of the popular design systems that we reference nowadays are this kind of design system: Material Design, the Lightning Design System, Shopify’s Polaris, and others like them. What makes this kind of design system a product is that they have dedicated teams that are focused on building those out day-to-day and week-to-week. They have a backlog. They have budgets devoted to them so that they can be sustained like any good product.
Think about the way a startup works and makes a product. There’s usually a dedicated team. They have a product manager. They have a acklog, they have things they have to work on. They release things very frequently to their users and to their customers. Those customers give them feedback on how that product needs to grow, what features are working for them and not working for them.
A good design system as a product at an organization follows suit. Design systems as products need to grow organically with the needs of the organizations they serve.
A company’s design system could simply be the particular way they build digital products. It can be an outline all of the steps. This can be a very effective way that an organization scales to be more consistent. If everyone’s working with the same process, maybe that makes the output more consistent than if everybody was just doing their own thing.
This is why governance is such a big topic in the world of design systems. Governance lays out who does what and when. So, process and workflow is a really big part of how design systems need to live within an organization.
Even if there are no design or code components, simply saying, “This is how we work,” can be a really effective design system for an organization.
At many companies, a design system team is its own entity. Product or feature teams interact with the design system team by using them like an internal agency or like a staff augmentation team. When they need something that the design system team knows scales across the organization, a product or feature team will essentially place orders with that design system team and then receive back components or suggestions or workflow tips. In that way, a design system can actually be a service to the rest of the organization and that can be really successful.
The last type of design system is a design system as a practice. This is probably the most mature stage for a design system to be at an organization.
A practice is a repeated exercise or performance of an activity or skill in order to acquire or maintain proficiency in it. That exercise could be repeated use of the same components and patterns. It could be incorporating a particular process. It could incorporate interacting with a design system like an external agency. It could incorporate all of the different ways that design systems can manifest within an organization. Essentially, you’re doing a thing over and over again, and, the more you do it, the more efficient the organization becomes and the more consistent the organization becomes over time.
As design systems become a practice in an organization, it evolves in order to scale better.
Is it a problem that we don’t have one definition of “design system” that we as an industry can standardize on? No! I think it’s a great thing that we don’t have one standard definition.
That said, although it‘s not a problem, it can be problematic at times. Generally, when working with a team, you’ll want to agree and actually have some shared definitions and vocabulary for the things everyone is working on. Otherwise it gets to be really complicated in how you’re working with team members.
One of the promises of a good design system is that it creates shared vocabulary among teams that might not have it otherwise. Imagine designers and engineers calling a component different things because it’s called something different in each of their workflow. A good design system will actually allow them to align on a definition of something. So, while there are different kinds of design systems, it is useful for you to say to your design team or your engineering team or your product team, "When we work on a design system, this is the version that we’re talking about." It could be any of the versions above, but it is important that your team picks one, a set, or a combination of them so that you all know what each other is talking about as you’re working toward a common goal.
Not having one standard definition of design systems allows us to be more inclusive of where any team is in their design system journey. In her talk for design systems conference Clarity in 2022, Amy Hupe shared a fantastic reminder for us all to “recognize the design system you already have.” Design systems come in all shapes and sizes, whether official or unofficial. Amy closed a section of her talk with this wisdom:
We have to engage with our existing, unofficial design systems to cultivate one that serves us better.
If you have a UI kit, that’s okay! You can work toward a larger and more mature design system.
If you have a full design system practice that is mature, that’s okay too! You probably still have a lot of work to do.
A design system is never complete; you continue to work on it for as long as your organization exists.
I’m reminded of the common idea that none of us will actually achieve perfection, but the pursuit of perfection is a good journey. With a lot of things, it’s about the journey, not the destination. The Material Design team has been working on that design system for many years and they still have a lot to work on. The Lightning Design System team has been working on that for many years, and they still have a lot to work on. That’s not a bad thing!
All digital products can be improved. Your design system can be improved no matter what kind of design system you have. Hopefully, this video gives you a better understanding of all the different types that are out there and how you can move and progress to become more mature in your design system practice at your organization so that you can do better work with and for your colleagues.
Join 30,200+ subscribers to the weekly Dan Mall Teaches newsletter. I promise to keep my communication light and valuable!