Design systems are powerful, but not perfect. Sparkbox experts share some hard truth about what’s involved in building and operating a successful system.
Design systems promise consistency, efficiency, and collaboration, but they can also come with some surprising challenges. At Sparkbox, we’ve spent over a decade helping clients move toward more systematic ways of working, and along the way, we’ve seen a few things and learned plenty of lessons. Here, we’ve gathered insights from our team to explore these uncomfortable truths, sharing honest experiences and practical advice.
Mandy: It can’t solve all of your accessibility problems
A design system is not a magic spell. You can’t cast it on a product and expect that product to be perfect. One example is the common misconception that building with an accessible design system will automatically result in an accessible product. Sadly, this isn’t the reality. I remember watching a live demo where a professional screen reader tester struggled to complete a purchase on an e-commerce platform, despite it being constructed with an “accessible” design system. While such a system can help tackle typical accessibility issues like color contrast or ensuring proper keyboard functionality for individual components, it’s ultimately the experience built with that system that must be accessible to effectively serve the needs of disabled users.
So what is reasonable to expect from a design system? Accessible design systems streamline the design and development processes by providing pre-built, accessible components. This reduces the mental load of constantly rethinking basic accessibility considerations, freeing teams to concentrate on the accessibility of their product as a whole. A good, accessible design system should provide guidance for creating new accessible components and composing existing components into truly accessible user experiences.
Kasey: Not everything will fit neatly into the design system
Some things are easy to work into a design system. Components like buttons and cards, along with foundation systems for colors and typography, are staples in pretty much every design system I’ve seen. Eventually, though, you’ll run into something that just doesn’t quite fit. There’s always that one component that’s used once, for a very specific use case, leaving you wondering whether or not it should be included in the system.
My advice in these situations? Leave it out. The cool thing about design systems is that they’re iterative, so you can always add one-off components later if they become necessary. There’s no need to force something into the system prematurely—let it evolve as needed.
Catherine: People might not want to use it
One of the most gut-wrenching aspects of building design systems is accepting the fact that people may not want to use it. Design system champions, at least successful ones, are typically good sales people. They get folks jazzed up for what they can build together, painting a beautiful picture of what could be. But implementing and integrating a system is hard work.
Creating the thing that fits perfectly in both “what people like to use” and “what people need to solve problems” is tricky, but if you achieve it, some people won’t know that solution you’ve created exists. You write amazing documentation and release notes, and some people won’t read them. You compose flexible components with numerous variations and some people still build their own thing instead. You get leadership to step in and require the design system be used, and some people won’t use it simply because they don’t like to be told what to do.
Instead of spending so much energy attempting to get every single team member on board with using your design system, refocus that energy toward improving the experience for the people actually using the system. Identify your design system super fans and turn them into advocates on their own teams. Keeping subscribers that want to use your system engaged will keep you moving forward toward productive goals, and will maybe even grab the attention of some of those hold outs.
Ben: The team that needs it most might not have the skill to use it
We tend to skip over the fact that using modes and themes, using complex components with many properties and variants, and configuring and composing all of that stuff is a skill that not every individual has. Not only are we asking consuming teams to work differently, we’re asking them to learn new skills so that they can work differently. The really ironic thing here is that the teams that likely need the system most are also the ones that probably don’t have the necessary skills needed to use a design system effectively.
That means it’s not enough to build out robust, flexible design systems. It’s not even enough to write beautiful documentation explaining why, when, and how to adopt. We also need to provide training and education on how to properly use the assets we offer. And, we have to find ways to do this that don’t come across as condescending or gatekeeping. The posture we take with the teams that need us most says a lot about who we are and why we’re building a design system to begin with.
To address this, we have to remember that we have just as much to learn from those teams that need a system most as we do to teach them. Our job is to engage with them—that’s a two-way street where we can understand the challenges in their workflows and devise systems that help address those challenges. This engagement is the door to building trust and the key to a healthy design system team posture, one that will allow our systems to thrive.
Melissa: It won’t be perfect
Your design system is never going to be perfect. But that’s ok! In the words of former Sparkboxer Noelle Lansford, the goal of a design system is to be used, not to be looked at. A design system is only valuable if your consuming team uses it. And how do we encourage teams to use our system? We build components that help consumers work faster and more efficiently, and we document how to implement those components to enable consumers to integrate them. If we allow ourselves to get caught up in making the perfect system, we lose sight of the end goal. I invite design system teams to let go of the idea that there is a perfect version of your design system, and instead adopt a mindset of iteration and an acceptance that to meet evolving team needs, a design system must also evolve.
When you let go of an attachment to perfection, you may notice a greater willingness for consumers to contribute back to the design system. Imagine being a contributor yourself. Are you more likely to give back to the system if you know that the expectation is perfection, or if the expectation is to get the component as close to done as you can, after which a design system team member can pick it up and get it the rest of the way there for you? You may also notice a renewed excitement for building UI. A perfectionist mindset and standard often creates stress and fear of failure that can make us forget how fulfilling the creation of impactful deliverables can be. And besides, what’s a bigger failure? Having a perfect design system no one uses, or having an evolving design system that’s useful for consumers?
Leah: Too Many Options Can Lead To A Poor Experience
Design system tools are constantly evolving, offering more customizable options to better serve users. However, without proper checks and balances, these customizations can quickly turn a system into something unusable. We’ve seen many companies invest in multiple design systems, only for them to go unused by product teams. This often isn’t due to a lack of effort or support but rather issues with usability or implementation, which ultimately hinder adoption.
Building a usable design system isn’t a one-size-fits-all process. Instead, we need to establish checkpoints for process, communication, and testing to ensure we’re creating a functional and user-friendly experience. These touchpoints help teams refine their approach to customization, making the system more valuable to end users, building trust, and fostering greater adoption.
Merani: Cool Features Don’t Always Lead to Great UX
As designers, we’re often thrilled by new Figma features that help us set up design systems in ways we feel are efficient. Maybe you’ve found a clever solution that feels intuitive and is easy to set up! In my experience, many designers love sharing these kinds of “hacks,” but it’s essential to step back and keep UX front and center. While these setups can be exciting—Figma features are undeniably cool!—we need to ask whether they truly make sense from a user perspective.
Consider a scenario where a designer is creating a button component with customizable icons. They might decide to group icon options within a dropdown labeled “configuration.” This approach could make sense from a setup perspective, but if I think as a user, I might not realize that icon options are hidden within this dropdown—a potential UX misstep.
A better approach might be using Figma’s boolean properties to indicate when icons are available. This way, when icons are enabled, users can receive recommended instance swaps without having to hunt for icon replacements. Here, even though both options are technically possible, the second choice clearly offers a stronger user experience and should be preferred.
