6 Ways Your New Design System WILL Fail
1. Treating it as a Widget Library
Grab or generate a component, save time. It’s a promise that has been repeated over and over since the 1980s. This promise has usually failed, and anyone who has been building enterprise systems for any length of time has experienced the frustration of ripping out the third-party components that have become a tortured mess.
But this isn’t what a design system is.
There aren’t many prior mental models for design systems, leaving a sense of “it’s a widget library like in Visual Basic, Power Builder, or off-the-shelf component libraries for the web.”
An atomic design system is and is not a component library. It’s a shared language that unifies design and technology, allowing for the removal of 50% of the waste from software development due to organizational delays and collaboration costs.
It’s also atomic. While a design system provides 30 to 50 components, 100% of your system is built on the design system. The token layer itself provides consistency for colour, typography, and other fundamental design elements.
Building a component not in the design system? Its atomic elements are there—colours, typography, paragraphs, layouts, fonts, etc.
With this, new components not in the design system are rapidly composed on the design system. Composition as a practice is inherent in the environment for both design and development.
2. Overbuilding or Underbuilding
This is just the reality of software. Architecture is the core of what is needed—no more, no less. Overbuilding creates something hard to adapt and introduces technical debt as it’s twisted into use (third-party component libraries almost all qualify as over-built compared to your needs).
Underbuilding doesn’t create enough value—designers can’t design meaningfully, and developers don’t really benefit from adoption.
3. Building the Design System You Want, Not the One You Need
This creates a design system death spiral because this design system is unadoptable.
The design system you want is the expression of your brand perfectly realized, with magic widgets that allow products to be assembled, not coded.
The design system you need allows design to be consistent, developers to build rapidly, and systems to be continuously extended and evolved.
Depending on your organization, it also needs to be adoptable into existing codebases without costly rewrites that don’t allow enough business value to be created. It also needs to be learned by developers, designers, and customers and evolved with your product(s) and market.
4. Not Considering the Experience Curve
This extends 1, 2, 3, which are ultimately all experience-based. The release of your 1.0 version of the design system NEVER matches the starting design system experience of your designers and product teams. It is also not your ideal system because that emerges from use and collaboration across multiple products.
The solution? Continue your design system effort until traction is reached across sufficient teams to allow a) effective use of the design system, b) effective extensions of the design system, and c) effective contributions back to the design system (either updated components via a monorepo or components contributed back to the design system team). This means building components that solve specific needs for adopting teams (improving developer experience and team ROI) as well as supporting those teams with coaching and support so they can adopt the design system.
When is your design system done? When adopted and multiple teams have traction with it (positive developer experience and team ROI).
5. Not Planning for High-Value Platform Migration Scenarios (Long-term vs. Short-term Incentives)
Some products will create massive value by the adoption of the design system… in 18 months.
The platform outcomes are usually: consistent user experience across multiple products, single authentication and authorization models, and the ability to sell new modules and increase the share of wallet.
However, the resulting organizational pressures will compromise developer experience and near-term ROI from new features delivered into the market. Traditional project management incentives and goals of on-time, on-budget don’t include the higher value longer-term outcomes of the design system.
To avoid this, create the measures of value and north star that makes the product become part of a platform an essential mission, with moving to positive developer experience and near-term team ROI in less than 3 months. Immersive coaching on the design system (dojo model) and a migration strategy that is clear make the developer experience better (learning and working on better tooling) and equivalent feature flow.
6. Not Embracing System-Level Considerations
Excellent design can create terrible customer experiences. Why? Because the design is to a single interaction, while the consistency of the experience makes your application more discoverable for users, and more evolvable due to common units of experience (e.g., onboarding, tablet support, etc.).
Constraints on design and developers enforced by the design system ensure effective workflow and culture transformation to being customer and value-creation obsessed. Without that customer-experience north star, personal opinion, and over-designed and over-engineered solutions start to degrade value creation.
Four Reasons You Need a Design System
Design systems are transformative, and it takes a lot of energy to create the alignment, trust, and organizational commitment to succeed. Software is hard, architecture is hard, design is hard. So to not have readers flee design systems after reading the above, I wanted to emphasize the NEED in 4 simple points.
1. 50% Design and Development Savings
While this may seem like hype, when you consider customer experience consistency as valuable, and the ability to make a decision and move on via the design system, all kinds of blockers and impediments are removed from teams (in addition to the speed of design and development improvements from reusing components).
Faster development also allows for aligning on shipping smaller slices of experience since the UX is the primary goal—the UI and visual design patterns are captured in the design system. Less conversation, more productive development.
2. Faster Features Allow for Customer-Centric Workflows
Smaller slices are easier to reason about.
Smaller slices get faster feedback.
Smaller slices allow for learning to be a success, not a failure.
Teams are happy to spend months talking about something, mistaking that for progress. A design system can allow new features to be designed, built, shipped, and tested by customers in 3-5 days. Feature flags can allow this for a limited set of customers before rolling out more broadly.
This capability enables companies to move from risk-averse due to the cost of deployments to customer-obsessed digital-first organizations. Once this capability is there, teams start to feel risk when they don’t ship. Why? Because the feedback channels mean they become accountable for learning and validation—something that always belongs to someone else in longer feature delivery cycles.
3. Evolvable Platform Outcomes
All successful products effectively become platforms. Yet design, experience, and technical debt create a barrier to realizing this. Acquisitions never get integrated. Rewrites are in continual planning.
Moving all products to a design system means all new development is on a common platform. New platform features (e.g., common authentication, authorization) enable other products to start to align their roadmaps to join the platform. The process can be accelerated by using a monorepo where the software and its test suites ensure appropriate consideration of changes without the collaboration overhead of endless meetings and negotiations. Smaller feature changes allow for conversation after the change where necessary.
Competitive advantage comes from better software. Design systems enable the platforms and migration to platforms that facilitate that.
4. AI Enablement
Codebases that can be reasoned about easily are vastly easier to extend. Studies have shown that fixing a bug takes 21 times more effort 6 months after it was written than fixing it immediately—by the same developer! The reason? Understanding the code.
What applies to human intelligence also applies to artificial intelligence. Quality platform codebases with a consistent experience layer will be vastly easier to extend with the coming AI assistants over the next 6-36 months. The net of this? Your design system is a key part of your AI strategy.
