So, you want to build a design system...

Before you get started, there are a few important points to consider. It's not enough to put together a library of design artifacts and assume your organization will use it. The following tips give you an idea of what to create and rollout for a design system, whether at a small start-up or large enterprise.

You need buy-in

Regardless of the size of your organization, some level of buy-in is necessary to create your own design system. On the small end of the scale, this might mean convincing your direct manager that spending some free cycles creating the foundations and some reusable components is a good idea. On the larger end, you might be in a position where you have to pitch the idea of establishing a dedicated team focused on producing a fully featured design system.

To get buy in at any level, you'll need to explain the value of a design system for the organization. Improving consistency, reducing development effort, and getting to market faster are all great ways to convince decision makers that a design system can be a benefit to your organization. Our ability to tell this story in a convincing way, using real data, was essential for us in getting executive buy-in.

Once you have the support of leadership, your next hurdle is getting buy-in from your fellow designers. In our case, most design teams at Sun Life were already using some form of their own style guide or component library. While the prospect of a unified design system excited most teams, there was still some reluctance to replacing well-established processes. A method to reduce this kind of friction is to involve key stakeholders in the design process. This helps by ensuring the teams who will use your design system feel their voices are heard and their needs are being met. Having buy-in from top decision makers also helps create advocates for your project that will encourage their own teams to get on board as well.

Here are some of the different types of stakeholders that we included early on:

Design leads from each region to provide input as we created page templates, components, and foundations of the design system.

Sun Life Brand representatives and accessibility experts to ensure we incorporated brand and accessibility guidelines in the design system.

Engineering partners to provide input, flag implementation issues and be aware of upcoming changes. We also created a federation model that allowed development teams to help contribute to building page templates and components. Product development teams could work with the design system development team to build components following the correct patterns. This helped product teams expedite component creation for projects with tight deadlines.

The key thing to remember is that the more partners you can establish early on, the easier time you'll have when it comes to rolling it out.

The right skills for the job

Building and delivering a design system requires a wide range of different skills, so you should be mindful of those skills when hiring. It may be tempting to hire a team of designers just like yourself but, if you do, there's a good chance your team might miss out on some important skills. When building a design system, these are the skills we found were the most important to have:

Systems thinking

You want team members who understand how everything works together. They need to understand how changes, additions and deprecations impact all teams and how the system evolves over time.

Development knowledge

Team members should have a basic understanding of how to develop, document, and test components. Having this understanding makes for much easier conversations when handing off designs to developers and communicating decisions to the wider organization.

Interaction design

Team members with strong skills in interaction design can improve communication between teams. Handing off a prototype to your development team helps answer thousands of questions that a static design just can't. A strong interaction designer also helps find flaws in final layouts and experiences that typically wouldn't be noticed until the design is put into action. They also help speed up user testing and presentation development. Motion design skills are also sought after when developing micro-animations and transition effects.

Visual design

Team members with strong visual design skills are beneficial in the decision-making process for component visuals and help keep your foundational styles and elements consistent.

Content writing

Having team members with strong content writing and/or technical writing skills is a huge plus! Having the ability to write detailed and easy to consume documentation for both design and development audiences can help with onboarding teams.

Research

Team members with strong research and user testing skills can help with the auditing and user testing process.

Scalability and flexibility

The only way your design system is going to succeed at your company is if other product teams adopt it. Product teams will only adopt your design system if it is scalable and flexible enough to account for all their needs. It needs to support their individual use cases, account for regional differences, and support different language and branding needs.

To ensure our design system would be flexible enough to account for each team's needs, we completed comprehensive audits to learn how they were using different design patterns. These audits allowed us to account for all the different use cases and inform how we should create page templates. When auditing a certain type of page (for example, login pages), we'd ask questions like: What do they all have in common? What are the outliers? Why are they different? Through this exercise, we were able to produce a single page template that accounted for all use cases.

And we didn't stop there. After designing a recommendation, we asked regional leads to review and test it with real data from their projects to ensure it worked for them. Each template also went through rigorous user testing across multiple regions. For a template to be viable for the design system, we required a SUM score of at least 80%.

Scalability also needs to continue to happen even after the design system has “everything”. We needed a way for teams to contribute to the design system and help us maintain it.

Change management and support processes

Design systems are continuously evolving just as the requirements from the teams using them are evolving. To account for this, we set up an in-take process that allowed product teams to submit requests for page templates and new components.

This in-take process allowed our team to review requests and determine if there was a strong enough need to add the new component or templates to the design system. If we determined a request was a niche request, which we dubbed “snowflakes”, it would be on the product team to create, user test and maintain those new components. These new components would also not be included in the design system.

We also needed a system to provide support to product teams that were onboarding to the design system. Since this was the first true design system at Sun Life, teams often needed a lot of upfront coaching before transitioning to a more of self-service model as they got more comfortable.

One of our onboarding techniques was running weekly workshops called Figma Fridays, where we demoed the design system and highlighted its applications for different projects. We hosted office hours to allow teams to come to us with specific questions on the design system. We also had multiple ways for teams to contact us, either by emailing our team, posting request tickets on a FigJam board or by posting questions in our MS Teams channel. Essentially, we made it as easy as possible for teams using the design system to get in touch with us.

Shortly after the first release of the design system, new component/template requests started to taper off as our team transitioned from an active design state to more of a run/maintenance state.

Continuously evolving

Design systems are never done. Once it has started to stabilize, look for opportunities to use the skills and knowledge you’ve gained and apply it back to project work. In our case, we started offering white glove project support by meeting with project teams and exploring their design challenges. We help guide teams when determining which template or components to use for their specific use case and help educate them in user testing findings from earlier design attempts.

I hope these tips help you get your next design system rolled out. Good luck! I know you can do it.