💡 This is a three-part series on design systems and happy teams. This article introduces the concepts behind what makes design systems successful and teams happy. And in each piece, we’ll cover a different aspect of the design system: product (the design system itself), people (the design system makers and consumers), and the process (how teams work to create and maintain the system). Let’s get started!

Introduction

We could craft the best design system with the right tools and unlimited time and resources. But that’s a rare luxury in real life. Instead, we often have to make the most of what we have, which can feel challenging and discouraging. Rather than sulk in our woes and contribute to despondent team morale, there are some things you can do.

In our How We Document report this year, we asked about people’s happiness with their design system documentation. We correlated it with responses to questions about their design systems, teams, and processes. Thinking of this information, along with our experiences working with a range of design system teams, we have a good sense of how design system leaders can create successful systems and happy teams.

We’ll examine what happiness and success mean with each of the three pillars of design systems – the product, the people, and the process. This includes:

• Leveraging existing resources, tools, and methods to optimize workflows
• Creating a culture of ownership
• Measuring success

Before we jump into the “how,” let’s take a closer look at the happiness factor from How We Document.

Design system documentation happiness

Our survey asked how happy people were with their design system documentation. Out of 518 respondents, about a third were mostly happy, and about a third were neither happy nor unhappy. A little under a third were mostly unhappy. Regarding the extremes, 10% of people were very unhappy and 3% were very happy.

Overall, we can interpret that over half of the respondents are generally unsatisfied. When we asked about the reasons behind their responses regarding their happiness, a few prevalent aspects emerged from the unsatisfied ones. They included frustration with tools, lack of time or people, and the amount of work left.

Page 51 of the How We Document Report – design systems teams need a hug

I completely understand those sentiments, and unfortunately, they’re common issues many teams face. When I led a design system team at an enterprise company, we had the same frustrations, and I wanted to try my best to improve the situation. My realm of control and influence felt small inside of a large company, and I also felt like I was solving this problem in isolation – so looking back, I probably didn’t go about things the ideal way.

But that’s what I find fascinating about digging into the data from this survey. By correlating responses, we can speculate what teams do that influences happiness. We can understand how accurate these correlations are from zeroheight’s experiences working with design system teams and speaking with experts. And we’re excited to share these ideas with you, so you don’t have to find these solutions alone. (Past me wishes this information was around before.)

At a high level, when we think of fostering happiness, we’ve come up with these basic principles based on our recent How We Document webinars:

• Reduce friction for people
• Address pain points for design system makers and consumers
• Do not stress about perfection

If you have a UX background, the first two seem obvious, but our approaches to resolving them might not be. The last item of not stressing about perfection might be a mindset shift teams have to make. Many people assume that design systems need to be perfect because they are so foundational. But that mindset is dangerous–it sets unrealistic expectations.

Design systems constantly grow and evolve, never reaching a finished or perfect state. It’s also typical that the ideal solution isn’t possible or the team isn’t 100% confident in any solutions. Instead, they choose an answer they think is best for the moment, knowing they’ll likely have to change it later.

Striving for perfection often takes a long time. And the more time you wait to release a part of your design system (e.g., a component, documentation, etc.), the more you make your design system harder to adopt. While the team is busy perfecting things, the rest of the organization navigates design and development independently, making up their own rules (which could include creating bad habits). By the time you’re ready to release what you’re working on, people won’t feel the need to adopt it—they’ve done well without it, and changing their existing workflow can feel onerous. Instead, small-scale, work-in-progress approaches tend to gain traction in the long term. There’s less at stake, which also means there’s often less resistance to change. By implementing something smaller, the team can iterate and improve, which is much more manageable.

Lastly, the weight of trying to achieve perfection can cause a lot of pressure and stress on managers and the team. This can often lead to burnout, low morale, and even employee attrition.

The importance of happiness

You may wonder if focusing on happiness should be a priority. We think so! Working on a design system is challenging, even if you have all the tools, time, and people. So when external factors and the nature of the work add additional challenges, it can make things feel even worse. For more context, check out Taylor Cashdan’s thoughts on pursuing a design systems role. There’s even an article on surviving design systems work by Henry Daggett. If you take away one thing from this article, it’s to prioritize ensuring happiness with design system makers.

Studies show that happier employees are more productive because they are:

• more likely to engage in the work
• less likely to be stressed
• less likely to seek a new job

OK, so let’s see what can be done from a product perspective to boost happiness.

Product

In this article, we will treat the design system itself as a product (although, in other cases, you could call it infrastructure). This includes the design and code components, documentation, and the tools used to house it.

Let’s find opportunities to reduce friction and address pain points for design system makers and consumers. Let’s also consider what’s suitable enough without aiming for perfection.

Evaluate the tools you’re using

Consider what tools your team uses to design, code, document, etc., for your design system. This can help provide a sense of any potential issues.

Make a list of your tools, then:

• Identify what you’re using them for
• Ask design system makers and consumers what pain points they have with them
• Ask what would contribute to their success
• Brainstorm with them to find alternatives to reduce friction, remove or improve pain points, and contribute to their success

Solve common tool pain points

