Design Systems Pitfalls
The path to successful design systems is perilous indeed. Poisonous snakes, speedy scorpions, and lurking alligators are all lying in wait while the systems team attempts to rope swing over all of them to reach the golden promised land sometimes referred to as Design Systems Utopia.
Dan Mall recently mentioned that teams he works with are frequently on their 3rd or 4th attempt at design systems, because prior efforts ended up as Design Systems Graveyards. In this post, I’ll share some of the biggest pitfalls I’ve witnessed, in hopes that you may be savvy enough to avoid them in your future design systems efforts, dear adventurous reader.
Grab that vine and hold on for dear life!
1. Don’t Take On Too Much
This is probably the most common pitfall I see design systems teams encountering. The more you learn about design systems, the more it can feel a bit like staring at the sun. Non-design systems folks tend to focus on, you guessed it, components. There are a multitude of initiatives a design systems team may need to consider: documentation, contributions, adoption, metrics, team workflows, communication, advocacy, shepherding, and the ugliest serpent of them all: cultural challenges.
In addition to the multitude of initiatives design systems teams may opt to take on, there’s the tendency to say yes to anything product squads may be requesting. Take the necessary steps to feel comfortable saying “no” to requests from product folks (“very cool suggestion, we can’t accommodate now given team size/other reason, but we will add to our backlog and revisit”). Establishing your team’s feature workflow may be a crucial first step.
Taking on too much not only makes the systems team’s day to day difficult, it’s helpful to recognize that anything produced by the systems team must be maintained indefinitely. Taking on too much leads to projects that die on the vine.
If you’re a smaller team just getting started, potential initiatives or requests can be distractions and lead to burnout. It’s important to assess your team’s capacity, and identify the things you won’t do, in addition to the things you will do. Formally, this is known as planning and prioritization, which doesn’t have to be as nasty as it sounds.
You can avoid this pitfall by putting in minimal effort to make planning fun, and making the output of your planning public so you can point people to it when they inevitably come to the design systems team with requests.
Left unchecked, the result of a design systems team taking on too much is burnout, and that’s simultaneously not fun for anyone on the systems team, nor helpful to the product adopters, which is essentially like being bitten on the foot by a gator before you take a single step.
2. Don’t Hyper Focus on Components
Another fairly common pitfall is focusing too much on the output of the design systems team, which typically comes in the form of a Figma library, and a code repository, both containing the components that designers or engineers would use, respectively.
Empathy is important here. It’s natural for product folks to have an understanding of design systems that is just “a set of reusable components”. Part of our jobs as systems practitioners is to help product folks understand the design system ecosystem is a bit larger, and that the systems team has worked to balance handling designing and building components with their myriad other responsibilities.
The potential dangers with this pitfall are numerous: docs that lag or are outdated, leadership having no idea what the systems team is doing, or adopting product squads not knowing how or when to use system output.
This one is a bit like walking a tightrope over a poisonous swamp, but sharing the system team’s planning work can be essential in helping product folks understand the system team’s priorities.
3. Don’t Change Fundamental Tech Frequently
Design systems teams are tasked with delivering on all the promises we make to product teams: consistency, efficiency, quality, etc. One of the primary elements of ensuring these promises come to fruition is consideration of the future. The decisions a design systems team makes have wider reach than a typical product team’s decisions, and as such require ensuring that the decisions the systems team makes will work for the company today, in 6 months, in 2 years, or beyond.
When the core technology used to build design tokens, build components, use as your workshop tool, or document your design systems changes on a pace on par with product, the systems team can feel like they’re standing in quicksand. Or maybe even more accurately, it can feel like you’re standing in quicksand, and are able to get out, only to find yourself in another pit of quicksand.
The result of swapping out core fundamental tech used by the design systems team can lead to the perception that the systems team isn’t moving at an acceptable pace, or is for some reason unable to deliver on the initial promises made to product. At it’s worst, it introduces mass quantities of tech debt for the systems team and product teams alike. The message design systems teams should deliver to product: all tools or tech used by the systems team is owned by the core systems team, full stop.
4. Don’t Staff Backend Folks on the Core Systems Team
Brad Frost’s recent Design Systems Ecosystem article puts more definition and clarity around the various tiers of design systems than anything I’ve seen prior. One of the primary tenets is that the core layer of your design systems should be Web Components, with tech-specific implementations (React, Angular, iOS, etc.) sitting at a completely separate tier, one layer above the core Web Components:
If you take this approach, and your core layer of Web Components is intended to power additional layers of components that are tech-specific, complex recipes or smart components, naturally the core layer should consist of fundamental semantic HTML, CSS and presentational JavaScript. This is the territory traditionally occupied by the wily frontend hybrid. I’ve written a bit about this, as I myself am one.
When product engineers with more backend experience than frontend (or even back of the front) are repurposed to work on core design systems web components, the result is components that look like what I might look like after falling into a pit of scorpions.
Nathan Curtis has summarized the best people to work on core Web Components in code:
Design systems tend to be a home for hybrids that bridge design and development. Depending on the culture, it can be a very risky place for them. Often, you find a designer who’s frontend capable, but isn’t the world’s leading expert on Typescript, and suddenly they’re rejected by the development staff you’re trying to merge into the program because they don’t know all the ins and outs of Typescript. They could totally run circles from a design token/tooling perspective around all those Typescript developers, but they’re not allowed in the repo. Be careful of that, but also work to set expectations of inclusivity and how team members can evolve. (from Nathan Curtis @ Clarity 2021, in his “Design Systems Operations” workshop)
Staffing systems thinkers, with a blend of in-house folks and fresh hires is likely the blend to successful systems teams. I say we let hybrids do what they do best (core Web Components), and let the backend folks focus on what they do best (tech-specific or smart components).
5. Don’t Open Contributions Before You Establish Workflows
“Let’s open up the repo and let every engineer in the company contribute to the design system”. Famous last words. If design systems teams are perceived as slow, a typical response from product folks in an attempt to speed things up is to open up contributions to product engineers.
In the words of the prophet Nathan: “Contributions as a solution to speed? Such a false promise.” (from Dan Mall’s conversation with Nathan Curtis and Amy Hupe on Measuring Quality with Design Systems).
The intent is valid, but this is one of the larger pitfalls. Everything implemented by design systems teams has wide reaching repercussions. Because of this fact, design systems teams have more rigorous rituals, and any contribution to the systems team must go through this rite of passage. Staffing systems-minded engineers to the team is a must.
The results are disastrous: inconsistent API decisions, misalignment between design and code, and perhaps the most dangerous side-effect: other product squads using something from the systems team that wasn’t properly vetted, and doesn’t meet the systems team’s standards.
Don’t open this pit of vipers and unleash them on your design systems efforts.
6. Don’t Go the Same Speed as Product
The cardinal sin of design systems: expecting the systems team to move as fast as product.
While design systems teams exist to support product, and should be aware of product roadmaps to help inform possible upcoming work for the systems team, an important distinction is essential: the design system roadmap is a different roadmap. This probably means that the systems team doesn’t adhere to the same sprint cycles nor release schedules as product.
This can be the most difficult to address, since it likely requires cultural change at an organization. Further, it has the potential to surface dysfunction at the largest level possible for the organization (who thought getting into design systems would be more about communication than anything else?).
Practically, it means the systems team has to dance the delicate dance of being informed by product, without being driven by product. Josh Clark’s recent article Ship Faster By Building Design Systems Slower articulates the differences in stark clarity. Not only are design systems and products different tiers, they orbit at a difference cadence.
The effects of design systems teams moving at the speed of product are dire. Burnout for team members, and ultimately the design systems team duplicating the same problems that exist in product, which ironically they are put in place to remedy.
Break down the established walls within your organization by clearly communicating the differences between product and design system speed.
Taking It All In
When you add it all up, if the design systems team takes on too much, hyper focuses on components, swaps core fundamentals frequently, doesn’t staff systems thinkers, opens contributions before proper process is in place, or tries to move at the pace of product, what you end up with is antithetical to the design systems team’s raison d’etre.
Without proper guidance, most design systems probably won’t make it past level 1.
Take it from our trusted friend, Jack Black.
