How to Make the Case for Design Systems
How to Make the Case for Design Systems
Building support for design systems by framing their benefits for reluctant designers, engineers, and PMs
Hello! I’m Pat and Better by Design is my newsletter devoted to creating great design, quality business, and a prosperous creative life. If you’re new here, join 2500+ creative technologists as we uncover new insights each week.
After a decade of designing and building software platforms, the benefits of design systems are second nature to me. However, I often find myself needing to rehash those benefits to rally new teammates and organizations to the cause.
The featured image from Jeremy Brett does a great job of framing the reality that system designers have to negotiate:
Most disciplines in tech companies don’t care whether there’s a design system; they care about the outcomes that a system can facilitate.
In my experience, even design, engineering, and product management have their own hang-ups with design systems, so today I want to address how you might bring those influential groups to your side to bolster support for your next design system effort.
Let’s dig in.
The case for designers
News flash: many designers are reluctant about design systems.
While it might sound obvious, your first order of business in establishing a system is to get the rest of the design team to care. Otherwise, you're dead on arrival.
The main concern I've experienced with designers is a perception that adopting a system will be too restrictive to their creative process and that it will inhibit their ability to solve specific customer problems. It’s a fair concern, but my response is that a good system is designed to facilitate better design, full stop.
Systems intentionally place restrictions, but the good kind, like guardrails. Designers know how important setting constraints is for the creative process; projects without them often feel paralyzing! A good system acts like a useful starter kit of technical constraints and helps us make sure we’re delivering something meaningful for the user without getting lost in the weeds.
You shouldn't have to reinvent the wheel for every pattern you need to achieve a good, new customer outcome. And you shouldn't have to red-line spec the same component over and over again for development to achieve a consistent execution.
A good system lets you design a pattern once in detail, and then apply it to solve many customer problems. It's also flexible enough to evolve when you encounter a scenario that requires something new!
Designers get:
A flexible tool that facilitates their focus on solving user problems
A useful set of constraints when starting new, nebulous work
Freedom from designing the same things over and over again
Higher likelihood of consistent execution of their designs
The case for engineers
Most software engineering teams have an easy time seeing the value of scalable back-end systems. The reasons are clear:
If the back end fails, you cease to have a product
If the back end is inefficient it crushes you with obvious costs (hello AWS bill).
When it comes to front-end scalability, teams are often more ambivalent since the consequences of inefficiency are less drastic.
However, the impact of a weak front-end system is insidious. Platforms often appear okay visually but the reality of the code makes them hard to maintain and slow to deliver value.
Your HTML and CSS footprint may not make as much of a direct performance impact as other parts of your code, but its complexity at scale can waste expensive hours of developer productivity playing "whack-a-mole" with UI bugs.
This sucks for the developer, delivers a worse customer experience, and slows the team's ability to ship features that would add more value.
Managing 10 discrete button instances? Not that big of a deal.
Managing 100? Orders of magnitude more challenging, error-prone, and expensive.
Engineers get:
UI that's DRY! (kill off that redundant code)
Less time wasted on specific, one-off UI bugs
More time building meaningful features
Quality new UI with less effort
The case for product managers
The product management team doesn't benefit as directly from design systems as design or engineering, but what it does get highlights the core value that systems return for the business.
Design systems are a high-leverage investment.
They require a bigger up-front cost to establish, but achieving a critical mass of system adoption amplifies the returns of future UI investment significantly. The cost of experimentation, the time to deliver value for customers, and the time to bring a new idea to market all decrease with a good design system.
New features that otherwise would have taken significant runway to design and develop can be prototyped with system elements to achieve a first iteration that adds value for the business much more quickly. Whether that's just the value of learning or dollar value to your bottom line depends on the circumstance, but either way, it's value that otherwise would be harder and more expensive to attain.
Finally, for your current customers, a design system helps ensure consistent and dependable experiences. That means internal consistency within your own product(s) as well as consistency with external standards that customers already know and expect. Unintentional inconsistency increases the cognitive load of using your application and results in the perception of a worse user experience even if it works as designed.
PMs get:
Higher leverage UI and lower cost builds
Better time-to-value and time-to-market
More consistent and dependable customer experiences
Final thoughts
The process of getting design system stakeholders to care about system efforts isn't so different from getting potential customers to care about your product: you have to put on your empathy hat, consider what those people really want, and then work to deliver something that meets their needs.
A strong system is ultimately a win for everyone, but to build the support you need to execute, you have to communicate the benefits in terms that make sense for each of the roles that will be impacted by it (either directly or indirectly).
Bring that added specificity to your pitch and I’m confident you’ll see good results.
Until next time,
Pat 💚
PS. I drafted sections of today’s post on X/Twitter earlier this week and plan to do the same with more ideas going forward. If you want to see all of those ideas, I suggest following me there as well: Follow Pat on X/Twitter.
If you got a little value in this post, consider subscribing, sharing, or following me on Twitter. If you got a lot of value I’d appreciate it if you bought me a coffee 😎☕️.
