Why most Design Systems fail – and how to cultivate success

Implementing a design system takes more than the creation of the system itself. I will argue that it is more important to focus strategic integration within an organization’s workflows and culture than it is to design a great system.

Having been involved in 3 design system rollouts in my time – both as an individual contributor, as a leader, and as a sponsor, I have distilled what I’ve learned offering a blueprint for organizations aiming to navigate the complexities of design system adoption.

The primary challenge in rolling out a design system is not its development but ensuring its broad adoption across teams. The key lies in strategic leadership and the establishment of organizational frameworks that facilitate this process.

I have found that a foundational strategy for ensuring design system adoption is the application of technical constraints. These constraints, such as deployment strategies and technical standards for implementing UI components, serve to streamline development processes and foster a unified approach to product design. By mandating a singular methodology for design and implementation, organizations can cultivate a cohesive culture that naturally aligns with the design system’s principles.

This is easier said than done. My take on creating the right culture for adoption is to let technical constraints and tooling lead it. The technical constraints should lead the culture, not the other way around.

My recommendations are as follows.

1. Define the primary objective of implementing a design system
2. Introduce technical constraints
3. Only do ‘real work’
4. Secure sponsorship and support from senior management
5. Avoid big bangs – release incrementally
6. Adopt an Open Source mindset
7. Provide a purpose and direction
8. Provide an upside

Let’s get started.

1. Define the primary objective of implementing a design system

The initial and perhaps most pivotal step in deploying a design system is the articulation of clear, strategic goals by senior management.

• Increased team velocity. Streamlining development processes to accelerate project timelines.
• Enhanced maintainability. Simplifying the upkeep of your digital properties.
• Faster Go-to-Market (GTM) and prototyping. Leveraging reusable UI components and data types to expedite product launches.
• Reduction in bugs. Improving product quality through standardized design practices.
• Streamlined onboarding and training of new hires. Making it easier for new hires to acclimate by standardizing UI creation processes.
• Support for fluid teams and cross-team work. Facilitating flexibility in team dynamics, allowing for seamless transitions and the formation of cross-functional groups.

Understanding what failure looks like is just as important as defining success. Failure may manifest in several forms, such as:

• UI/UX refactoring without clear customer value. Initiatives that focus on aesthetic or functional changes not directly tied to customer needs or willingness to pay.
• Complete system overhaul. Viewing the design system project as a one-time effort rather than an ongoing process.
• Little consensus on best practice. Failing to establish and adhere to agreed-upon standards across teams.

These pitfalls underscore a fundamental truth: the goal of a design system extends beyond the implementation of a technical solution. It’s about fostering a shift in the organizational culture and ways of working. Ironically, it’s the technical constraints imposed by the design system that often drive this cultural transformation. By defining clear boundaries and standards, these constraints not only enhance efficiency and consistency but also promote a culture of innovation and collaboration.

The primary reasons for embarking on a design system journey might be very different. It has been for me.

I’ve had the pleasure of leading a design system implementation three times with very different reasons to start:

• Benjamin Media. Back when the term “design system” wasn’t yet a household concept, the lifestyle magazine company had 9 websites for 9 different brands. Our design system initiative hadd the defined objective of reducing development costs and time to market 9-fold, yielding significant financial goals that ended up driving the adoption of design systems.
• DR (Danish Broadcasting Corporation). At the Danish equivalent to the BBC, our aim was to unify disparate tech stacks and improve team velocity. At the government-funded institution, financial goals weren’t as strong a driver – but addressing both operational and cultural challenges was.
• Lenus eHealth. At the Danish hyper-growth scale-up, we found ourselves onboarding as many hires to the product team as the size of the product team itself. Effective onboarding was a serious deal. Here, the need to support rapid team growth as well as ensuring a uniform experience across web and mobile platforms demonstrated the value of focusing on scalability and flexibility in goal-setting.

I would recommend prioritizing outcomes such as increased team velocity, improved maintainability, and faster GTM as the primary goal and have streamlined and updated UI and UX as a nice side-benefit or secondary goal. Besides – if you succeed in widespread adoption of a design system with a centralized repository and version control, rolling out a new splendid UI and UX becomes a walk in the park.

Adoption is more important. Improving UX, in this regard, does not matter to begin with. What good does it do to have perfect UX in 5% of the app, if the remaining 95% never get a chance to experience it – then you have just created an even more fragmented experience.

Adoption first. Great UX second.

