In the course of three years of consulting and problem solving for companies with existing design systems, one fact has become (at times, painfully) obvious: Design systems are hard to get right.
In an enterprise context, there’s a lot of organizational complexity to battle. There are almost always multiple products and regions, which means the design system must scale to meet the needs of a number of teams with differing outputs. In order to scale, the team needs defined and reliable workflows, including handoffs between design, quality and development, and those handoffs must be codified in the design system–or what you end up with is just a set of tooling.
To make this happen, there’s a need for solid change management. This must include internal champions at the highest levels of the company, in order to facilitate buy-in across multiple departments and product lines, to get the right visibility and funding for the design system, and to ensure it is both taken seriously and used properly by all adopters.
Below are five reasons why your first design system build can go off the rails—and what you can do to keep it on track.
1. Goal setting
It’s important not only to measure the right outcomes for the design system, but also to evaluate whether a design system is the right solution for your needs. To do this, clarity on your vision and goals is essential before deciding on a design system or any other solution. From here, creating both realistic and measurable goals counts for a lot. Recouping the cost savings of a design system within a year might not be realistic, but the less tangible benefits to customer experience, employee satisfaction and reduced silos can be significant.
A design system offers a number of for your business. However, it’s also important to understand what you want to measure, in order to track the success of your implementation. Is it hours of work saved? Increased collaboration? It can also be the cost savings associated with branding and consistency measures. The specificity of the goal is important, but the method of measuring it counts just as much. Other valuable metrics, such as the number of components built to high accessibility standards, or the number of times a component has been re-used across digital products within the enterprise will also give insight on the success of your implementation.
Without clear and attainable goals, and the ability to consistently show success metrics, the team building your design system may quickly see their funding disappear, their leadership support evaporate, and their ability to scale the design system to other product teams undermined. Getting the right goals, right out of the gate, is essential
More than the work of building the design system, creating the conditions for it to be widely adopted across an organization is a Herculean task—one many companies find insurmountable. Organizations that are competitive, rather than collaborative, will find scaling a design system difficult. The common attitude is: “Why should we use another team’s tool when our processes work fine?”
Creating a , and strong, healthy relationships within and across departments is essential. After all, the point of a design system is to improve collaboration between teams. But without the incentive to build relationships, companies shouldn’t waste their time creating a design system at all—the internal friction it will create will quickly demotivate the design system team and prevent its successful scaling.
Governance for a design system is essential when multiple teams will be expected to use it and contribute back to it. The must include guidelines for how work flows between teams, who gets to do the decision-making, who can contribute, and how enhancements are made. These roles and responsibilities are essential—without a solid and understood governance structure, the design system will start to mutate in the hands of each different product team, creating inconsistencies in user experience across your digital products, which will put your company back at square one.
To combat this, two key pieces of culture enablement are essential: First, there must be a team responsible for consistently updating the design system as new use cases arise, and this team must be regularly communicating these changes to all users of the design system as they happen. Second, all users must feel comfortable contributing back to the design system, and feel confident that their suggestions will be heard. Again, this isn’t possible in a culture of suspicion and mistrust. Achieving scaled practices at any company is only possible with mutual trust and a one-team mentality.
As mentioned in the introduction, no can get far without internal champions. However, in many organizations, the championing is left to the team where the design system originated, and maybe their leadership up to a director or vice-president level. This is not sufficient to scale a design system at a large company, especially a multinational or one with multiple lines of digital products.
The design system must have a number of champions, up to the C-level. The organizations who are most effective at scaling their design systems will have at least two executives from cross-functional departments who are committed to working together to promote adoption of the design system within and across their business lines, will openly demonstrate their collaboration to increase trust, and actively seek support and funding for the design system at the leadership level.
In organizations with a dysfunctional design system, other scenarios occur. In some cases, all design and development work is put on pause for the sake of finishing the design system, resulting in delayed launches and a decrease of revenue-generating, value-to-market activities. The design system must be created in concert with the products it will serve, or the time to ROI will simply be too long for the business to support.
In opposite cases, the design system is a permanent side project of a small team within the organization, who have competing priorities and little time to devote to its completion. The “off the side of your desk” approach, which is where many design systems start, is problematic. For one, it’s definitely not cross-functional, since it’s almost a secret when it’s kept within a single department. Secondly, it doesn’t have the opportunity to attract C-level sponsors, for the same reason. The team cannot hope to ever have the time or resources to finish the design system without sponsorship, and won’t be able to share the benefits of it with their colleagues, even if they manage to complete the project.
5. Getting to scale
The first four points of failure will prevent a design system from ever effectively scaling in an organization, which is its . Scale requires addressing all these points: Clear goals that show consistent metrics, a culture open to adoption of new tools and processes, governance that promotes a collaborative attitude to the design system, and leaders who believe in its worth and can convince others to believe it, too.
Scaling comes down to good communication, but it also requires , and ensuring that the design system is built for flexibility, rather than rigidly structured for the needs of a single product, using today’s tools and processes. Scaling means the design system must change. If it was built by a single team who jealously guard it as ‘theirs’, it won’t be designed to scale, and its adoption won’t be taken seriously by other teams, even if it's mandated by leadership.These five reasons are not quick fixes—solving them requires focus, commitment and openness to doing things differently. Reducing the likelihood of failure is the reason why many companies choose to partner with an external agency to help them stand up their design system. Our focus for is not just building the tooling, but instead on creating the conditions for great adoption. Enterprises are complex, and this complexity is part of their ability to generate value. Cutting through the needless complexity—silos, outdated technologies, inefficient processes and cultural dysfunction, is the promise of a good design system. The ability to deliver on that promise is dependent on understanding the risks of doing it wrong.