55 min
After understanding the benefits design systems can bring, getting buy-in for your team to embark on a design system is a huge milestone. Figuring out what parts of a design system your team should invest in is another challenge.
In this article, we’ll go over the different artifacts of an enterprise-grade design system you may want for your organization. We’ll also review real scenarios that will best leverage a design system and how these artifacts can play a role in building your product.
It’s important to note that not every design system needs to be built out to rival Material or Polaris, systems that each serve millions of customers.
As you go through this list, it’s more important to recognize why you might use these things, and the challenges your team faces that can benefit from having them.
Design systems are rapidly evolving as a subfield in UX. If there are any other artifacts you think should be in this list please let us know!
Design-focused artifacts in a design system provide a framework for creating consistent and cohesive user experiences. They enable designers to deliver high-quality designs faster by providing ready-made assets and guidelines.
1. Design principles
Design principles, or tenets, are often overlooked. These are the values you want your design system to embody, and how those values will show up in your designs.
The hallmark of a good principle is whether it can help you make a decision when faced with ambiguity.
An example principle could be “We value clarity and usability over design flourish.” If the team is at an impasse on whether it should show a chart legend or hide it in favour of clever tooltip interactions, this principle should clear that up.
2. Style guide
If anybody asks (and they totally will) “what size fonts do we use” or “what is our error colour” the style guide should help get them sorted.
Some of the things the style guide will have:
A style guide is a form of documentation and can typically be found in design files alongside the next artifact in our list.
3. UI components
As a designer, having a set of UI components to be able to quickly create designs may be a huge reason why you’re bought-in to having a design system in the first place.
Examples of UI components are:
UI components are the base level or “atomic” elements of the design system; they cannot be broken down into smaller parts. Think of basic elements like checkboxes, buttons, or inputs.
4. Pattern library
Pattern libraries are often conflated or confused with UI components. In reality, patterns are what happen when you put a few UI components together to solve a problem.
One example is a “search pattern,” which may consist of a text field to enter a query, a button to submit the search, and a dropdown menu to show search typeahead options.
Other patterns that may be part of your system:
Pattern libraries, and their big bro templates, are where design efficiencies can really take off. Having a set of components is nice, but having a whole page already built for you to start from is even better.
5. Design documentation
As a design system advocate, if you aren’t around to personally help guide someone through the system, how might they get the knowledge they need to be able to provide solutions?
Documentation can take many forms. Dos and don’ts, component guidelines, usage examples, and accessibility standards. The other design artifacts on this list can also be considered documentation. Despite the variance, the goal is consistent. Spreading design knowledge asynchronously so that users can maximize the value they get when using the system.
Instead of stress-writing an entire library of content that may or may not be referenced by system users, try using your system as-is, and document when you experienced ambiguity yourself.
Design system artifacts for developers are focused on turning design decisions into real interfaces users can interact with, while doing that in a way that streamlines development and makes maintenance of the codebase easier.
1. Component library
The development component library is the code counterpart of a designer’s UI library. It is also arguably the most important part of any design system because it’s the thing the user will actually interact with.
Achieving and maintaining parity between the design UI library and the coded component library is an important part of operating a design system. Discrepancies between the two can lead to misalignment and collaboration inconsistencies during development.
2. Design tokens
Design tokens are meant to ensure visual and functional consistency across an array of components in a system. If the development component library and design UI components are two sides of the same coin, design tokens and the design style guide are bffs in the same way.
Design tokens take the core measurements or values of individual design objects and add meaning to them. A hex colour code of #FEFFD5 might be gibberish, but adding layers of meaning by applying design tokens can turn it into a more human readable format, like color.page.background.subtle
Regardless of how your design tokens are implemented, it's more important as a designer to partner with your engineering friends and find a way to translate design definitions into development definitions in a scalable way
3. Developer documentation
Similar to design documentation, developer documentation for design systems can come in a variety of flavours. Code snippets, usage guidelines with examples, API integration guides, accessibility guidelines, and changelog histories are all important things to know. Developer documentation would be maintained by engineers and could appear alongside design documentation for the same component.
This type of technical documentation helps ensure the design vision is translated accurately into code, and implemented consistently throughout a product.
The following artifacts that make up design operations can be defined and maintained by designers, developers, or a collaboration between them. Much like products launched to external customers, having a dedicated product manager owning these will be a huge asset, freeing up the designers and developers maintaining the system to focus on their areas of expertise
1. Design system roadmap
As your system becomes more mature, it’s important to communicate what you’re doing and the impact you expect to have on the organization. A design system roadmap is one way to make that known to other teams.
A roadmap can also act as a way to double-check the design system’s efforts to make sure the projects on the timeline are aligned with the greater business goals. It will also give you a peek into planning for necessary resources, prerequisites, and ensuring things are operating in a logical sequence of events.
2. System governance
Who is responsible for making design system decisions? What does that process look like? After a decision is made, what downstream actions are set off because of it?
As a system scales it will have to serve multiple teams, and those teams will have competing priorities. A system governance process will ensure input is prioritized accordingly and not because you’re friendly with one of the product team leads.
3. Contribution guidelines
Having system users add new ideas and elements to the system is a great way to encourage engagement and crowdsource work the system team would otherwise have to do.
Contribution guidelines outline how to contribute to the system, how to review those changes, and ultimately integrate those changes back into the system so that everyone else can make use of it.
As a designer, seeing a component in the system that solves my exact problem at that moment is a huge relief. Knowing that someone else contributed that solution brings a lot of warm feels knowing the team has each other’s backs!
4. Performance indicators
Examples of performance indicators are metrics like adoption rates, contribution rates, user satisfaction, component usage rates, or any other measurement that can be linked to how the system is performing.
Like any externally facing product, if a project isn’t providing value to the company, chances are it won’t get the resources it needs, and may eventually be downsized. Same goes for internal design systems. Conceptually having a design system makes sense, but if all the components, documentation, and other investments that have gone into the system aren’t being used, that’s a red flag that shouldn’t be ignored.
5. Training, workshops, and office hours
If you build it, they will come… right? Not necessarily.
No matter how much time you’ve invested in developing all the things in your design system, if people don’t know about it, don't know how to use it, or don’t know who to reach out to for questions, your system isn’t one. People are the lifeblood of any system, so having them engaged and involved is critical.
The best way around this is to be visible. Host weekly design system drop-ins where people can attend if they have questions or requests for new components. Conduct regular workshops for new team members on how to effectively use the system. Make stickers and distribute them out with onboarding welcome packages. Act like any other external product your team already develops to spread the word internally.
Having reusable components, documentation to reference, and a process for how things become part of the system all seem like good ideas, but what goals would these artifacts help drive? Here are some examples.
Product performance is important to the overall business and technical architecture of your product. Nobody has commented “I wish this page was slower!” Refactoring components on a page to perform better and make implementation easier in the long term is a real use case of a design system.
This goal sits mainly on the development side of design systems because there may not be any requirements for design deliverables.
Artifacts that can help drive this outcome:
Developer artifacts
This goal is on the opposite end of the system spectrum from the previous. Where optimizing for page performance relies on a set of efficient code components, updating a brand relies on a cohesive design language. Having a visually cohesive set of efficiently built coded components would be ideal, but not required for a brand update.
Launching a visual update to a brand or product is also a great opportunity to prove how a design system can be a pillar of consistency.
Artifacts that can help drive this outcome:
Designer artifacts
Creating functioning prototypes, not just click-through simulations, are valuable research tools to better understand user needs and expectations without investing time to build a fully realized product.
One of the quickest ways to achieve this is to reduce the time for concept development on the design side by working in low fidelity sketches or wireframes. Development should be able to translate low-fidelity designs into ready-made components, and feed that prototype with realistic data. Presenting this to users will generate valuable insights that no amount of internal circular debates could ever produce.
The key to this process is speed. Repeat this rapid prototype loop as many times as needed to have clarity on what the final product needs to be.
Artifacts that can help drive this outcome:
Designer artifacts
Developer artifacts
Using a design system to build a product is exactly what the system was meant to do. Orchestrating various teams to achieve this end goal is also a sign of organizational maturity and system sophistication. Knowing what artifacts will be most helpful in that goal will rely on recognizing where process gaps may exist, as well as knowing where the team functions well.
Having multiple disciplines working together on a shared goal isn’t easy, but using a cohesive set of tools, documentation, and processes to make the build process easier is exciting, and offloads a lot of stress
Because products are so diverse and teams are so varied, the artifacts below are the same as listed above. This doesn’t mean you need them all, but they all have a place in the product development process as your organization scales and matures.
Artifacts that can help drive this outcome:
Designer artifacts
Developer artifacts
Design operations artifacts
Design system artifacts for enterprise organizations should meet the needs of the groups the system is serving, and therefore there isn’t a starter pack that will work for every group.
Large design agencies with experience developing multiple brands may have a robust set of design artifacts that make their work easier, but fewer developer artifacts if they rely on in-house teams to execute on that vision.
Development-led products that address specific technical challenges will likely have an extensive set of development artifacts to streamline their production, but may have less definition on look and feel or how to approach presenting new design patterns to their users.
The items listed here should give you an idea of what to expect when scaling your design system, but don’t feel you need to check them all before you can start. Each artifact can help system users, and ultimately your end users. Over time your design system toolbox will have enough in it where you’ll wonder how you ever shipped products any other way 🥳.
Do a mini UX audit on your table views & find your trouble spots with this free guide.
Be the first to know about our upcoming release!
.webp)
.png)