2. Introduce technical constraints

By establishing firm technical boundaries, organizations can significantly streamline their design and development processes, ensuring consistency and efficiency across products and platforms.

Technical constraints serve as the framework within which design systems operate. By making it so that there can be only one way to implement new design, organizations can eliminate ambiguity and indecision, making it easier for teams to adhere to established standards. There is only one way to do it.

Of course, if your product is based on several front-end web stacks, you might consider which frameworks to support. Which and how many to support depends on the size of your company (how many people are using the frameworks) and the adoption of each stack. If it’s 45/55% React and Angular, then support both. If it’s 5/65/30 for React, Angular, and Vue.js, then you might consider to just go for the latter two.

It is much easier to drive the transformation of how you work and change the culture by establishing technical constraints than the other way around. Technical tooling is a great driver for cultural change. In many organizations, attempts to shift culture or processes through policy or edict alone face resistance or slow adoption. Conversely, when changes are embedded within the tools and systems that teams use daily, adoption can be swift and more organic. The design system’s technical constraints become the default mode of operation, seamlessly integrating into the workflow and, by extension, influencing the organizational culture.

Implementing technical constraints requires a support system to help teams adapt and thrive within these new boundaries. A practical approach to achieving this is by embedding system architects or senior developers within teams, particularly during the initial phases of the design system’s rollout. This hands-on support ensures that:

1. Teams understand how to apply the technical constraints in their daily work.
2. The design system evolves in response to real project needs and various contexts, ensuring its relevance and utility.

Feedback loops between developers, designers, and system architects are short and effective, enabling quick iterations and improvements.

Do the right things before doing them right.

• In the Benjamin Media scenario, the consolidation of frontend codebases across multiple magazine websites under a single design system required strict technical constraints. By defining a unified way to build and design websites, the organization streamlined production, reduced costs, and increased efficiency.
• At DR, the challenge of unifying various tech stacks and cultures under a single design system was addressed through the implementation of technical boundaries. These constraints facilitated a smoother transition for teams, ensuring consistency across platforms while accommodating the specific needs of different branches of the organization.
• For Lenus eHealth, rapidly growing and ensuring a cohesive experience across web and mobile platforms necessitated clear technical guidelines. By developing and applying these constraints, the team could support fluidity, allowing developers to move between projects without the steep learning curves associated with differing design approaches.

By making it impossible to do design work incorrectly within the framework of these constraints, organizations can ensure consistency, efficiency, and quality across their digital products. Supporting teams to work within these boundaries, especially through direct collaboration and the development of tooling, is essential for fostering a culture that embraces these constraints.

3. Only do “real work”

Focus on doing as much “real work” as possible.

“Real work” being the kind of work that is carried out by teams working on real projects, solving actual problems, and delivering valuable product increments.

The most important work of implementing a company wide design system lies in the implementation. Any efforts done that have to do with the design system should be in combination with doing actual work on solving real customer problems. That is – in combination with completing the regular backlog items of a team. Any design system work should be applicable and in production within a few weeks.

Rather than going big and broad to begin with, worry less about the wide-scale adoption to begin with. Start with just 1 exposed pilot project to design and implement the first few design components and the workflow automation and tooling that goes along with it. Set up the Git flow, Storybook, Figma components. Worry about and test merge and deployment procedures – while you are working on real projects.

Initiating the rollout of a design system with a single, exposed pilot project offers several advantages:

• Immediate impact. A pilot project allows teams to quickly demonstrate the value of the design system, providing a tangible example of its benefits.
• Learning and iteration. Early deployment facilitates rapid learning and iteration, enabling teams to refine the design system based on real-world feedback while preparing the foundation for onboarding a second team.
• Stakeholder buy-in. Successful pilot projects can help garner support from stakeholders by showcasing the potential for broader organizational impact.

Start by embedding a technical design system lead within teams on a project-to-project basis (3 months tenures could be a start). Once done, the design system lead continues to the next team: training, implementing, and refining the tooling to also fit their needs. This arrangement can offer several benefits:

• Expert guidance. Frontend leads can provide expert guidance on applying the design system’s standards and best practices.
• Direct support. Their presence within teams ensures that any challenges encountered during implementation can be addressed promptly, facilitating smoother integration.
• Knowledge transfer. This close collaboration allows for direct knowledge transfer, empowering team members to become proficient in using the design system.

Here’s how we tried to do this in the design system initiatives I was part of:

