We’ve been building design systems for organizations large and small for over five years now, and going through the process multiple times reveals patterns some might not otherwise see when in the trenches of a design system team. We want to share the most common pitfalls we see companies make who are planning or stuck in a failing design system project.
Design systems are no longer a "nice to have" but foundational to succeeding in the new digital economy. With multiple brands, product lines, and a global customer base, today’s business leaders can’t play guessing games with their digital experiences. But, it’s not enough for organizations to just have a design system. Without widespread adoption and use across teams, design systems never deliver the value promised, and the time and money invested are wasted.
An adoption-first approach to design systems
Adoption is challenging at scale, especially in large and complex enterprises, where design and development teams are spread out across the organization with different needs and ways of working. When it comes to Design Systems, if you build them they will not just come. But why?
Below, we discuss five common design system adoption pitfalls and our recommendations on how to avoid them.
Five common design system adoption pitfalls
1. Component coverage and a big bang release as the primary goal
Design system initiatives almost universally prioritize creating a wide range of components and releasing them all at once. This approach often overlooks the importance of smaller sets of tokens and components that teams can start using right away and derive immediate benefits from.
Even more critically, design system teams lose valuable learnings they would get from a leaner and more iterative approach that focuses on building the minimal end-to-end design system and gathering feedback from the consuming teams on what they like and don’t like and what’s missing. Don’t try to guess.
The number of possible issues in the coverage-focused approach is compounded by multiple components and multiple teams. We notice the complexity of adoption issues often isn’t well understood until it’s too late and too complex. The big launch attracts more complaints than accolades. Stakeholders are angry about a lack of promised results, and things start all over again 6-12 months later with a newly hired design or marketing leader.
By waiting until all the components are complete and releasing them in a big batch, the development process becomes long, intensive, and risky with no feedback loops, resulting in low adoption and eventual failure. There is no design system product market fit.
2. Thinking a Design System is mostly a bunch of lego block-like components.
Components are important, but the component library or design kit is only part of the system. A design system is really a new way of building software and working, so they require a heavier focus on change management than most organizations realize.
You build software and products differently as a result of having a design system. Change management around that is challenging in and of itself. If you bring in too many complex components, the amount of things that can go wrong and the weight that brings to the whole process slows everything down to the point where things typically fail. It all seems like more effort than it’s worth.
3. Thinking that a Design System component will magically unify a product design.
People mistake Design Systems for design unification. You have to put in the work to unify the way you work and your designs, and then a Design System comes out of that. The piece people don’t think about enough is the work to consolidate and come up with a design pattern that works with their product(s). Building components without going through an audit and consolidation process will lead you to a Design System that doesn't fit the needs of your teams.
4. Making components that do everything
Flexibility of any one component comes at an increasing cost to maintainability for design system team developers and consuming product teams. If you use the components in a Headless CMS then usability for content creators becomes another issue. What is the right configuration? What is the permutation of every possible configuration? When should I use a parameter?
5. Not thinking about the Design System like a product
Treat your Design System like you would any other product. It has users that are trying to get work done. You either help them in that work, and they value it, or you don’t, and they abandon your product.
Would you rather have a product with 50 features that your users don’t use, which is hard to maintain, and retention is always an issue? Or a product with only a handful of features that all your users love, is solid and mostly bug-free, and is critical to getting their job done every day?
Successful Design System Recommendations
1. Focus on early adopters: Adoption is the critical piece—think about this rather than component coverage.
Firstly, a good place to start is by using design tokens to maintain the relationship and visual style, amongst other things. Then, you can build whatever you want from there.
Secondly, you always want to launch to a smaller audience first to get traction and adoption. Identify a specific team to work with first. A key question to consider is: What product will be ingesting the design system first? We recommend starting small because the level of complexity of supporting multiple teams is way underappreciated.
The team building the design system has to learn how to build and support other teams, not only build components. Support can look like facilitating meetings, maintaining open channels for communication, creating support documentation, setting up training, hosting Q&As, or asking for feedback.
2. Discovery jobs & pain points: An audit (of your digital properties) is essential to begin with.
Just creating components doesn’t create alignment and unification, and people make assumptions about the components they need.
Conducting an audit lets you think critically about all the use cases for component discrepancies. It highlights any divergent patterns — any inconsistencies that are necessary and those that are a result of a lack of context or alignment. It’s important to identify what your users’ problems actually are. This means auditing products and pages to figure out what you need and talking to product teams that will be using the design system to understand what problems they’re constantly facing.
3. MVP feature set: Do tokens first, then decide what is the next most high-value component to add to the design system.
We recommend starting really small. Build an end-to-end system that goes from design to code in the easiest way possible. Typically, this means beginning with design tokens — they’re a light lift with high impact. We noticed that most teams start with components, which becomes very complex.
Once you get started with design tokens, propagate them throughout the software. Then, you can look at what you’ve learned and uncover the next level of complexity you want to tackle. Next, identify the next high-level component that will add value, is feasible to develop and maintain, and will take the strain off of your product teams.
Conclusion
We hope you found these recommendations helpful. Remember, your design system is the one source of truth and maintains brand consistency across your entire organization. With that, the ownership of a design system should be distributed across your organization, and it should incentivize people to work together rather than apart.
Time after time, we see adoption as the most common hurdle teams face when trying to build a design system. Conduct an audit, focus on early adopters, and start with design tokens to build an MVP feature set – this will help improve organizational confidence in your design system.
If you want to learn more or need help assessing your design system product-market fit, reach out to us for a conversation. We’re happy to support you in an advisory or delivery capacity.
