This is the last article in our three-part series on design systems and happy teams. In Part 3, we cover the process aspect of your design system and what we can do to ensure team success and happiness. Part 1 introduced the concept of success and happiness and dove into the product aspect. Part 2 focused on the people who contribute to and use your design system. Read Part 1 and Part 2 to get a complete picture of ensuring success with your design system and maintaining team happiness.

Process

From our How We Document report, we will examine what processes behind creating and maintaining a design system can lead to success and team happiness. We’ll touch on governance models, documentation processes, and contributions.

As with the other pillars in this series, you’ll notice that our recommendations include ways to reduce friction, address pain points, and avoid striving for perfection.

Document your design system sooner rather than later

We learned from the report that documentation is part of the natural part of the design system process. Years ago, teams focused on designing a library, coding components, and finally documenting things. Our report showed 87% of respondents started documenting within a year of starting their system.

This is great! (And not just because we’re a design system documentation platform. 😀) When you start documenting earlier, the design system makers and consumers form good habits—documenting and referring to documentation become a natural part of the process, reducing friction. If you delay this, poor habits of not using any documentation can form. It can be harder to get buy-in to use it when it’s ready (e.g., “Why do I need to start referencing documentation now? I seemed to do just fine without it.”)

When you start sooner, you won’t have everything documented, but as it turns out, that’s OK. We’ll go into why next.

Page 28 of the How We Document report – documentation is a natural part of the process

Cover the breadth but not necessarily the depth

Our finding suggests that you want to cover the breadth of your design system. People with design systems that are at least 75% documented are the happiest. This makes sense—the more you document, the happier people are. However, your team can still create happiness without the depth of documentation! From our survey, teams were happy even when the documentation was partially mature. We considered documentation partially mature when it includes partial content and some developer integration, which, if you think of it, isn’t that much!

As you document, try to cover the breadth – or at least the foundations and popular components. Then focus on the basics of writing good documentation (usage, do’s and don’ts, where to find code, etc.), and don’t stress out about documenting every little detail. Eventually, you’ll have everything documented, but the key is that you don’t have to worry about that from the start.

Page 56 of the How We Document report – documentation coverage and happiness

Page 52 of the How We Document report – happiness and maturity

Hold off on version control

Version control is important but probably not the most pressing process from a holistic design system perspective. (Yes, version control for coded components is important, but it’s probably a process already built in.) Our survey shows that only a few have version control in place. Once your design system is more mature, it’ll be a good time to look at versioning your system. If you’re ready for version control, we have some guidance on holistic design system versioning.

Page 35 of the How We Document report – version control is a sign of maturity

Have some process around contribution

When contributing to the design system, we recommend including a process sooner rather than later. From our report, people are happy when there is an effective contribution model for their design system. A formal review process helps with that, but we learned that people are happy even with an informal process. This tells us that any process is better than no process. After all, humans benefit from structure.

Page 57 of the How We Document report – happiness and contribution

Page 58 of the How We Document report – happiness and governance

If you’re creating a process or looking to formalize one, we recommend looking at how contributions currently work. If it’s working, there might not be a need to change the process. It’s just a matter of formalizing the informal process (i.e., documenting it). Sometimes processes that are working might need to change if you’re looking to scale the processes across more products, teams, or people. We recommend trying a few pilot cases to see how things work before solidifying things.

Creating a process helps people feel confident in what they’re doing and aims toward better alignment. A more significant benefit is starting earlier, even if you don’t have the process perfected. It allows the makers and consumers to get in the habit of following a process, even if it evolves. And it will enable you to get their feedback to ensure you create a method that works for everyone.

Provide capacity for documentation

Lastly, if you can make way for more capacity for documentation, teams are often happier. Only some people can spend most of their week documenting, but from our report, even 1-3 days of documenting per week (or sprint) can make a difference in happiness. If this isn’t possible, the main takeaway is to make space for documenting the design system. Some ideas include:

• Building in time for documentation as part of the component creation/update process
• Having one person rotate in for the sprint to focus on documenting
• Switching to zeroheight, which makes documentation effortless – so more can get done in a shorter amount of time

Page 60 of the How We Document report – happiness with contribution capacity

Create a hybrid or centralized governance model

We touched on this in Part 2, but working toward a hybrid or centralized governance process is a great step toward increasing happiness. Centralized models mean there’s a dedicated team working on the design system. This can provide focus and consistency. Hybrid governance models are a combination of having some people centralized on creating and maintaining the design system, but there are representatives across the products to provide feedback and contribute as needed. All models come with their benefits and disadvantages to each. Consider adopting a hybrid or centralized model as you create or refresh your processes.

Page 59 of the How We Document report – happiness and governance models

Success and happiness within the process pillar

As you can see, there are a few things you can do around processes to improve design system success and happiness. Check out Part 1 and Part 2 of the series to see what efforts you can try from a holistic perspective to ensure success and team happiness. Much of what we recommended was about making the most of what you have, trying a few things based on what How We Document reflects with our field, and not striving for perfection.

If you try any of these things, please let us know! We love hearing success stories from teams because they can help our community. Let us know if you run into challenges, too, because we can all grow from those experiences.