• At Benjamin Media, the design system was born out of solving a real project pain: solving the same UI bugs on 9 different websites, implementing the same functionality on 9 different websites (with slight variations), and making the same 9 different mistakes on 9 different websites.
• At DR, our strategy was to use a pilot project (the redesign of the dr.dk front page) as a starting point. That facilitated a hands-on approach to integrating the design system, providing valuable insights for its further rollout.

4. Secure sponsorship and support from senior management

The backing of senior management is crucial for providing the design system with the visibility, resources, and authority it needs to be adopted across an organization. This sponsorship signifies to the entire company that the design system is a strategic priority, ensuring that it receives the attention and investment required to flourish.

One of the first steps senior management can take is to sponsor dedicated time away from regular project work for teams to focus on investigating and defining the architecture of the design system. This might include:

• Allocate specific time blocks. Ensuring key employees within your product organization teams have uninterrupted periods to work on the design system is vital for its progress. This is best combined (embedded is best) with doing real work on real projects.
• Assigning leadership roles. Designating a single person to be responsible for overseeing the investigation, definition, and consensus-building around the design system ensures clear accountability and direction.

Regular communication about the design system’s progress and successes is essential for maintaining organizational buy-in and enthusiasm. Senior management can play a key role in this by:

• Feature the design system in Town Halls. Use company-wide meetings to discuss the design system’s benefits, showcase successes, and acknowledge the contributions of teams and individuals.
• Promote success stories. Share case studies or examples of how the design system has improved efficiency, consistency, or user experience in internal newsletters or on the company’s internal Notion or intranet.

5. Avoid big bang releases - release incrementally

Incremental releases allow organizations to introduce changes in manageable portions, ensuring that each component of the design system is thoroughly tested, refined, and validated in actual use conditions. This approach not only facilitates a smoother adoption process across teams but also enables timely adjustments based on real-world performance data and user interactions.

By integrating changes in smaller, manageable increments, teams can rapidly respond to feedback, adjust to user needs, and refine the system without the pressure or risk of a single, large-scale rollout. This method fosters a culture of experimentation and learning, where each release is an opportunity to test, learn, and improve.

A design system redesign project might be planned and executed as an isolated project over 1-3 years, with the new design unveiled all at once in a big bang. While this approach allows for a comprehensive transformation, it carries significant risks. The main drawback is the uncertainty around performance — teams know what the final product will look like but have limited insights into how users will interact with it or how it will perform in real-world conditions.

Alternatively, adopting an incremental redesign approach involves releasing updates in smaller segments, often aligned with sprint cycles. This method might leave some uncertainty about the final aesthetic outcome, but it offers far greater confidence in performance and user satisfaction. With each release, real user data and feedback inform the next iteration, ensuring that the design system is continuously optimized to meet user needs and business goals.

The ‘big bang’ approach, with its waterfall-centric methodology, often jeopardizes performance due to its inflexibility and the high stakes of a single release moment. While this can be great for stakeholder alignment, as all stakeholders can see what they’ll get, it is terrible for performance. Releasing hundreds of changes in a big bang release will make it near impossible to explain the results post launch. You will need to rely on popular opinions. If it went well, stakeholders will most likely claim that it was their change that moved the needle. If business performance went south, stakeholders will more likely point fingers toward elements they did not root for or the “poor implementation”.

Incremental releases represent a strategic approach to design system implementation that prioritizes flexibility, risk mitigation, and continuous improvement. By learning from each release and adapting the system over time, organizations can ensure that their design system not only meets the current needs of users but also evolves to address future challenges and opportunities.

6. Adopt an Open Source mindset

Embracing an open source approach to design system management offers a powerful strategy for fostering collaboration and ownership across an organization. This approach encourages the active participation of all teams and individuals within the tech team, democratizing the process of design and code contribution. By treating the design system as an open source project, organizations can leverage the collective expertise of their entire team, ensuring the system remains dynamic, inclusive, and aligned with user needs and developer needs – across teams.

Allowing everyone to make a pull request or add new elements help empower everyone to contribute improvements, suggest new features, and refine existing components. This level of engagement not only accelerates the design system’s growth and adaptation but also fosters a sense of ownership and accountability among contributors. By participating in the development process, team members are more likely to advocate for the system’s use and adhere to its guidelines, enhancing consistency and efficiency across projects.

