We all know the benefits of building a design system. It creates consistency within the design team, enables easy handoff to the development team and creates a foundation for rules and guidelines for a product.
Before I dive into why I believe design systems can fail, let’s talk about what it is.
Design systems are a collection of reusable functional elements used in product design. It helps make the process of design to development as easy as possible by maintaining consistency of experience. This is done by providing states, text styles and colours placed in a tier like this:
These components are built in a system that allows all designers in a team to use as building blocks for their work. It also is created in a way that allows for the easy export to development handoff tools as shown in the workflow diagram below.
This is great because it allows designers with a large team to begin building and focuses on the functional business requirements of a user story rather than play with pixels and colours.
Why design systems fail
There are a few challenges with design systems that can lead to failure or inefficiency.
Lack of adoption
If designers in different teams do not adopt the components used in the design system for whatever reason, we lose the consistency required to develop a good user experience. Often this comes to a designer’s understanding of Figma and the design system itself. If designers are not educated on the benefits of using components or even how to use it, we lose the efficacy of the whole process.
Moreover, you find yourself or a designer ‘detaching’ components in their local files, then we need to communicate within the team about why this is happening. Is there a variation or a use case that hasn’t been thought of? Can we take that use case and apply it to the rest of the product? Can this use case be added as a variation in the design system? These are all questions that need to communicated within a team if we find ourselves going against the principals of the designs system, we need to understand why it’s happening and how to best resolve it.
This takes use to the next reason for failure.
Using components in a individual profile file works well but who is maintaining the design system itself? Does it require ongoing maintenance?
I believe that the design system is owned by the design team as whole.
Just as everyone in the product team is responsible for the end user experience; the design team is responsible for maintaining the elements we work with. Ensuring they are used correctly and updating them when required with updates that reference why the change was made.
The design system is not published often enough
There is a balance between publishing design system changes often enough to keep everyone updated, but not to the point where it is annoying to it’s consumers. If as a team we communicate about the frequency of the changes and why it’s happening, it’ll keep the team informed.
Designers have the option to Dismiss these updates at anytime, however it’s beneficial for the team that everyone is kept updated and pull in the latest changes as soon as possible.
Designers don’t know how to update the design system
If designers are not familiar with components, variants and how they impact the instances on other files, you may run into a major issue.
Let’s say for example you have 100 instances of a button, then you change the layer name of the text on that button and publish it. What can happen is that every instance of that button gets reset to the default text and you’re left having to go through and update the unique text changes that were originally made.
This is why it’s crucial to apply a design library ideally at the start of the project using well known components. Informing everyone on the design team how to update and edit components. Only doing it when absolutely necessary.
Every designer works in their own way, so aligning on something as simple as design components will help us design and build faster with an experience that is seamless. Regardless of who is designing it.
Alternatively, in large design teams it’s possible to assign the ownership of the design system to one person. Minimising the risk of breaking components.
Organisation don’t see the benefit in creating one.
Simply selling the idea of a design system can be challenging in itself. What I have always done when working within an organisation is to create the design system as part of the project. As the saying goes, ask for forgiveness rather than permission. Investing in the time to build a design system whilst designing out the project goes a long way in selling it when it comes to the build. Not only benefitting you in future, but creating consistent experiences within the code base and UI.
When you have the design system in place or just the foundation of one, it means you can show first hand the benefits of how it all works. Not only that but it allows new designers to onboard seamlessly, reducing the time and money it takes to share knowledge and fix inconsistencies within files.
And that’s my list for why design systems fail. We can address these issues as discussed with communicate and education within the design team. This will in turn make the design system a powerful tool that your team and organisation can benefit from in the long run.