To create an excellent design system, treat it like a collaborative process
Design systems have no end date, and you can’t maintain one by yourself
“Why don’t we add this functionality to our design system?” I suggested, causing one of the veteran UX team members to sigh and explain.
“We’ve probably tried every iteration and improvement you could think of. It all comes down to one question: who’s maintaining it?” She replied, almost as if she had expected this.
Like the rest of my new design cohort at the time, I had attended a lunchtime discussion where the department was talking about our current design system. Our design system was pretty good, reflecting on it now, but it seemed basic at the time. There were around 25 design patterns with documentation, so I and several of the newer hires suggested several improvements after the presentation.
It wasn’t until working with the design system for several years that I appreciated what the veteran designer said.
“Who’s maintaining it?” is one of the most important questions to address with design systems. One of the toughest challenges around design systems is that they’re a process, not a product.
The challenges of creating a process, not a product
Creating a design system often requires a different way of thinking about problems than we’re used to.
UX Designers typically work on projects with a defined start and end date. Sometimes, there may be resources to support Designers on the project’s second iteration. Still, we eventually hand off our prototypes to someone (usually developers) and ‘finish working’ on it.
You can’t approach design systems in the same manner. After all, you’re not designing a product: you’re designing a process.
A design system typically consists of three artifacts: a style guide, a component library, and supporting documentation. This is a process that, if properly implemented, might be in use 5 or 10 years from now.
However, there will come a date when you will stop supporting it. Eventually, you’ll be asked to work on another project, take on different roles, or you might even change jobs. Even if you split time between the projects, the design system won’t be your full-time priority.
That means that for a design system to have a long-term effect, it has to last beyond your micro-managing and advocating for it constantly. In other words, the main challenges with design systems are that other people have to adopt them, someone has to keep it updated, and someone has to improve it as your team changes.
This means that, while creating the elements of the design systems are essential, the most critical steps for building a successful system are often the user research to understand how users will use your design system for work.
Make it easy for our users to work with design systems
There tend to be three significant groups of users and touchpoints in creating successful design systems:
Designers: Users who will be using the design system to create their designs
Engineers: Users who will follow the design system documentation to build the system in the front-end
Design system leaders: Users who will be in charge of maintaining and upgrading the design system.
Keeping each of these users in mind is crucial to ensure that the design system will be adopted successfully and used. To do that, we need to ensure that our design system integrates easily into existing workflows.
Here are a few ways how we can do that.
One centralized, additional step
Designers may be okay with doing some digging to find design patterns that make their lives easier, but the other two might not be. One of the first crucial things, then, is to have a single centralized location where users can access the design system.
One additional step is more straightforward to integrate into existing workflows than multiple. In addition, only having one location to access anything you need regarding the design system, from design elements to coding documentation, is the easiest way to avoid any friction.
Automate processes if possible
We should also take steps to automate as much as possible. For example, rather than text that says we should always have 10px between buttons, building that into components can save engineers from asking about that every time.
One thing that is especially helpful for this is templates. While there may be individual design elements in the design system that users can choose from, sometimes pre-built templates (for example, what a page with tabs looks like) allow users to get started quickly with the process.
Creating well-organized elements of the design system (style guide, component library, and documentation) in one location is usually enough to satisfy the first two user groups at the start. But without paying attention to the third user group, users might eventually ignore the design system. The reason for this is the same question that the veteran designer asked us: who’s going to maintain this?
The common problem with many design systems
Even though it’s a process, many people think about design systems as a product.
They’re suitable for a while, as people are aware of the system as a recent project, but inevitably the novelty of it wears away. That’s when you might realize that system needs an update.
Or something breaks and needs fixing.
If you’re still there, this may be where you may jump in and fix it to maintain it. However, you may not always have the time or resources to do that, especially if you’re tackling a whole load of projects.
So it waits on the backburner, but eventually, it might lead to people abandoning the design system altogether. This is because of two reasons.
First of all, nobody wants to do more work. If designers (or developers) use the components, but it turns out they’re obsolete, that’s more work for them to update them.
If they navigate to your design system and the last update was two years ago, should they make an effort to use what’s there? Or is it easier to do whatever they usually do without that extra step?
Secondly, is that design systems tend to lose visibility unless spotlighted. A design system isn’t a shiny new product shown off to teams: it’s a set of components, patterns, styles, and guidelines that help make the design process more manageable.
As a result, a newer designer might not have any idea that it exists unless someone points it out to them.
This is where you need to be on the lookout for that third user group: design system leaders. As you create the design system or show it to other people, keep an eye out and ask if anyone is willing to help you support the system.
They don’t necessarily have to help support the whole thing: instead, they might help with certain things if they need to be updated or some questions need to be answered.
This ties into one other thing to keep in mind that, in some sense, is the most important thing for design systems to do: communicate with the team.
The importance of communication and updates
Design systems aren’t polished high-fidelity prototypes, and they won’t get recognition as other projects receive. Therefore, it can be essential to make sure that you provide a clear, public, and open channel of communication to your users.
Whether it’s e-mailing about the latest design system updates, asking for ideas or feedback through surveys, or presenting awards to teams that use the design system well, it’s crucial to create visibility for the system regularly. Making sure that your team is aware of the design system and the benefits it can provide and answers to questions they may have allows your team to build up trust with the system.
This is where the veteran designer’s advice applies: the best thing to help design systems flourish is to make sure you can reliably maintain them.
The point of design systems is to guide with up-to-date practices as best as possible. If anything feels out of date, doesn’t make sense, or isn’t visible, that can damage the design system more than you realize.
Even small scale design systems can have an impact
While design systems can sometimes be overarching guidelines for every design pattern, sometimes they can be small-scale (i.e., a few design patterns and documentation).
A small-scale design system is not only manageable for you to start maintaining, but it’s also a great way to get more people involved in the process, as they may have suggestions just like I did. If people suggest improvements (and are willing to help maintain it), you can eventually build a more extensive design system that can be useful. Even a simple design system can improve how a design gets built, creating a great user experience. You have to remember it’s a process, not a product.
Kai Wong is a UX Specialist, Design Writer, and Data Visualization advocate. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.