"Why should I give a f**k about design systems?"
Discover more from Better by Design
"Why should I give a f**k about design systems?"
Directly answering the question your stakeholders will think but not ask
Intro
Hey friends 👋 Welcome back!
If you’re like me and design digital products for a living, I bet you already understand the benefits that good design systems can have on your work. But, I also bet you’ve encountered the challenge of communicating those benefits to the broader organization to get the support you need to make a system happen.
I recently found an article from Jeremy Brett in the UX Collective on Medium that I liked for being tongue-in-cheek while delivering a clear message:
Outside of design and front-end dev, the reality is that most disciplines in tech companies don’t give many f**ks about whether there’s a design system. They care about the outcomes that a system can facilitate, but they don’t care about the system itself.
So how do we rally the most influential design system stakeholders to our cause? What do they get in return if we get to make our precious system? Why should they give more f**ks?
Why design should give a f**k
Let's start with the obvious: if you can’t get the rest of the design team to care about your systems effort, it's dead on arrival.
The main concern I've experienced with other designers is a perception that adopting a system will be too restrictive on their creative process. They fear it will inhibit their ability to solve specific customer problems. It’s a fair concern, but my response is that good systems are designed to facilitate better design, full-stop.
Systems do intentionally place some restrictions, but the good kind, like guardrails. Designers know how important setting constraints is for getting good creative output. They help us focus our efforts so that we’re solving the most important problems for the situation at hand. 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. You also 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, then go 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
Why engineering should give a f**k
Most engineering teams have an easy time seeing the value of scalable back-end systems. The reasons are clear: 1) if the back end fails, you cease to have a product and 2) if the back end isn’t efficient it can crush you in a variety of obvious costs (hello AWS bill 😅). Software businesses fundamentally cannot proceed if the back end isn’t given the appropriate care.
When front-end systems start to fail it’s less obvious. Sure, they could just straight up crash which is bad. But the more insidious failure is when the front end visually appears fine but the reality of the code makes it hard to maintain and slow to deliver value. Nathan Curtis has a great article called “The million dollar button” in which he breaks down the true cost of ignoring your UI systems. Managing 12 button variants? Not that big of a deal. Managing 120? Orders of magnitude harder, more error prone and more expensive.
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 in large projects can waste hours of developer productivity playing "whack-a-mole" with UI bugs. This sucks for the developer, delivers a worse immediate customer experience and slows the team's ability to ship useful, new features that would add more value.
In short, UI code benefits from DRY principles just as much as any other part of the application. For engineers, "design systems" is a practice that helps deliver a DRY and robust UI that's a joy to develop and feels good to use.
Engineers get:
UI that's DRY! (kill off that redundant code 😎)
Less time wasted hunting specific, one-off UI bugs
Quality new UI with less effort
Why product should give a f**k
The product team doesn't benefit as directly from design systems as design or engineering, but what they do get highlights the core value that systems facilitate for the business.
Design systems are a very high leverage investment. They require a relatively bigger up-front cost to establish them, but once an application has reached a critical mass of system adoption, the effect of the system 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 a lot of runway to design and develop can be prototyped with system elements to achieve a real-world 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 the customers you already have, a design system helps ensure consistent and dependable experiences. That means internal consistency within your own product (or products) as well as consistency to external standards that users are accustomed to from the other software in their day-to-day lives. Failing to be consistent can increase the cognitive load required to use your application and also cause the customer to anchor onto moments of inconsistency, resulting in the perception of a worse user experience even if it objectively works as designed.
PMs get:
Higher leverage and lower expenses
Better time-to-value and time-to-market
More consistent and dependable customer experiences
Outro
The process of getting design systems stakeholders to give a f**k about your system isn't so different from getting potential customers to give a f**k about your product: you have to put on your empathy hat, think about what those other people want, and then work to deliver something that meets them where they're at.
A good system is ultimately a win for everyone involved, its benefits just need to be communicated in terms that make sense for each of the different roles that will be impacted by it (either directly or indirectly).
Similar posts
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 😎☕️.
"Why should I give a f**k about design systems?"
Another fun read! Reminds me of all the conversations over the years I've had with management and product about the "ROI" of investing in a design system.
One thing I'd add to your "Why engineering should care" section is that a design system should really be considered a part of a company's "UI platform". Engineering leadership often has more backend experience than frontend, so they will be very comfortable with investing in backend platforms, yet unsure of what equivalent investments look like on the frontend. They may even have had negative past experiences with past frontend investments, such as migrating between libraries, that make them inherently skeptical of other supposed investments like design systems. Tailoring one's description of a design system's benefits to the background of engineering leadership can help get their buy in.
Another fun read! Reminds me of all the conversations over the years I've had with management and product about the "ROI" of investing in a design system.
One thing I'd add to your "Why engineering should care" section is that a design system should really be considered a part of a company's "UI platform". Engineering leadership often has more backend experience than frontend, so they will be very comfortable with investing in backend platforms, yet unsure of what equivalent investments look like on the frontend. They may even have had negative past experiences with past frontend investments, such as migrating between libraries, that make them inherently skeptical of other supposed investments like design systems. Tailoring one's description of a design system's benefits to the background of engineering leadership can help get their buy in.