Inside and out — part one
Determining what goes into your design system
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?
Using Zendesk as an example, we’re creating a series of complex products often with separate use-cases. Some of our products have existed for ten years, whereas some of our features are merely days old. At the point of deciding what does and doesn’t belong in our design system, we always ask this question:
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?
An example of a satellite component came up in a recent dashboard redesign for Zendesk Connect. Connect is a proactive marketing tool and the dashboard uses a card component to identify campaigns that have been created within the product.
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?
Unless the component that you’re designing is going to be reused many times, then adding it to your design system will simply create extra work for your team. The effort of maintaining a functional and current design system is large, and the work put into it needs to be truly worth it. Remember that one of the primary purposes of investing in a design system is to optimize the workflow of your design team, so asking them to update and maintain single-use components creates an overhead that inhibits your ability to scale.
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
The journey to design system success can take some time. You might find yourself making strategic decisions about what goes in and what stays out many times. A design system is a living thing, it should never be considered “done”. Revisit your system regularly to determine if it is both large and lean enough to meet your objectives.
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.