How to organize and maintain design systems in Sketch

Recently, I talked about how to build a design system. I covered basic components like Color Variables and Styles, and how to work in guidelines and agreements. But as your design system evolves, you might find yourself with way too many elements to sort through. Don’t worry! There’s nothing some good organizational best practices can’t fix — at least when it comes to design systems.

Today, we’ll learn different techniques to group and organize our components. We’ll also touch on some things to keep in mind as you grow your design system.

Let’s take a look 👀

Embrace your inner organizer

When we think about design systems, we often think about a single Library for every component. But there’s no rule that says you need to keep everything in a single document. For example, you might want to have separate Libraries for different types of components, and even another document to hold guides and documentation.

In Sketch, you can use Projects and Collections as primary and secondary levels of organization. For example, you can create a Project for your brand and group your Libraries and other design documentation into a Collection.

The more complex your design system, the more creative you can get. However, I suggest keeping it simple at the beginning — the more levels you add, the more challenging it’ll be to find the right components later on.

Choose between platform-agnostic and platform priority

If you work in product design, a helpful starting point is choosing between platform agnostic and platform priority. By this I mean choosing whether you’ll focus on components or on platforms — such as devices, operating systems, browsers, etc.

With design systems, it’s easier to update and maintain components and all their variants at once rather than having to look for the same component in many different places (per platform). This is a platform-agnostic approach.

On the other hand, with platform priority, you’re more likely to search for and select components for a specific platform. Rummaging through platform-specific components may take more time, but it also means your design system will be easier to scale and maintain. A good example of platform priority is Apple’s UI kits.

Both approaches have their merits and their downsides. The important thing is to choose early and stick with your choice. And make sure everyone else working on the design system does, too!

Group your components

As you create components, it’s good to think about how they relate to one another. Ask yourself questions like: is this Symbol the inactive state of another Symbol? Or, is this Artboard Template specific for a device?

Decide on a set of naming conventions to help group components together and even create hierarchies between them. For example, you might have a standard button Symbol but then create additional versions that you reuse frequently like an inactive state variation or a button with a different CTA. By naming these Symbols ‘Button’, ‘Button/Inactive’, ‘Button/Buy-Now’ ‘Button/Inactive/Buy-Now’ and so forth, you can group them automatically within Sketch.

Whenever you search through your components these buttons will show up next to each other, making it easier to find or swap. However, try to keep your component hierarchy as flat as possible. Always ask yourself if it’s possible to simplify your current approach before settling on a structure and adding unnecessary complexity.

Work with one source of truth

As your design system evolves, you may find yourself in situations where you need to make substantial or provisional changes. But how can you make changes without disrupting your teammates who might already be using your design system’s components?

Starred versions can help by setting the latest (or any) iteration of your design system as the default that others can keep using. That means you can work on a new version without affecting your team’s workflow. Once you’ve made all the changes, you can Star that version of the Library and we’ll deliver the update to anyone using the Library.

Here are a couple of extra tips on how you can use version stars to manage your design system better:

• Add a page for previewing changes. With a dedicated page for high-fidelity mockups and screens in your Library, you can see how your component updates would affect the final design — all without needing to star the version or push any real updates.
• Add a description. You can add descriptions to your starred versions to describe any major changes, making it easier for your team to find the right one.
• Set “release dates” for your team. Depending on your update cadence, you can set a specific day of the week or month to star new versions of your Libraries. Having a set date can also give your team a timeframe to check and test any changes before releasing.

Starring versions can be incredibly helpful for maintaining and growing a design system over time. It provides control, documents your changes, and separates creation from consumption.

Build out your components using Styles

As you create components, try to rely as much as possible on Styles and Color Variables instead of customizing each component separately. This approach guarantees that, if there are any style and color changes somewhere down the line, you can easily update components and screens without too much disruption.

For example, imagine you design a landing page based on brand colors and typography. If you used Color Variables and Styles, you can rebrand the whole design by making changes to these Library components instead of needing to update everything individually.

Establish a design system council

Regardless of the size of your team, it’s probably a good idea to have periodic sessions to determine the state of your design system. We can call this the design system council, and it could be made up of however many teammates who need to be involved.

The goal is to keep the conversation going around your design system and whether it’s working for everyone in its current state. Through these sessions, you can decide which elements to remove, combine, add, or modify. Use the time to establish your design system’s architecture, set up principles around evolving and creating components, and define your documentation goals and versioning strategy.

Overall, setting up a design system council is a good way to gather feedback and give everyone a chance to talk about their own experience and pain points. They’re also great for keeping all the important stakeholders in sync and making sure that everyone on the team feels included. Rituals and procedures are up to you — nobody complains about free pizza! 🍕

Ultimately, a design system is only useful if people actually use it. Establishing a council will increase the likelihood that the design system speaks to the needs of the team or organization. Plus, it can dissuade people from going rogue and creating their own components outside of the designated Libraries.

Design systems are as versatile as they are helpful, but they do take some legwork at the beginning. Give yourself and your team enough time to consider your needs and which techniques you can use to best address them. That way, you’ll be building a design system that truly works for you — and give you an extra confidence boost when iterating and expanding later on.