Why Design Systems fail?

Why most Design Systems fail – and how to cultivate success

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.

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.

Te goal of a design system extends beyond the implementation of a technical solution

At the outset of a design system initiative, it’s essential to interrogate the motivations behind the endeavor. A common initial response might focus on the aspiration to create a streamlined user interface (UI) or user experience (UX). While achieving a cohesive UX is valuable, framing it as the primary goal risks embarking on an indeterminate journey. The crux of the issue lies in the open-ended nature of UX enhancement; it’s a project with ill-defined boundaries, difficult to declare complete.

Instead, the true measure of a design system’s success should align more closely with tangible business outcomes and operational efficiencies. These might include:

• 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.

Ironically, it’s the technical constraints imposed by the design system that often drive this cultural transformation.

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.

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.

Any efforts done that have to do with the design system should be in combination with doing actual work on solving real customer problems.

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.

After promoting the first few success stories, it’s likely that other teams want to join in on the fun. Some might even express their disappointment that they weren’t picked to be part of the pilot project. This is a good sign. This is the luxury problem that you want.

After promoting the first few success stories, it’s likely that other teams want to join in on the fun. Some might even express their disappointment that they weren’t picked to be part of the pilot project. This is a good sign. This is the luxury problem that you want. It means that there is a pull and you don’t have to push the change anymore. Rather than making excuses for why they have to wait, be prepared to support and sponsor them with similar expert guidance, possibly expanding the core design system working group from one to two.

For a design system to be effectively integrated into the organization’s workflow, it must be supported by a set of clear working principles. Senior management’s role includes:

• Establishing clear guidelines. Developing a clear set of principles for how the design system should be used and maintained
• Enforcing the guidelines. Put systems and structures in place to ensure that projects adhere to the design system by making compliance a part of project review processes. More about that later.

The support and sponsorship of senior management are indispensable for the successful implementation of a design system. By dedicating resources, highlighting successes, and supporting clear working principles, leaders can ensure that the design system becomes an integral part of the organization’s culture and processes.

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.

Releasing hundreds of changes in a big bang release will make it near impossible to explain the results post launch.

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.

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.

Many agile practitioners would argue that these CoPs should be completely self-organizing and self-governing without the interference of senior management. I disagree respectfully.

Many agile practitioners would argue that these CoPs should be completely self-organizing and self-governing without the interference of senior management. I disagree respectfully. On the contrary, I have seen great results from giving each CoP clear missions, while respecting their right to self-organize around them. By defining clear missions for each CoP, there is a mechanism to utilize their collective knowledge and passion to support and enhance the design system. These missions might involve identifying and disseminating best practices, reviewing and giving feedback to proposed new components, exploring new design or technology trends, or fostering mentorship and skills development. A well-articulated mission helps CoPs focus their efforts on areas that offer the most value to both the design system and the broader organization.

Technical guidelines serve as the backbone of the design system’s implementation, ensuring consistency, reliability, and efficiency in development processes. For tech leads and engineering teams, these guidelines might cover aspects such as coding standards, component reuse, accessibility compliance, and performance optimization. By clearly defining these technical parameters, organizations can streamline development workflows, reduce redundancies, and foster a culture of quality and excellence. Tech leads play a pivotal role in developing, disseminating, and enforcing these guidelines, acting as both educators and advocates for the design system’s standards.

At DR, we sought to leverage this by forming Communities of Practice (CoPs) around key areas such as UX/UI design and front-end development. Each CoP was given a clear mission:

• UX/UI Design CoP. To standardize user experience principles across all DR platforms, ensuring consistency and familiarity for users.
• Front-end Development CoP. To create a unified front-end framework that could be adapted across DR’s varied digital offerings.

These missions helped focus the efforts of CoPs on strategic areas that directly contributed to the design system’s goals, fostering a sense of purpose and collaboration among team members.

We established comprehensive technical guidelines to ensure that the development of the design system and its application across projects were consistent and efficient. These guidelines covered:

• Component reuse and modular development practices to speed up development and ensure UI consistency.
• Performance optimization standards to ensure that all digital products provide a smooth and responsive user experience.
• Accessibility guidelines that all projects were required to follow, ensuring inclusivity and compliance with legal standards.

Tech leads were instrumental in developing these guidelines and worked closely with engineering teams to implement them, providing training and support where needed.

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.