Based on what your team is experiencing, think of ways to improve the situation. Here are the common friction and pain points, along with some approaches to remove or alleviate them:

Too many tools lead to confusion and redundant work.

Take a closer look to see if you can remove any redundancies or find a tool that helps remove redundancy. For example, if you’re tracking design system work in Trello, but the team uses Jira for everything else, consider switching to Jira. It reduces one less tool and integrates it into the organization’s existing workflow.

Difficulty using the tools (e.g., it takes too long to make simple updates, designers using tools made for developers, etc.)

Sometimes you want to make the most of what you have, but it comes at the cost of time and cognitive load. Ultimately, your team might spend more on salaries to complete the work, and a better tool is cheaper. One of my previous teams used a tool that required us to make several separate images (e.g., specs, variations, etc.) for the documentation in addition to making the components themselves. Creating images, exporting, re-uploading, etc., was too much effort for an already under-resourced team. Our documentation was always outdated, and because of that, people were hesitant to use it. We eventually switched to zeroheight because it makes maintaining documentation updates effortless.

Dependency on particular skills, roles, and permissions (e.g., relying on a dev to push changes, only one person knowing how to use a tool, etc.)

When teams have to rely on one or two people to accomplish a task, that could potentially create a bottleneck in the process. This is especially true if you’re relying on people working on other projects besides the design system. Typically, people in this situation try to fit design system work, which might not be the priority. In general, having a single point of failure (SPOF) is something everyone should avoid. Ideally, your team has tools that allow more people to maintain or contribute without requiring strict permissions or unique skills, so bottlenecks and SPOFs don’t become an issue.

Tool recommendations from How We Document

From our How We Document report, we can suggest a few solutions to explore. Even if your team isn’t ready to implement these recommendations, you can use this as inspiration for later.

Documentation lives across many tools

Many of our respondents have them living in the code, the design tool, and third-party design system managers (DSMs, such as zeroheight). From our respondents, the most common combination was Storybook and zeroheight, which we’re not surprised by. Storybook is popular among developers, and zeroheight conveniently integrates with it (i.e., it doesn’t cause friction with developer workflows).

Consider using a third-party DSM, like zeroheight (you can get started for free)

From our survey, we learned these respondents tend to be happier than those using the design tool or a self-built solution. Those using self-built solutions remarked on the difficulty of updating them or that their needs have outgrown the solution’s capabilities. Considering that I see how much goes into making a product like zeroheight, this makes sense. Teams creating self-built solutions are essentially making bespoke DSMs without the depth of knowledge needed to build a scalable solution. With how quickly the design system landscape evolves, it’s a lot of effort to maintain a self-built solution that will grow along with it. Respondents explained that using a third-party DSM made it easy to maintain documentation and navigate.

Page 31 of the How We Document Report – popular documentation tool combinations

Page 61 of the How We Document Report – happiness with documentation tools

Contents of your design system

Regarding what your design system should include, we need to remember that we aren’t striving for perfection, where perfection is 100% of your design system components, documentation, and libraries. Instead, it’s much more manageable to prioritize your components and get the essential ones in your system and documented.

In a previous webinar we hosted on starting your design system, Lily Dart mentioned focusing on creating form-based components because the product her team worked mainly on form design. This allowed the team to get used to the design system and keep them moving on what was most important.

If you’re looking for inspiration, page 33 of How We Document ranks the most popular items people document in their design system. While this will depend on your product, this is a good framework of what to consider.

Page 33 of the How We Document Report – what people are documenting

Including design tokens in your design system

We often see design system teams fret over design tokens – deciding what to create tokens for, how to organize them, and what to name them. This can be very taxing on a team, and we see the pressure teams put on themselves. Some perceive design tokens as foundational and feel the need to get them perfect because of that. But we recommend trying a few, seeing how well it goes, and deciding what to improve or scale. Setting this expectation can relieve a lot of stress.

When to add design tokens to your design system depends on many factors. Our survey showed that people who started newer design systems were likelier to include design tokens. This makes sense because it’s easier to include when you’re starting from scratch. Older, established products might not be as agile when adding tokens. For example, teams might have to refactor code to support them. Consider your products’ maturity and whether design tokens make sense or are feasible to implement.

If they are and you’re unsure what tokens to consider, our How We Document report summarizes what other teams are doing. This can be a good starting point when considering the products that would leverage tokens. The most popular design token combination included: borders, colors, radius, shadows, spacing, and typography. We learned that most teams create tokens for 5-7 design elements. We can guess that creating too few isn’t worth the effort, and too many might not be necessary.

Page 42 of the How We Document Report – design tokens people are using

Success and happiness within the product pillar

As you look to build a successful design system and foster a happy design system team, consider making the most of what you have. It’ll put you in a better headspace instead of yearning for that amazing tool, more time, or more teammates, that you might not be able to get right away.

Consider removing friction from the tools that create and host your design system. Think of ways to prioritize parts of your design system without pressuring yourself or your team to get everything done (and perfectly, too!). Creating design systems is an iterative process as much as any other design project.

💡 Check out Part 2 and Part 3 of this series, where we’ll dive into finding success and team happiness through the people and process pillars, respectively.