However, to maintain the integrity and coherence of the design system, a core team plays a crucial role in overseeing contributions. This team, often composed of experienced designers and developers, is responsible for reviewing pull requests, ensuring that new additions or changes align with the system’s standards and objectives. The core team acts as the guardians of the design system, balancing the need for open collaboration with the necessity of maintaining a high-quality, cohesive product. Their oversight ensures that while the design system benefits from diverse input, it remains focused, consistent, and effective in serving the organization’s goals.

Prior to adopting an open source approach, having clear guidelines for contributions in place is critical. That includes coding standards, design principles, and review processes. Common structures include:

• A list of requirements. What does it take for a new component to be accepted? Adhering to certain data schemas, using the right variables, following a certain coding style, that it includes unit or functional tests.
• Core vs community components. Are some components approved by the core team as “the right way to do things” and even maintained by them? Then allowing teams to contribute their “community” components can lay the foundation of a testing bed for future “core components”.
• Roadmap to acceptance. A detailed explanation of the review process for components to be accepted into the maintained “core”.
• Guide to implementation. Step-by-step tutorials for teams unfamiliar with the design system on how to embrace the new approach.

Providing comprehensive documentation and resources supports potential contributors in making meaningful, aligned contributions. Regular communication, through forums, meetings, or digital platforms, can help in sharing ideas, discussing proposed changes, and celebrating enhancements, fostering a vibrant and collaborative community around the design system.

Treating a design system like an open source project not only enhances its development through broad participation but also ensures its relevance and robustness through careful curation by a core team. This strategy promotes a culture of innovation, inclusivity, and continuous improvement, vital for the long-term success and adaptability of the design system in meeting evolving organizational needs.

At DR, I initially believed that the best way to lead and influence the project was through traditional means: architecting solutions and communicating through PowerPoint presentations. However, three months into our journey, a pivotal moment came when our lead front-end architect expressed a desire to return to what he knew best—coding. He believed, and I came to realize, that his contributions would be far more valuable and impactful through direct involvement in the development process. This was a turning point for me, understanding that leadership in such a dynamic field as ours could be more effectively exercised by “leading through code,” akin to the practices seen in open-source project management.

Adopting this open-source mindset transformed our approach to developing the design system at DR. We started treating the design system as if it were an open-source project, welcoming contributions from all corners of the organization. This shift not only democratized the development process but also fostered a sense of ownership and collaboration across the team. The change in leadership style — inspired by the open-source community — allowed us to tap into the collective creativity and expertise of our team, leading to a design system that was robust, flexible, and deeply integrated into our workflows.

7. Provide a purpose and direction

Communities of Practice (CoPs) within an organization bring together individuals with shared interests or expertise, such as UX design, front-end development, or accessibility standards.

8. Provide an upside

A great side-benefit from dedicated sponsoring of our design system efforts and having those tech-leads responsible for the design system adoption be embedded within teams rather than sitting alone, was the upside that it provided to product managers.

As product managers chose to take part of the rollout, their team would gain an additional expert resource – typically a senior frontend developer – funded entirely by the design system initiative.

This helped lower barriers to adoption by mitigating the common concern of resource allocation and project budgets. The promise was clear: by embracing the design system, teams wouldn’t just be committing to a new way of working; they’d be gaining a direct, tangible benefit that could accelerate their own project’s progress. This expert resource would not only assist in implementing the design system within their specific projects but also serve as a bridge, transferring knowledge and best practices back to their teams, thus enriching the team’s skill set and bolstering the project’s success.

This decision proved to be another turning point in our design system’s adoption rate. Product owners and managers, previously hesitant due to concerns over project timelines and resource dedication, were now more open to integrating the design system into their workflows. The additional expert resource acted as a catalyst, not only easing the transition but also enhancing the team’s capabilities.

Looking back

Reflecting on the journey of implementing a design system across different organizational landscapes, it’s evident that the process is as much about fostering a culture of collaboration and innovation as it is about the technical feats achieved. From embracing an open-source mindset to ensuring incremental releases, each step taken was a move towards creating a more cohesive, efficient, and user-centric product ecosystem. The lessons learned from navigating the complexities of design system adoption highlight the importance of leadership, adaptability, and strategic thinking in driving technological transformation.

It’s not just about creating a library of components or establishing coding standards; it’s about building a shared vision and a collaborative environment where everyone — from developers to product managers — feels empowered to contribute. This journey reaffirms the belief that a design system is more than a project; it’s a cultural shift towards better, more sustainable development practices.

It’s more about embracing a specific way to work than it is about embracing a specific implementation.