Now recruiting for a Senior UX Design Freelancer! Click here for more information →
General

Anatomy of an Enterprise-Grade Design System

May 15, 2024
Written By:
Jason Jajalla

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.

Design system artifacts

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

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:

  • Fonts, sizes, and their weights
  • Colours 
  • Spacing and size values
  • A grid system to align page elements
  • Shadow elevations and sizes
  • Iconography

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:

  • Buttons
  • Form inputs
  • Tooltips

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. 

Development

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.

Design Operations

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.

Using design system artifacts in real situations

workflow for creating and updating design system artifacts

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.

Using a design system to make pages more performant or scalable

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

  • Component library: these don’t have to be tied to design UI components, as long as they are functional and can be applied in other areas of the product
  • Documentation: this is useful for ensuring consistency with the components developers are building and deploying

Using a design system to update a product’s visual look and feel

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

  • Design principles: having a vision of what the design is meant to be will help ensure the downstream artifacts are cohesive
  • Style guide: this will keep the design language consistent throughout
  • UI components: this is the atomic and repeatable interpretation of the style guide
  • Documentation: coordinating how styles are applied consistently throughout the product will require some record keeping and chronicling of what to keep an eye out for

Using a design system to create rapid prototypes and design concepts

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

  • Design principles: these will guide the overarching goals of the design, but won’t provide UI level definitions
  • UI components: things like form inputs or content cards will be helpful to have defined if they’re part of the design concept, so that their functionality can be communicated to development
  • Pattern library: definitely not necessary for exploratory prototypes, but if these already exist and can be referenced, they will greatly speed up concept definition and development

Developer artifacts

  • Component library: these don’t necessarily have to be linked to a design UI component, just as long as they are functional

Using a design system to design and build products more efficiently

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

  • Design principles
  • Style guide
  • UI components
  • Pattern library
  • Design documentation

Developer artifacts

  • Component library
  • Design tokens
  • Developer documentation

Design operations artifacts

  • Design system roadmap
  • System governance
  • Contribution guidelines
  • Performance indicators
  • Training, workshops, and office hours

Wrapping up

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 🥳.

UX Heuristic Report Template Kit

Spend your time and life force on capturing heuristics problems rather than endless visual fiddling. Meganne Ohata will guide you the whole way, so you can propel your work and become their most trusted advisor.

$79
$59
Learn more
ux heuristics series

Download our Table UX Audit Checklist

Do a mini UX audit on your table views & find your trouble spots with this free guide.

Available in a printable version (pdf).

Please fill in the form below and it will be in your inbox shortly after.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
letters

Want to dig deeper on flow diagrams?

Be the first to know about our upcoming release!

If you found this intro content useful and find yourself needing to express yourself more efficiently on your software team, this training is for you. Our new flowchart training includes real-life enterprise stories and examples for using flowcharts for UX. You’ll get tips on how to make your diagramming efforts successful, how to derive info for the flow charts, and how to get others to use and participate in the diagramming process.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Get to know us
“Your article made me realize our tables suck.”
Matthew S.
Mazumago
Previous Post
Next Post
Benefits of a Design System