Design without the ‘system’: Why design system adoptions fail

In the past year, I have seen a shift from senior leaders in enterprise organizations asking “What’s a design system?” to saying “Yeah, we’ve got a design system. It isn’t delivering the way we thought it would.” This common problem is slowing speed to innovation, and making leaders question the efficacy of having and using a design system.

Poor adoption in your organization can stem from a few deeper maladies, but the source is usually in the implementation. You have to prep your people and your organizational culture for using the design system, especially for teams who were not part of its creation. As with any change, it requires understanding and buy-in across your company.

A design system is simply a tool. And even the best tools can’t help a business if no one uses them properly.

A great design system has a lot of parts—a developer sandbox, clear and up-to-date documentation, and a design kit with usable styles and components, among other things—but it’s not worth much until teams understand its value and how to use it. I've heard horror stories of companies with multiple unique design systems, and teams working on the same product each using different design systems. This is a fundamental misunderstanding of process, and a failure to implement best practices at the leadership level.

Everybody thinks they’ve got a design system, but they’ve missed what makes systems work: people and processes.

In order to fix the issue, your organization needs to address the process issues that were ignored while your design system was rolling out. These problems are fixable! Here are some of the common challenges I have heard about design systems, and how you can address them to get the most value out of yours:

Our design system team did an excellent job on the project itself, but we can’t get traction to scale it across the organization.

When a design system is not effective as originally intended, it’s often because it starts in one department in a large organization, and they have trouble scaling it. While I advocate starting small with a design system, and growing organically out of the original team’s success on a project, there comes a time when that team has to cede a bit of ownership over their work in order for the design system to be useful to others. Adoption is the biggest challenge, and a single team may build a tool that doesn’t fit with the other teams’ work or intended output. It’s hard to think big enough when you’re trying to evolve a design system organically, but without involving other teams earlier than you think you need, you risk building tools they can’t use.

To combat this problem, champions at the executive level are essential—and all the better if they come from outside the design department or original team. They can bridge the gaps between teams, communicate the value of the tool, and mediate the discussion of the varying needs of each team. To find these leaders, you’ll need proof that the design system has value, solves a business challenge you’re currently facing, and will continue to support the business in the future. Do this with proof points on how the design system has contributed to accomplishing company KPIs.

We want to scale/continue scaling our design system for the whole company, but we’re having trouble convincing the C-suite of its value.

Without champions at the top, it’s hard to bring everyone to the table to implement a design system. Do you have a compelling story to tell about design system successes? Build your business case on what’s happening now, not the potential for future successes.

The trend for design systems and design thinking began with the promises for what a design system could do for your company in the future—but asking the C-suite to spend money in the here and now means that you need to identify the DS’s current value. This can be tricky when your design system hasn’t been implemented properly, and teams feel like it has caused more headaches than high points. Focus on those business objectives, then see how the design system can be used to solve them. It’s important to remember that design systems aren’t just for designers—they’re a tool for uniting design and product. And they benefit every team in your product delivery pipeline, including development, quality, product management and delivery. If you have proof points of how your design system has enabled team collaboration, this can be another way to gain or reinvigorate interest and investment in your design system from the leaders in your organization.

Need to know how to position a design system to your stakeholders? Watch this interview with Kim Marchant, VP of Design Operations at JP Morgan Chase & Co.

We have a great design system team and buy-in from the C-suite, but we’re having trouble getting cross-functional/offsite/international teams to adopt the tool.

No one likes to be invited to the party last-minute. Assess how you’ve shared your design system with cross-functional teams, and how (or whether) you’ve asked for their input on process and governance. Change is hard, and a hard-sell approach is not the best tactic.

Communication between your teams is key to a truly successful design system. While the point of the DS is to reduce rework and establish certain-agreed upon principles for creating content for your applications, it doesn’t mean that your teams can reduce communication with one another. Inter-team conflict over the design system can arise when processes and responsibilities are not set into the documentation, or not agreed upon by all teams. It’s not enough to tell teams what they need to do—everyone has to agree and believe that the design system is making the work easier and better.

When the output of the design system doesn’t match the intention, the problem is often a missing feedback loop. This can be because your design, development and delivery teams are still too siloed from each other, or because documentation, design kits or tooling haven’t been kept up-to-date. Questions to address include: What’s the process for updating our design system? How do we communicate across teams? Who contributes to the design system, and who informs all teams when updates are needed or complete? The good news is that answering these questions forms the foundations of your DesignOps practice, and DesignOps can solve these problems. With a design system implemented or nearly implemented, you can consider moving one or more designers from your design systems team into a design strategist role to work on these issues.

Our design system is in place, but it hasn’t improved the speed of our workflow like we were promised.

The purpose of a design system is to make the work of building your applications flow faster, but this won’t necessarily be like turning on a new machine on a factory floor. Building in time for teams to adjust is essential, and some estimates advise that it will take a year between implementation and the intended capacity improvements. If your team is under significant pressure to perform with a new design system, it’s time to consider if the team is large enough to scope it, build it, document it and get it adopted across the company. You may need to invest additional people resources in your team (treating it like a consumer-facing product, not a second-tier internal project), and consider this question: Have you decided who controls the design system? Having a centralized locus of control will ensure that it functions the way it should for each team, and you get the most out of it in productivity and cost savings.

For enterprise organizations, you will need to consider hybrid models, but this does not mean many different design systems.

Not all your products will necessarily adhere to the same branding and user experience expectations, and a single design system may be a serious impediment to different branches of your business. But variations in a hybrid design system can work for your different teams and departments to create a tool they will want to use.

The value of a design system is in the path to design maturity. It’s potentially a long road, but it has real impact on your bottom line. InVision recently studied a number of organizations with design practices, and graded them on design maturity and their design efforts. Of the companies they surveyed, those with the most mature design practices reported that design had a proven impact on profitability. 92% reported increased revenue, 85% reported cost savings, 84% reported improved time-to-market, and 52% reported increased share prices.

My amazing team at Rangle can help companies struggling with their design system to get back on the right path—whether it’s process and change management, or more technical considerations like architecture and governance. Our expertise in building design systems for enterprises means our people have battle-tested insights to share with your practitioners.