Which Problems Design Systems Solve (and Which They Can’t)

Design systems can solve problems for both designers and developers, but let’s take a realistic look at what design systems can do for us and what they can’t.

Over the last several years, design systems have enjoyed their time in the sun—there’s been a lot of attention and hype around them, and for good reasons! They can solve a myriad of problems for both designers and developers. They’re not magic wands, though; they can’t fix everything and it won’t happen automatically. Let’s take a look at what design systems can do for us … and be realistic about what they can’t.

Design Systems Are Great Shared Documentation

One of the main selling points of a design system is being able to collect and document all the disparate parts of a user interface. It’s not just about listing the brand colors—it’s also for describing when to use each one, what they represent, how they should (and shouldn’t) be combined, and so much more. Multiply that across every UI element in your application, and all of a sudden, you’re looking at a seriously hefty piece of documentation.

This is especially helpful for sharing resources across teams. For example, many developers use a component library, though designers don’t always have access to it. If components are added to the design system, developers can document where and how they get used, what features they include, what can (and can’t) be customized, and so much more! This reduces the back-and-forth that can happen during the handoff process, because everyone was aligned on the capabilities and limitations early in the process.

… But They’re Not a Single Source of Truth

However, despite being shared across teams, it’s unlikely that the entire design system will be located in a single shared place. By nature, different parts of the design system will need to live in different places—for example, design tokens and logos might live in Figma, while components and templates might live in a codebase, and tone-of-voice and language guidelines might live in a text file or PDF.

While there are places where we can expose that information to collaborate (like Progress ThemeBuilder), in reality a design system is—in and of itself—a collaborative effort that requires specialist work from different teams. Anytime we need specialists, we also need specialist tools. We can share the output from those tools (like loading components into a Storybook instance or exporting logos as PNG files), but we’ll always need to manage and maintain the core elements in their respective original “homes.”

Design Systems Speed Up Design and Development

I’ve seen design systems described like building blocks before—small pieces that can be easily combined in a multitude of ways to create cohesive and visually interesting interfaces. Because all those pieces have been designed to go together, it removes a lot of the friction from both the design and development processes, allowing us to move from idea to product a lot faster!

… But They Don’t Mean We Can Skip Testing

However, sometimes I see people make the mistake of assuming that because they’re pulling from a curated, vetted library, they no longer need to worry about testing. After all, each component has been unit tested in isolation, so we don’t need to worry about QA, right? Each page was designed from our collection of approved resources, so no need for usability testing, right? Unfortunately … wrong.

Just because each element works individually doesn’t mean they’ll all work as intended when brought together into a final product. Design systems don’t remove the need for usability testing, accessibility testing or quality control. The good news: with all the time you saved during the build phase, you have plenty of time to test thoroughly and still hit deadlines.

Design Systems Empower Developers to Make Small Design Decisions

One of the (perhaps most useful) perks of a design system is that it enables non-designers to make informed design decisions. Especially as products and teams grow larger, it’s not realistic for developers to ask designers for guidance on every minute decision—designers have bigger fish to fry than choosing button colors! Often, developers are asked to “just” add something to the page real quick—a form, an announcement bar, a confirmation dialog, etc. Rather than having to begin the design process from scratch, they can grab UI elements from the design system and know that they’ll look professional, polished and visually cohesive.

… But They Can’t Replace the Work of a Skilled Designer

However, as the scope of the work grows, those quick-fix, pre-made elements may not be enough. That’s where designers come in. Design systems are meant to grow and expand with their products. They’re guidelines, not hard-and-fast rules that can never be broken. A skilled designer will know when new elements need to be added, old elements need to be revised or new solutions created entirely.

A design system can’t think about the user flow of an application. It can’t listen to user feedback and adjust layouts. It can’t balance UI elements on a page, understand user priorities or rework existing systems to incorporate new features. For all that—and so, so much more—there’s just no replacement for a designer.

Design Systems Save Time, Overall

One of the main reasons that teams create design systems is for the time they can save—we even mentioned it earlier in this very article, when talking about how design systems speed up design and development! That gives us time back to work on all sorts of other things, from innovation to bug testing and beyond. They enable us to create faster, iterate faster, ship faster—but to get there, we have to be willing to put in a little time, as well.

… But They Still Require Time for Creation and Upkeep

Design systems don’t come out of nowhere. The creation process requires an upfront investment of time and effort that is (speaking frankly) fairly significant. After all, you’re basically building a foundation that you want to set your application on top of—why would you skimp on that? For a design system to be adopted by the various teams and actually used, it needs to be thoughtfully created—not just thrown together quickly.

It also needs to be maintained. The maintenance process isn’t as time-consuming as the initial creation process, but it isn’t nothing either. A design system that isn’t kept up will eventually be set aside. It becomes a burden, rather than a help. Think of it like owning a car. It will help you get from point A to point B a lot faster than walking, but if you want to get the most out of it, you need to keep up with regular oil changes, inspections, tire replacements, etc. Without those regular check-ins, it will become a pain point instead of a help. Design systems are the same way.

Do You Have a Design System?

Thinking of starting one? Already working on it? Check out the Progress Design System Kit to see our collection of resources that can reduce some of that time investment for creation and maintenance. Start from the basis of our beautiful, accessible Kendo UI components and build your full design system on top!