Having worked on multiple design systems throughout my career, I now know that the launch of a design system does not necessarily mean it will succeed. The push towards a launch date can be enormous, and when you finally get there, the satisfaction is incredible. But the success of a design system relies on many other factors: A design system without functional onboarding processes, documentation, version controls, request management tools, technology, and users is nothing more than a style guide.
Without users, a design system’s power to affect change is negligible.
So what are the common reasons design systems lose the love of their users?
Outside of developing a product that users find value in, adoption relies on other factors too. You need to consider the following:
Does it have consistent documentation? (Users are unclear about implementing a component)
Is there a robust onboarding process? (Users don’t know where to start or are overwhelmed)
Do you have a request management system in place? (Users requests are falling on deaf ears, and bugs aren’t being fixed)
In this article, I am going to focus on user onboarding. I will provide you with strategies to help streamline the onboarding process and reduce the noise when you make your first release.
Material Designs introduction is a great example of onboarding standards.
Design System Onboarding
How to do it and where to start? Before launching, you’ll need to create a streamlined onboarding experience for each user group. This requires a thorough understanding of how users will access the product, configure their workspace, and use it day-to-day.
Audit the existing setup process: Now you can develop a set of instructions for each user group.
Conduct user research: There are many methods — interviews, surveys, usability testing, etc. Most importantly, witness how users interpret the instructions and approach setting up the design system. Look for possible drop-off points. Where did users get stuck? What was missing from their experience? If they didn’t succeed, what did they do next?
Synthesize and identify insights: Based on the feedback, identify patterns, sticking points, moments of uncertainty, and work towards solving them in new iterations of the onboarding process.
In the past, I have included an onboarding guide inside the design system sketch file.
Keep the onboarding process swift and easy
Offer a simple download + install method.
You want designers to feel empowered to start immediately. Think about convenience here. Designers won’t want to have to download things from different places. Keep all the necessary assets in one location and within reach. You’ll probably want to include: Software (e.g. Sketch, Abstract, Github), fonts, logos (PNGs), icons, illustrations, a pattern library, templates, and a branded presentation kit.
Streamline product updates so everyone is working from the same version.
Most robust design systems use an RSS feed to manage and deploy updates. The RSS feed delivers library updates directly to anyone who has downloaded the library. Ensuring everyone has the latest version of the design system. Other tools that can help manage version control and file backups include Github and Abstract.
Surprise and delight via the initial download package.
At a minimum, you will want to include the setup instructions and a list of any other tools necessary they’ll need to use the design system. But this is an opportune time to unleash more value adds for the users. You could include a list of tools and resources to help designers work faster. I typically categorize recommendations based on what is required and what is recommended. For example:
I included the list of plugins inside the sketch file along with other onboarding guidelines.
An example of the designer's onboarding process in Carbon.
Why start with onboarding designers?
If a designer refuses to use the design system, it is unlikely a developer will either. While I can’t speak to best practices for onboarding developers, I can speak to best practices for designers.
Here is the challenge:
Other than personal incentives (faster development, being asked by a manager, etc) no one holds developers accountable for using the design system.
Though adoption has to be mutual between designers and developers, developers do owe some accountability to the designer as their output must honor their design.
TL;DR: Given designers' influence a developer's output, ensuring designers know how to use the product will set off a domino effect.
Well-designed onboarding breeds collaboration
What design tools make your life easier? What makes you more efficient? What tricks help you meet unreasonable deadlines?
Whether it is plugins, open-source platforms, mockups, templates, spell-checkers, etc. they all count.
Lead by example and share those tips in your design system documentation. After all, the very reason for a design system is to create centralized knowledge.
I’ve always found lifting my team up and supporting them to do their best work, raises the standard for your whole team. I guarantee the tips you share will leave a lasting impression on young and inspired designers long after the design system has rolled out. And hopefully, they will pay it forward and you will learn something too!
As a member of a design system team, you have an opportunity to leave a long-lasting legacy behind. Your team has the power to transform the way an organization designs, delivers and innovates. But first and foremost, you need to develop a solution that prioritizes your users and their needs — in this case, your internal delivery teams.
The success of your design system relies on conversion rates — which start with user adoption. Use this opportunity to showcase the power of thoughtful user experience design paired with detailed documentation, consistent communication, and empathy.