Throughout my career, I’ve created, contributed, and maintained different forms of design systems at various companies. Now I am working as a UX Designer at Chegg, leading the design system efforts.
Depending on the needs of the team, a system can be as simple as a user interface toolkit file or as complex as a multi-page playbook about the brand, UI patterns, collaboration process, and more. There are numerous challenges and considerations that come with working on design systems, and I want to share some lessons I’ve learned over the years for anyone who’s looking to start a new system or improve an existing one.
Starting a design system
Looking at popular design system examples, we are accustomed to seeing versions of style guides with well-organized components and usage documentations. It is common to be tempted to jump right into production mode and crank out patterns to add to a shiny new UI kit, or to get overwhelmed once we realize that the team needs more than just a sketch file filled with component symbols. That’s why it is critical to first define what should be part of your system and how the system will be used in order to build a successful design system.
Understand that a design system is more than a pattern library
When I first took on a design system project years ago, I thought it would be a simple design file with some component symbols. However, if you look at ‘design system’ sites from some of the more recognizable companies in the world, we typically see a combination of the following:
- Brand guidelines
- UI component/pattern library
- Voices and tones
- Process documentations
- Component source code and engineering documentation
- Motion guidelines
- Accessibility standards
Getting a solid grasp of what your team’s design system should contain is a critical step to facilitate alignment, buy-in, and prioritization of your design system efforts.
You don’t need to have everything
Design systems typically have the components I’ve listed above, but they vary across companies because the needs of the team are different. For example, the Chegg design system contains a set of component UI source files, usage documentation, brand style guides, and process documentation. It’s also unlikely you will need to have all the design system components listed in the previous section, or at least not right away when starting a new system. While we all aspire to create an extensive system like Google’s Material design system or IBM’s Carbon design system, such a project requires countless hours of hard work from a dedicated team. Instead of diving right into build mode, take some time with your team to determine what would actually be useful.
You also should not worry too much about making these design system artifacts very presentable until you’ve finished the content. I also advise you to opt-in for a low effort approach to host and share your deliverables, such as an existing file storage solution (e.g. Dropbox, Google Drive, etc..) or third party design system tools (e.g. Frontify, Invision DSM).
Getting buy-in
It is often challenging to convince your team or the rest of the company to invest in resources to build a design system (more thoughts on why and how to overcome this later). It is also common for teams to abandon design system work due to the loss of resources or tight deadlines. Therefore, securing buy-ins and commitments from your team can help ensure the success of your design system efforts. To obtain buy-ins, I recommend you:
- Gather information regarding the benefits of design systems and share your findings with your team and company.
- Treat the design system as a product, plan out a roadmap, and discuss release goals with other stakeholders.
- Rally other stakeholders as allies in this effort. Engineering is a good starting point.
- Ask for dedicated resources. If your team cannot acquire additional resources, request some designers to dedicate a portion of their time to work on the system.
In some cases, just jump in
I know I called out the importance of researching and planning out your design system before starting the work. That being said, sometimes it’s challenging to move the conversation along or to get buy-in. When I tried to pitch my very first design system earlier in my career, I was met with resistance. After several attempts, I learned that the best approach is show, don’t tell. Start by investing some of your time to create a simple version of the design system and share that with the team. From my experience, it is much easier to have a conversation with the stakeholders about the design system once some of your team members are already using and benefiting from it.
Building out a design system
Once you dive into the design system work, you may face an additional set of challenges such as standardizing a pattern with the team and keeping track of changes made to the system. Let’s discuss some of the most common challenges during the build phase.
Dealing with contributions
Depending on the team’s resources, design system tasks may fall under a single person or a small team. Establishing a contribution model and communicating the model to the team can help reduce ambiguity and increase accountability. There are a few recognized contribution models (see a great post that explained contribution models in depth) among design teams:
- Solitary: Single contributor working on a system that serves the many
- Centralized: Dedicated group of designers driving the design system work
- Federated: Committee-by-design approach that empowers a selected set of designers to collaborate on the system
Regardless of which model your team operates under, it’s important to recognize that the design system represents the latest standard of your entire team, and it requires a team effort.
Establish a process
Just like most projects, the road to building out a design system can be messy, especially when it involves multiple team members and cross-functional stakeholders. Having a documented and well-guided process will not only establish order, but is also handy when someone new joins the effort. Discuss with the team and align on how to handle the following:
- How the system should be organized
- How to maintain a source of truth for people to reference the latest standards
- How to seek support when there are questions related to the system
- How to add new patterns into the system and the process for obtaining approval for a new standard.
Keeping a source of truth
One of the hardest things when building a set of standards is keeping track of the absolute latest. When you have a handful of contributors making design updates to multiple components, your team can easily fall out of sync, resulting in inconsistent variations that may sneak into the product experience. To maintain the source of truth, I find the following tactics helpful:
- Maintain a master: Establish a source file (design + code) that is constantly reviewed and updated
- Versioning: Keeping an individual component versioned can help to identify whether a component is the latest
- Align with production: Aim to match the latest component design/pattern with what’s live on the production app. At the minimum, you should match design patterns with the latest engineering built components so that there is a single source of truth for both the design and engineering teams.
Evangelizing your design system
“If you build it, they will come” sounds inspiring, but from my experience, this is not the case for design systems. It takes a good amount of effort to drive awareness. It takes even more effort to promote company-wide adoption and contribution to the system. Broadly speaking, advocating for your design system centers around onboarding, community building, and communicating value.
Start with onboarding
Once some patterns and processes are defined or built, making them known to designers and engineers is the first step to adoption. Hosting meetings to walk through your design system is effective, but can be time-consuming for a large organization, especially when you have to repeat this for new hires. In addition to onboarding meetings, you should create a written guide to communicate the following:
- Resources available in the system and where to find them
- How-to guides on setting up the necessary tools to access the system
- Process guides that outline how your team utilizes and contributes to the system
When the system is updated with new components and standards, the changes should be communicated to the team. It’s a good practice to establish regular meeting syncs or other methods to update the team on the latest. For example, we schedule monthly sync up meetings at Chegg for designers to meet and catch up on the latest system updates.
Growing the community
Behind every successful design system, there is a strong community of support. The sooner you can rally people behind the effort, the faster everything will progress. Focusing on the community-building aspect of the work early on can bring about positive group guidance and accountability. Regardless of the size of your community, you should strive to maintain the following:
- Create goals for the group and keep track of the progress
- Have channels (e.g. meeting, chat client) for members to sync and facilitate discussions
- Make efforts to grow and spread the word about your community
On a related note, not everyone in your community should be required to make active contributions because that can drastically slow down growth. The hope is for more and more members to see the value and volunteer their time as the community grows.
Communicating the value of design system
Compared to other projects on a company’s roadmap, the impact of the design system may not be as obvious. This is perhaps the main reason why many designers and engineers have a hard time getting the initial buy-in to start a design system. To make a case for design system, here are three main benefits you can emphasize:
- Enforces a consistent end-user experience
- Increases the efficiency of your team and output
- Promotes better collaboration between designers and cross-functional teams
To convince your team of the value of a design system, it might also be helpful to seek support and evidence from:
- Advocates from your cross-functional teams
- External experts with experience in design system work
- User research validating the product consistency maintained by the design system
- Data showing improvements to the business metrics or teams efficiency
Once you have some materials to make your case, the only thing left to do is to advocate for your design system. Focus on the key decision-makers at your company, and spread the word to the rest of the organization when possible.
Conclusion
Working on design systems has been both a challenging and rewarding experience for me and my team. Design systems require a great deal of persistence to advocate and develop, but they are one of the most hidden initiatives in the tech industry that has the potential to drive many positive impacts for the business.
Additional resources
There are tons of resources available to learn more about starting and maintaining design systems. I recommend the following:
- Design System Repo has a large collection of design system examples, tools, talks, and more.
- Nathan Curtis is a thought leader in the design system space and he has many articles on the topic on his medium.
- Brad Frost is another leader in the design system world, and his work on Atomic design influenced how many teams organize their system’s components.
- Clarity is one of the largest design conferences for the design system community.
- To connect and chat with others, check out online communities like Design System Slack.
