Designing interactive, digital experiences is still a relatively nascent discipline. While fields like architecture have a long and storied past with well-established terminology, governing bodies, and certifications, web design is still in its “wild west” era. We’re creating methods, vocabulary, and more as we go.
We’re also borrowing a great deal from related disciplines or simply grasping for metaphors to provide language (see “atomic design”), and this is true when we use the term "design system." As a matter of fact, in her 2017 book entitled Design Systems, Alla Kholmatova makes this very point:
“There isn’t a standard definition of ‘design system’ within the web community, and people use the term in different ways — sometimes interchangeably with ‘style guides’ and ‘pattern libraries.’”
If someone is trying to convince you that you need a “design system,” what exactly do they mean? Will it be tied to a specific technology? Will it work with your CMS? Who can use it, and what will they be able to do with it? Will it be a website or product of its own, separate from the sites and apps it enables? If yes, will you now need a person (or team) tasked with maintaining that as well?
All great questions! The bad news: there is no single, right answer to these questions that applies to any organization and all design systems. The good news: you can answer these questions based on your organization’s needs.
What is a design system?
While design systems can vary greatly, it is useful to have a working definition for what we mean when we use the term. In the absence of an established one, we have created our own definition based on the kinds of things design systems are comprised of and the reasons for their existence:
“A design system is a set of principles, constraints, patterns, and documentation that empower disparate teams to create, maintain, and extend a design efficiently and consistently.”
Some parts of a design system may already exist within your organization, but a design system is more than the sum of its parts. Ultimately, a design systems approach is what we are describing. As Ethan Marcotte says, design systems are about “the way your organization works.” Or, as Nathan Curtis puts it:
“Design systems are the way you talk about all the decisions that you make as a design and coding organization. It’s the way you collaborate to hand off those decisions and create an experience in using that system.”–Nathan Curtis, Consulting Lead at Eight Shapes
Nevertheless, our definition helps clarify some of the common parts that make up that collaborative process and framework.
The Common Parts of a Design System
To help you assess the nature and scope of each, this is what we mean by principles, constraints, patterns, and documentation:
- Principles: Design principles are short, memorable markers of what success should look like for your design system. They should be informed by research, emerge from your early planning and design process, and act to protect against the problems your design system is attempting to solve. Jared Spool has some helpful tips for creating effective design principles.
- Constraints: There are many types of constraints that make up a design system. You have more obvious things like style guides that constrain the visual design and stylistic choices. You have UX guidelines that define common user flows. You also have governance models that help define the process for adding to, altering, and using your design system. Design systems provide constraints for various users of the system to increase efficiency and consistency. The constraints your system needs should be governed by the needs of its users.
- Patterns: People often think of “pattern libraries” when they hear the term “design system.” These typically capture visual design patterns for reuse but can often capture things like the stylistic constraints (noted above) and other forms of designer, developer, and content creator guidance. Design systems aren’t just pattern libraries and style guides. Ethan Marcotte says, “Design systems work is much, much more than a pattern library: it’s the way your organization works with those patterns.” We sometimes refer to these as “process patterns.” Ultimately, design systems become a way of working for a cross-disciplined team. Therefore the governance models that constrain how things should happen, and the process patterns for carrying them out, are just as valuable as the design patterns and guidelines for designers and developers.
- Documentation: Documentation is key to a successful design system since multiple people in varied roles will need to accomplish different things without access to every form of expertise. Clear, canonical documentation of the principles, constraints, and patterns empowers people across your team to work efficiently and consistently.
Like the sites and apps they empower, design systems should be designed to their users’ needs.
Some parts of the Georgia State design system
The nature and scope of your system’s principles, constraints, patterns, and documentation should vary based on your organization’s needs. Here are a couple of examples of how a design system can vary from organization to organization:
- An enterprise tech company may need a design system that provides pattern and code consistency across multiple sites and apps managed by several development teams. It may benefit from investment in a code-based pattern library (e.g., a library built on Fractal or PatternLab).
- A small product team whose design system is focused on a single marketing site or implemented within a CMS for content editors may look for lighter-weight approaches to capturing their pattern library. Products like zeroheight or Frontify allow designers, developers, and editors a place to capture and document together without the cost and effort involved in building a custom, code-based pattern library.
The Different Users of a Design System
Like the sites and apps they empower, design systems should be designed to their users’ needs. The users of a design system vary. Here are a few common user types for design systems to consider:
- Designers: Some design systems exist primarily to help designers maintain consistency and efficiency as they try to work at scale. Small design teams may need the system to help speed up and scale their work. Large design teams may need the system to ensure consistency.
- Developers: The same needs described for designers also can apply to developers. Some design systems exist primarily to help developers work efficiently and consistently or to fulfill requests without needing an extensive design process.
- Content Creators: Some design systems provide tools (often in CMS form) and guides for content creators and editors to easily create new things that adhere to the design.
- Product Owners: Some design systems help product owners evaluate new business needs, estimate timelines and costs, and assess when a new design and build process is needed.
Identifying your design system’s users and describing their needs and challenges accurately through research is essential to creating a design system that saves money and increases productivity. Design systems created without this kind of care can easily create new hoops for people to jump through to get their work done or further divide already siloed teams. Design systems, done poorly, can feel like they constrain your best talent rather than taking away their most tedious tasks.
Design systems, done poorly, can feel like they constrain your best talent, rather than taking away their most tedious tasks.
The problems a design system solves
Defining the design system your organization needs always begins with identifying the problems you’re hoping it will solve and the people it will solve them for. Ed Chao, a designer at Apple (and formerly Dropbox), refers to this as naming your villain.
What villain are you hoping to defeat with your design system?
The 3 villains design systems exist to defeat
While there are many villains your team may face, there are three common ones we’ve found in most organizations that need a design system.
- Scale
- Inefficiency
- Inconsistency
More often than not, if you need a design system, you’ve got one or more of these villains causing problems. Successful design systems projects require up-front investment and a longer-term plan for maintenance and governance. One of the best ways to avoid unnecessary expense or scope creep within your design system project is to zero in on the primary villain you need to defeat.
Villain #1: Scale
More often than not, if you need a design system, you’re not working on just a microsite. The clients we typically serve at Lullabot have a network of sites, apps, and channels that their content is distributed through. Most have websites that are large and complex. In these scenarios, design systems often emerge from a designer or a front-end developer trying to make their own life more manageable by making it possible to do more and do it more quickly.
If your product, site, or organization is not large or complex, you may find that some of the parts of a design system are useful (e.g., you may still need a style guide or some design principles), but you don’t need to take on an actual design systems project. However, suppose your organization is large, or your product platform and marketing channels are vast. In that case, you may find that just having a useful style guide isn’t eliminating key challenges like inefficiency and inconsistency.
If scale is your primary villain, you should find ways to measure it early in your design system project. Establish metrics for the number of parts within your current system. Conduct an interface inventory to assess what you currently have. Look for opportunities to eliminate redundant parts. Be sure to measure the reduction. This can be as simple as the number of parts within your existing interface you were able to remove (E.g., We went from 37 button styles to 5 in our new design system).
Note: If you want to nitpick, the next two villains are often children of #1.
Villain #2: Inefficiency
If you’re working at a large enough scale, inefficiency is usually a problem. Designers may find it inefficient to treat every page of your site as a special snowflake. They may have too many pages to design, build, and launch each quarter to make that feasible. Likewise, developers may feel that same pain as they’re working to rapidly build bespoke designs and get each one through testing and deployment to launch quickly enough. Marketers may feel hamstrung by the time it takes to roll out a new landing page for a campaign. Content creators may feel frustrated that simple content tweaks require a lengthy process in a ticketing system. Inefficiencies like these are a clear signal you should consider investing in a design system.
In a recent survey conducted by the team at Invision, 83% of those surveyed said their design system saved them at least 2 hours per week as part of their normal workflow. 34% estimated it saved them more than 6 hours per week.
If inefficiency proves to be your primary villain, you should plan your design system project to identify critical metrics for efficiency. These metrics may be things like time-to-launch or time-to-publish for high-priority pages and content types. Focus your energies and investment on improving those areas.
Villain #3: Inconsistency
Even if your team has the resources to handle scale efficiently, many organizations begin feeling the pain of not having a design system due to inconsistency. For example, multiple business units may each have their own design and development resources, and your brand team may not be able to keep up with their productivity. You may find that whole sections of your site feel like special snowflakes (in a negative way), creating grief for your brand team or complicating your messaging. Even worse, this can lead to disjointed experiences for your users.
The adverse effects can go beyond merely frustrating designers with visual inconsistencies or creating technical debt for developers with too much to maintain. You may fix an accessibility flaw in a particular flow or process, only to discover it popping up again and again in other places. These kinds of issues can lead to lawsuits and real problems for organizations. A well-designed design system can help you scale accessibility effectively across your products.
If inconsistency is your primary villain, you’ll need to look for ways to quantify the existing problem at the outset. The interface inventory from villain #1 is a great way to start. You can spot the areas of your existing interface with the most inconsistency and prioritize improvement of those areas. Try taking on just one of those areas as a pilot program for a new design system.
Conclusion: What next?
If you’ve identified problems of scale, inefficiency, and inconsistency that could be improved by a mix of principles, constraints, patterns, and documentation, then you’ve likely identified that you need a design system. What do you do next? How do you start creating a design system? And not just any design system, but a design system that will actually help solve your problems?
We have helped organizations create new design systems and helped them refine existing ones. These have been organizations both large and small, with varied users and varied needs. If you need help, please contact us to get the conversation started.
We will also be publishing more about our process for creating user-centered, content-first design systems. So stay tuned!