Inside and out — part one

Determining what goes into your design system

Sarah Stevens
Jan 10, 2019 · 5 min read

There certainly isn’t a shortage of great resources about the benefits of using a design system. In large organizations, the number of people contributing to any product can be substantial. Referencing a single source of truth ensures that everyone is on the same page about what your product should look and feel like, helping to maintain a consistent visual language.

At Zendesk, our product designers are incredibly lucky to collaborate with our internal design system team, Garden. The Garden team works to produce a solid system of components and provides the tools and resources to support it. Assets are collaboratively created, with an open-tender approach allowing designers in all locations to have a say about their use-cases, requirements, and preferences.

When it comes to foundational components, the Garden team has us covered. However, it’s not sustainable to think that everything can or should be defined within your design system.

What goes into your design system?

Can this be used in most of our products? and how often is something like this used?

If the component in question has multiple applications across your products, then the established process of adding it into the design system can easily be followed. These are the assets that form your base; the elements that all else is built upon.

Design systems should be thought of as the central body — considering everything else outside of it to be satellite components. Each of these satellites should orbit around the design system, clearly taking influence from the core, and remaining in close contact throughout the evolution of the product.

What is a satellite component?

Card components can be seen in a few areas within Zendesk products. However, they are used to communicate distinctly different content — in line with the functions of the products that they exist within. In this example, the card displays multiple lines of text, tags, and a set of icons specific to Connect.

If we were to consider adding this component to the design system, we would need to find a way to make it modular. Consistent hierarchy and formatting would need to be determined across multiple uses and large compromises made to really get it to work.

The card consists of elements that already exist within our design systems, such as typography, iconography, and buttons. The compromises needed would challenge the core purpose of this card in Connect, and would no doubt have negative flow-on effects if included in the design system. The card stays out.

What components stay out?

Additionally, if you choose to be over-explicit within your design system and favor complex components, then you run the risk of restricting their use so heavily that they are no longer versatile enough to satisfy multiple requirements. While there may be different levels of complexity in the components within your design system, an effort to focus on the elements with fewer functions will result in more flexibility from your system.

The true beauty of a design system can be seen when it finally hits the sweet spot — containing enough broad, adaptable components that your design team can use as a launch pad. It is the satellite components that push your system to its full potential. You’ve reached success when your system can be used as a foundation to build high-level designs that satisfy an endless array of applications.

Lynsey Thornton, VP of User Experience at Shopify echoes this sentiment in the Invision Genome Project when referencing their design system, Polaris: “Polaris is the floor — it’s the baseline of everything we do, but by no means is it the maximum we strive for.”

Consider the objectives of your design system

Has your system been adopted by every member of your design team? Do they use it as apart of their daily workflow? If not, ask them why? Your greater design team may not be the direct caretakers of your system, but you need them to actively engage with it in order to add its value to your organization. Your design system needs to be implemented by your engineering team and prioritized by your product team, so you should buy-in at entry level.

Your system will contain unidentified gaps so you should set aside time to encourage feedback from your team to help develop it into a useable size. If your system has grown so large that it no longer meets your needs, consider being more ruthless in your next edit. The boundaries of a design system will be different for every organization implementing it. However, your design system should never tell the complete story of your product.

The elements inside your design system are incredibly important, but so are the objects that sit outside of it. Always remain true to the objectives of your system to see clearly where to draw the line.

The second part of this article will discuss how to approach designing a satellite component without losing the spirit of your design system and the best practices to share your designs among your team.

We like making new friends. Let keep this going. Check out design.zendesk.com for more thought leadership, design process, and other creative musings.

Zendesk Design

The ideas, perspectives, and musings of the wonderful people of Zendesk Design