Design Systems Create Bad Designers
If design systems take over, what work is left for the designer?
I’ve been both enamored and troubled watching the Design System evolve over the past several years. I first became interested in pattern libraries in 2007 as a young designer working on Windows software, then again as I was tasked with aligning multiple web products into one consistent experience in 2013.
I’ve since moved away from in-house design and have witnessed this evolution from pattern libraries to design systems from the outside. The trend has been largely driven by improvements in design tools, UI dev frameworks, and frankly massive design teams who charitably publicize their work to help inspire and educate burgeoning young designers.
But for all the positive gains this movement has yielded, I worry about what it’s doing to the craft of design. Are the goals these systems aspire to actually good for the field? And who is even pushing for these advancements? And finally, if these systems succeed at their goals, what work is left for the designer?
In this article I provide a counter opinion to these massive trends in design systems. My goal is not to simply be contrarian, but to inspire designers to think more deeply about the ramifications of these seemingly innocuous systems. I’m certainly not exactly right in each proposal that follows, but at the very least, I hope to provide some food for thought.
Design systems are driven by efficiency, which is not a goal in design
It’s true that being more efficient is desirable. But the experimentation that goes along with design is not driven by this goal. In fact, design systems should instead focus on how to give designers more ability and power to experiment.
But let me be clear: Design experimentation isn’t about A/B testing, it’s about finding solutions.
Designers mustn’t forget the power of finding solutions through making. By pushing pixels, we get to understand the problem from a different angle. Sometimes we literally need to see what something looks like before we cross it off our list, and often, better solutions emerge as serendipitous accidents while “playing” with pixels.
Our ability to make good design decisions hasn’t kept pace with our ability to build designs faster
In what I suspect will be one of many controversial perspectives in this article, I’d like to posit that it’s a myth that designers make better design decisions when they spend less time designing screens.
I hear this constantly: “Design systems free up designers to think about the decisions that really matter.”
For one, this ignores the many other roles that bear responsibility for good design decisions: product managers, marketers, developers, etc. And honestly, this type of thinking often feels like a surrender of responsibility for getting your hands a little dirty. Often, designers who don’t get “dirty” with design tools are simply afraid to make their mark.
More importantly, this perspective is based on the speed of actually building designs — which has improved exponentially with the development of design tools — not on ways to make our decision-making faster.
Instead, I believe that when people say “design systems save people time,” they actually mean they save people effort in thinking things through. As you’ll see later, the guidelines that systems enforce serve to help designers offload these decisions: “I don’t need to think about whether the button goes here because the guidelines dictate it,” or “I feel like a different color is appropriate for this section to help it stand out, but since it’s not in the system, I won’t worry about it.”
These are just examples, of course, but they’re reasonable and realistic results of successful systems. Time might be saved now that you don’t have to do the grunt work, but what if the grunt work of doing design helps you make better design decisions?
The designer–developer handoff isn’t the most important handoff in product
Okay, now this will probably raise some hackles.
Let’s start by understanding why this handoff gets all the focus. Dev and design spend more time together than any other disciplines. And it’s a relationship wrought with inefficiencies.
So naturally, it makes sense to streamline this process by standardizing controls and making them into coded components whenever possible. Designers championed this with pattern libraries because it increased the chance that their work would be built closer to spec, and it reduced their overhead in mocking up the same thing over and over again.
But since design systems have taken over, engineering has taken control of this handoff. Systems are both design and code… both of which can dramatically hinder design potential.
But that’s not the real problem. The real problem with these approaches is that they presume there is any product at all going to market, and moreover, a product that exists in the market long enough to even warrant entire teams whose sole purpose is streamlining production.
As a result, we see monolithic, corporate design teams at the forefront of today’s design systems movement.
Ironically, we have most designers complaining and begging for a seat at the table to influence product direction.
Guess what? The key is shifting your focus away from engineering handoffs and toward marketing and sales.
Put another way, what good is it to establish an efficient design system if you’re not helping sales in demos or helping marketing create demand?
What you often end up with is a well-designed and well-built piece of art, yet another portfolio piece to store away for when you have to search for another job (because you wasted so much effort on helping engineering that you forgot to help the product get sold).
Designers, if you want to get a seat at the table, then stand up and walk away from the one you’re at and start figuring out how you can optimize the design–sales or design–marketing handoffs.
Design becomes less about craftsmanship and more about policy design and lobbying
With a successful design system, changes to the system will be more difficult. Doubly so if the system is also backed by code.
As a result, the designer is left to design in ever-smaller boxes, and the more intertwined the system is with other functional groups (namely, engineering), the more people are needed to approve such changes. Over time you can start to imagine how these systems might dissuade designers from even trying something new, knowing the stamina or time needed to see them through.
However, guidelines (aka “policies”) are useful… just more in the way of design patterns than systems.
Guidelines are how we end up with Frank Lloyd Wright buildings; design systems are how we ended up with awful suburban tract housing — a set of principles taken to an extreme, driven by shortening the design–build handoff.
(To be fair, Frank Lloyd Wright homes are famously hard to maintain, so take this comparison with a grain of salt.)
Instead, design mustn’t lose its focus on craftsmanship. Don’t let efficiency dominate. Collectively, our field relished breaking free from the tyranny of Windows and MacOS and ran toward the freedom of the web. But we need to maintain our freedom in this new environment.
Too many systems are simply becoming new versions of Windows, replete with creativity-hampering restrictions and guidelines that become more important than the very product itself.
Design relies on rule-breaking, but systems have more rules and enforce them more strongly than ever before.
Design systems subjugate designer responsibility and judgment
What I truly worry about with the design system movement is that they serve as absolution from designer responsibilities — submitting individual judgment to a central authority.
Systems may come to represent a dramatic flattening of decisions, driving the very same blandness we all revolted against in native desktop-land. Designers are trained and expected to make good decisions based on judgment, honed through constant learning and practice.
Systems take this away.
They often presume a “right way,” or more fairly, a “best way.”
But there is no such thing as best or right, and even if there were, it’s a moving target. To bake this judgment into a system manifested through groupthink is submitting the individual designer’s expertise to an outside force. Ultimately, we gain consistent button placement and colors, but we lose the delightful variability that emerges from opinionated experts. Design systems are restaurant chains, but expert designers are chefs. I imagine world-renowned chef René Redzepi doesn’t ever want to work at Applebee’s, and the world is probably much better off that way.
Are these goals really worth it?
For all the efficiencies that systems have to offer, we must ask ourselves what we are truly gaining. And in this process we need to critically examine whether the problems we are solving are truly problems at all.
Speed, efficiency, consistency, seamless handoff — these are bureaucratic ideals, not designerly ones.
Naturally, we ought to strive for some measure of each of those qualities in our work, but they’re not the ultimate goal of design work, just as losing weight isn’t the ultimate goal of getting healthy. Both are merely byproducts of larger goals.
What’s worse, I believe designers who scoff at the “trivial tasks” that systems automate are missing out on the inherent rewards of a job well done. Sure, the work can be tedious, but designers will derive meaning for their careers and their lives through this tedium. Completed projects can be celebrated as the culmination of this work.
If design systems cut the tedium, then where will we find our flow?
Again, designers will argue that this frees us up to do the more important strategic work. But have you ever filled an entire day working through thorny details or wicked problems? I have. And it’s absolutely exhausting.
Worse, my abilities to work through problems strategically diminishes by the hour, and during particularly “strategic” weeks, I’ll be seeing diminished returns by Wednesday.
Designers need tedium to counterbalance these difficult problem-solving activities. The “details” aren’t just something to be dismissed. I used to criticize lead designers who palmed off their work to “wireframe monkeys.”
Today, design systems suffer that fate.
Design systems create bad designers
I’ve saved the most inflammatory for last 🙃, but I can easily see a future whereby design systems create legions of bad designers.
I believe that microwaves have helped the average person make a decent meal without teaching them to cook; design systems can do the same for untrained designers. But for those who take seriously the profession of design and desire to become a master craftsperson, design systems are your kryptonite.
For all the extra time systems should be creating for designers to “do the important stuff,” we will find products in disrepair (much like the awful vinyl-siding tract homes littering the USA), unforeseen technical issues with no expert to advise on workarounds, and a general dumbing down of the industry.
If the design system has the best practices baked in, then what’s the point of learning the principles yourself?
I’ll end by saying I do actually believe there is value in design systems.
I use them myself to some degree. They succeed at many of the things they are intended for. And when used properly, they can greatly simplify your work and align your design team. Instead, consider this a warning against letting them completely consume your career.
I’ve had too many conversations with young designers who want to work on design systems first. And senior designers wanting to create them as their first project at new jobs.
Don’t lose sight of the craft.
You cannot hold design in high regard while relegating so much of it to a centrally controlled system. Mastery comes from practice, and practice comes from choosing to put in the time.