50 tips when building a design system

During the last few years, we have both worked in large international organizations building design systems from scratch here in Sweden. We shared our stories and struggles in the webinar “The design process of a Design System.” These experiences have given us many good insights and many hair-pulling moments that can come down to these 50 tips divided into 5 steps: Empathize, Define, Ideate, Release and Optimize. We promise you, this is how we both wish we had done it from the get-go!

Have a read and please make sure to approach it in a similar way. We don’t want one more forgotten component library out there in the universe.

Empathize

Before starting, spend time researching why a Design System is really needed in your organization or what problems it really needs to solve.
Share why the Design System is needed with as many people as possible to get people’s understanding of what you’re working on solving.
Do workshops together with developers and designers to identify what problems they encounter.
Select a few people from your target group to interview to truly understand their everyday challenges.
Make sure the "few" people you select to interview have mixed competences and come from different departments/teams, to get the full picture.
Infiltrate or observe several teams to identify patterns & struggles in their way of working.
Search for similar guideline/library initiatives and sync with those teams. In large organizations, these initiatives are very common to be duplicated. But remember, together you will be stronger.
Search for current and future redesigns to make sure those don't affect the adoption of the Design System later on.
Don't copy goals from others, select goals that reflect the research you did and that speak to your organizations’ real challenges.
Change your goals if needed, they will change as you, the organisation, and the ecosystem evolves.

Define

Create a point of view based on user needs and insights.
Select your first, secondary, and tertiary users. This will help you know who to focus on when starting your design system efforts. And make sure to define how you will support your secondary and tertiary users and communicate it.
Start with changing the organization's culture into a collaborative culture instead of listing inconsistencies. The list will never stop growing ;)
Start your design system efforts by deciding if your team needs to solve inconsistencies, do a gap analysis, focus on unifying brand documentation or create a collaborative culture.
When doing a gap analysis, make sure to have workshops with rotating users to agree on what to get started with and what designs to align on.
If you start by solving inconsistencies, implement one component at the time. When everyone is consuming them, future improvements will make a bigger impact.
Decide how public and how private the Design System will be. This will largely affect the users you have selected.
Define which platform you will start building a design system for and why. Choosing the right platform to start with is essential for the complexity of components and adoption.
Nathan Curtis has identified team models, decide which one you want to strive for and keep evaluating the weaknesses & strengths of each.
We recommend the Hybrid team model that Salesforce use, we believe it would allow the Design System to grow in the best way. A core team has ownership and core contributors come together to contribute, improve and establish that the design system is being used.

Ideate

When choosing tools, always prioritize tools that make collaboration easier. Even if it means you need to fight corporate. It’s worth the fight.
Don't force people into new tools, use what they are using today or make slow introductions.
When choosing a prototyping tool, remember license updates and corporate security can really affect people's access.
When selecting a code framework, think of how other teams, using other frameworks, can use the same components. Minimize this effort by reducing the framework layer in the components to the minimum.
Create a process for new components including acceptance criteria. Test your process and refine.
Document it all. Updates, research, design rationale, even if you don't think people will read it, they will. Take our word for it.
Display your documentation in one place. Not divided by dev/design, and make sure it has all the content needed to explain your thoughts/guides on that component.
Test, test, test. Take the time to test it all, any new component, tool or documentation.
Create a beta test and choose a team that is excited to work and try out the design system. There is such a thing as the wrong audience for a beta.
When testing, adapt to the teams’ way of working. And do this with every team. If your organization is too large for that, at least focus on doing it with 3-5 teams to begin with.

Release

Release updates continuously and always communicate them through various channels.
Evangelize as much as possible. Selling the design system is one of your topmost important tasks.
Set goals and metrics for the release. This will help you understand your progress and sell yourself better to management.
Promote the way of working with the Design System. This requires a shift in the way the teams share work between each other and even the culture inside the organization.
Make an introduction to the design system team a part of the onboarding routine for new staff.
Find your fans. They will be your advocates and spread awareness to a larger audience.
Get the Design System into the team backlogs by helping them break down adoption steps.
Make teams commit to a plan.
Celebrate adoption. Every small adoption should be a reason for a positive reward.
Identify where in the Innovation Distribution your Design System is to make sure you approach your audience with the right strategy.

Optimize

Create feedback loops to receive feedback consistently and through different sources.
Continue to do surveys and interviews with your users to improve the design system and evolve the Design Systems’ goals.
Build a community where people can discuss and help each other. Keep the community full of energy so it doesn’t die out.
Create a process for designers to contribute to the documentation. Get people to feel ownership so they want to contribute.
Create a governance board where you meet and align, especially if you have multiple Design Systems.
Create metrics that can help you understand what people are using, how often, and what they are not adopting. These are essential to know what steps to take when evolving.
Build & communicate your backlog priorities: new components, improvements, contributions, and deprecations.
Set rules for creating new components. For example, only if 2 or more teams need a component, it shall be created.
When you decide to improve components based on feedback/bugs, make sure to set expectations right. How much of the component you will edit, when you will release it and how teams can follow it.
Do not adopt the Design System for another team. It is their work to adopt it, your role as a design system designer is to guide them through the integration.

Good luck on your Design System journey!

/Kajsa Westberg and Lina Alvis