“The single biggest problem in communication is the illusion that it has taken place.”
— George Bernard Shaw
The environment around design systems is brimming with loaded and context-dependent terminology, conflicting and evolving definitions, and way too many people claiming to have it all figured out. We aren’t those people.
There are lots of ways to define, interpret, and categorize many of the terms you’ll hear in relation to design systems. We aren’t in the business of being right. We’re in the business of communicating and solving problems. It is in pursuit of communication, not righteousness, that we put together this list of commonly conflated, loaded, and context-dependent terms you’re likely to encounter when talking about design systems. The goal here isn’t to become Deputy Definitions. It’s to be aware of terms with squishy definitions so that you can recognize potential miscommunication, swoop in, and firm things up.
A design system is generally an umbrella that covers an opinionated collection of assets created to help teams build consistent UI. Typically they include:
For some folks, the lines drawn around a design system may be more narrow, more broad, more rigid, or more blurry. You may also hear “design system” used to include, exclude, or refer to:
*This is the single most critical piece of terminology to immediately norm around. Conflicting understandings of what constitutes the design system can have a huge impact
A brand guide or brand system is typically a document aimed at capturing a brand’s overall vibe, and includes rules and resources to help it be reproduced consistently across media. A brand guide will usually include:
Many things can be interpreted as guides or systems, and anything an organization creates technically falls under their brand, so this one is a real crap shoot.
Generally a style guide is like a lightweight version of a brand guide. It’s often a subset of the most visible aspects of a brand’s look and feel that’s easy to apply across media. If the brand guide is a full study, the style guide is like the abstract. They often include:
The above definition assumes a context of design. In the context of development, a style guide may be a set of guidance for how developers should be writing their code so the codebase remains clean, familiar and navigable across teams. In a marketing or branding context, a style guide may refer to on-brand voice, tone, verbal and grammar usage.
Further still, a team may create something called a style guide in lieu of a design system. In this context, we’re usually talking about an internal library of UI components and patterns that can be easily reused.
A component is simply a reusable pattern.
Designers & developers both understand components to mean reusable patterns, but the content of the patterns and the contexts in which we apply them are usually different.
A good place to start a conversation between developers and designers is to talk about the pieces of the interface that design believes are components (or patterns) in an attempt to model the software code to match how the designer is thinking about reusable patterns.
A library is a collection of resources, organized and shared across teams.
Libraries may have shared code, shared assets, or a shared set of UI components.
There can easily be confusion on a team when both designers and developers are talking about “libraries”. Our best advice is to get comfortable asking “which library do you mean?”
A framework is a kind of opinionated and vetted scaffolding on top of which we build something.
People use the word “framework” to talk about following an established pattern or conceptual template. They also use it to talk about a specific type of technical product called a framework.
Documentation is usually a website that spells out everything that’s available as part of a design system, descriptions of how it all works, and instructions/recommendations for how to use it. For example, this is the documentation for Clarity (VMware’s design system).
Documentation can be anything that has been documented, so this is another place to get comfy asking, “which documentation are you talking about?”
Knowing the impact that loaded terminology can have on communication, you may be tempted to align on team-specific definitions for these terms, via something like a ubiquitous language workshop. This could be a great solution to the problem. The word of caution we will share is this:
Language tends to be deeply embedded in people—dislodging or “correcting” internalized definitions from their minds might be very difficult, even if they have the best intentions of seeing them dislodged.
We don’t want to dissuade you from aligning on standard definitions for some of these terms with your team. We’re simply saying that even with the best intentions and the most bought-in team members, people may still slip. If the norm is to quickly check-in with each other when these loaded terms are used, you’re likely to catch any slips and still communicate effectively. If the norm is that “when we say library we always mean _____”, you might not catch an unintentional straying from the established norm.
In more ways than you might think, design systems are a lot like hot dogs: lots of people love them, some people have odd opinions about them, and it’s not uncommon for their recipes to be steeped in mystery. Despite their popularity, design systems can stump the best of us. Lots of people harbor misconceptions about them that can make your life unnecessarily difficult. Get to know some of these commonly heard phrases, so that you can impress everyone in your Zoom room with your insightful ability to head off the future trouble they may cause.
Design systems are often spoken about as simple, easy, magic-bullet-type solutions to all our product problems, which is a huge misconception. Their out-of-the-box polish and the seeming straight-forwardness with which they can be used to build professional-looking software has likely contributed to this reputation.
To someone without mountains of experience, the complexities that come with design systems may not be obvious. They can seem like magic libraries, where patterns are copied off a virtual shelf and pasted into apps. The reality is that there are loads of nuance, quirks, opinions, and limitations baked into every system. They require resources, processes, and dedication to use and maintain. It requires time, training, and practice to master them, and they will still surprise you. Design systems can be powerful tools, but they are not to be taken lightly.
Language shapes perception. The name “design system” can lead to the assumption that designers “own” all the design system things in their designer bubbles. This is a dangerous assumption, and could not be further from the truth.
In reality, design systems live in the evolving (perhaps even shrinking) middleground between design and development. Design is not a territory, it’s a capability. We all have roles to play when it comes to engaging with design systems. The systems do not absolve you of the need for meaningful cross-discipline communication and collaboration. They require it in order to be effective tools.
The belief that any one design system is universally “the best” ignores the fact that each product, each team, and each organization exists within its own ecosystem of needs and constraints. The best design system is the one that meets the needs of your organization and your teams. The one that loses you the least, and gains you the most in terms of trade-offs; the one you know, or are committed to learning how to use. It may be the one that doesn’t exist yet, because you need to build it. It’s even possible that the best design system for you is no design system at all.
A design system provides a common starting point from which designers and developers immediately and inevitably diverge. Think of it like this: you give the same 100 LEGO pieces to ten different people, and ask them to build a house. The result is you end up with ten very different houses. Nobody did anything wrong. It’s just the nature of the beast.
Having a design system in place does not guarantee consistent (or even good) design. It’s a tool that many people are going to use in many contexts, giving it the potential to be used in many different ways.
Imagine you buy an empty plot of land for your future home. Then someone drops off a few tons of framing lumber and sheetrock. You wonder, “Do I really need the architect?” The answer is Yes. Unless you’re cool with being 80% complete when you realize your picture window gives an excellent view of a brick wall, you’re going to need a professional planning how things will fit together.
As discussed, a design system provides a common starting point in the form of some patterns and some decisions. Some decisions! Not all decisions. You can have the most robust system in the world, and there will still be countless decisions and judgment calls that the system cannot make for you. Designers are trained to make these decisions in ways no system ever could. No matter how fancy your system is, it’s still a tool, and tools can’t use themselves.
It’s also worth mentioning that designers do a LOT more than assemble UI components. Design is a multifaceted discipline, and the points discussed here are just scratching the surface.
“No matter how hard you fight the darkness, every light casts a shadow…”
Design systems are no exception to Plato’s insightful observation of this basic reality. For all the value there is to be gained by using them, design systems do not come without some very real challenges. While some of these challenges are inherent, requiring vigilance and discipline to navigate, others are entirely avoidable. Let’s muse on some common challenges around design systems, and how you can approach navigating them.
There’s no getting around this one. Some big decisions around design systems are difficult to walk back. Once you’ve decided to start using a system, it is almost always going to be a very expensive decision to unmake.
It’s important that you do everything in your power to make good, well-informed decisions. Check out some of the sections below to help navigate these choices whether you’re choosing a design system or inheriting one.
Software folk come from all manner of backgrounds, so it’s not uncommon for you to be working with stakeholders, partners, or practitioners who have little to no experience working with design systems.
Remember, empathy first. It’s no fun to not know something you feel like you should. Look for ways to help your team deepen their understanding of design systems, and remember to stay open to learning yourself. We work in an ever-changing industry, and “knowing” anything is always risky. Treat every team and every system like a new opportunity, and consider doing some design-system-focused norming among product teams.
Managing and maintaining any kind of in-house system is a beast of a job. No matter how you slice it, there are a lot of plates to keep spinning:
It’s possible that your experience working with a system did not go smoothly. It’s also possible that the folks who need help handling all this business are working outside the explicit boundaries of a specific project or team, making them a little more difficult to influence.
Again, empathy first. Assume that everyone is doing their best and try to see where you may be able to offer some feedback, guidance, or influence. Consider disguising it as help if there are fragile egos in the mix. If there’s a meeting where updates to the system are discussed, ask if you can attend. If there’s a Slack channel where questions are asked and discussion takes place, join the conversation.
In general, try to kindly identify gaps, inefficiencies, or problems where you see them, and always be sure to offer possible solutions if you have them. Designers are problem-solvers, after all.
The availability of high-quality supporting resources for practitioners is another challenge with adapted or custom systems. . Issues exist from incomplete or contradictory documentation, to incorrect color values in the published design library. This can be frustrating as a practitioner, especially when it slows down the ability to do your work. These resources are often owned by outside teams, and perhaps sitting outside your sphere of influence.
If you find yourself working with resources owned by another team consider it an opportunity. If you notice that designers are constantly detaching the instances of a design component because it’s built incorrectly, point out to your teammates what you’re doing, and why you’re doing it. This is a good opportunity to demonstrate proactivity, as well. If you come across missing documentation or sloppy assets, find out what the process is for making fixes. In all likelihood, whoever has that in their job description is going to be glad to have some help. See if you can gently inject yourself and some of your expertise. If you can help improve these resources, you’ll not only be helping your team, but every other team who uses the system.
Consistency—the white whale. The idea of in-app and cross-app consistency is one riddled with nuance and strong opinions. You may run across leaders who insist on the consistent use of patterns regardless of domain. You may encounter a designer who believes they’ve revolutionized the dropdown, rejecting basic system components in favor of their own custom creations. You may discover that the teams building parts of a single large product offering have entirely different navigation patterns and applications of the color palette. And you will almost certainly run into someone with a desire for consistency, and an inability to tell you what that means.
First, remember that consistency does not mean uniformity. There is, and should be, room for autonomy. Second, try to suss out what “consistency” means in your particular situation. Think about what it might take to achieve, and determine the value that the consistency provides to the organization, users, practitioners, and product teams.
Achieving the consistency that’s initially desired is a grossly underestimated effort that provides overestimated value. That’s not to say there is no value to be gained. If inconsistencies in major design patterns are causing confusion and frustration for users, or if they are resulting in a sloppy look for an organization, something should be done about it.
Should you encounter a similar issue it’s best to proceed with caution, and do what you can to:
There is no shortage of spicy opinions to be found around design systems. There are designers who are upset by the feeling of their autonomy being taken away, and there are plenty of folks who are not the biggest fans of Material. Still, others are excited by the prospect of having to make fewer design decisions. It’s important to allow people space to have their own emotions and opinions, but there is a point where attitudes can become unproductive, risky, or even toxic.
Talk about attitudes that you encounter around design systems openly, and honestly with your team about handling attitudes around design systems. Try having a one-on-one, or sharing a different perspective with someone who may be harboring an attitude. From a practical perspective, try finding fun ways to embrace creative constraints.
For example, we once ran a creative constraints workshop with a team of client designers who had mixed feelings (and mixed adoption) of their design system. It turned into a great bonding experience. We witnessed an emotional saga told exclusively with emojis, that actually helped cool down some of the spicier attitudes on the team.