bp
Contents

Your Design System is Not a Solution

Crop male master shaping wooden stick with spokeshave in workshop. Photo by Ono Kosuki

You've got a problem. Your painting fell, and you want to hang it back up. You grab a hammer and some nails, you get to swinging, you make a few adjustments, and Hey Presto! before you know it, your problem is solved.

You have implemented a solution: you hung the painting.

Just then, your neighbour knocks on the door. Wouldn't you know it? he also has a problem. His painting has fallen, too. He also needs a solution. Being the magnanimous, good-looking, and preturnaturally charming neighbour that you are, you leap into motion, practically stuffing his arms with hammer and nails, and you send him on his way, richly satisfied by your own generosity.

An hour later, he knocks again. You see — your house is built of timber and drywall, while your neighbour's house is built of cinderblocks and plaster. Your neighbour now has two problems — his painting is still on the floor, and he now has an unsightly hole in the wall.

Tools, or Solutions

Now, your solution needed a bunch of tools to get 'er done:

Some of those tools were essential to the solution, others less so. But they all have one thing in common:

none of those tools is the solution to your problem.

If you really needed to, you could probably hang that painting with an old shoe

Consider, too, that your solution didn't work for your neighbour, who built with cinderblocks and plaster, and actually made things worse for him. What went wrong? Was it the tools you gave him? Not necessarily. He might have used the hammer you gave him to drive special cinderblock nails or those plastic-and-tack plaster hooks.

The problem wasn't the tools — the problem was seeing the tools as the solution.

Jackhammers require care in use. Thumbtacks are cheap, plentiful, and not particularly dangerous. Both are needed on a construction site — one to break large blocks of concrete and rock, one to hang plans and blueprints. Both tools are important — crucial even — in their own ways, but they have widely different costs, lifespans, and restrictions on their use.

Cui Bono?

If you've been following along, you're probably waiting for the punchline, so here it is:

Your design system is not a solution, it's a toolkit

So why do companies adopt design systems? Are they just spinning their wheels? Well, my desire to continue receiving a steady paycheque requires me to say, "No, they aren't! Design systems really do solve problems for companies!" But there's an important difference between the kind of problem which design systems solve and your team's design problem.

Companies adopt design systems because they want:

All of these are fancy ways of saying they want to establish and enforce rules and guidelines for producing user interfaces. Design systems help solve that problem by centralizing the know-how for building the components of those interfaces in a way which can be easily ported to different teams' workflows.

Mowing the Neighbour's Lawn

Design systems can't and shouldn't try to solve every problem for every team. This industry is by its nature prone to widely varied opinions and approaches, one often incompatible with the other, and establishing a baseline is hard enough without shipping bespoke implementations for each team that comes along. The reasons for this become immediately clear once you shift perspective from that of the product maintainer to that of the design system maintainer.

The specialist skills needed to produce a design system are not the same as those needed to ship products. Product teams often need to move quickly to ship new features, built on top of the previous framework, and they often don't have the luxury of The Big Rewrite™.

From the design system maintainer's point of view, the customer is actually the product owner/developer. That's not to excuse design systems from concerning themselves with end users — quite the opposite. But rather, as toolmakers, their primary responsibility is to produce quality tools for their fellow craftsmen.

If you don't own the problem, you can't own the solution

Since different projects have different toolchains, histories, and processes, they have different constraints as well. What appears to be a non-starter to one maintainer is a no-brainer to another. Because of this, design system engineers would do well to focus their effort on platforms rather than frameworks.

Tech Debt up to Here

So, your design system is now free to build on top of platform primitives, and there are greenfield projects and high-velocity teams reaping the benefits of platform-oriented development. Lechaim — 🥃 Fancy bourbon all around! But that still doesn't solve the problem of legacy framework integration. Who's left holding the bag?

Some organizations solve this by reimplementing their design system for every framework that comes along. To my taste, this practice is error-prone; remember our initial goals from above. Web development is complex enough when targeting the browser: duplicating that effort across multiple frameworks scales that complexity geometrically. It also requires more resources, effort, attention, and time.

Moreover, tracking integration problems inside the design system repositories can lead to an awkward situation where greenfield users might mistakenly adopt the workarounds and second-bests in place of the happy path. There are costs to increasing API surface, and teams responsible for shipping tools to diverse projects shouldn't be burdened with the maintenance of those workarounds, when they have other customers who don't need — and shouldn't try — to adopt them.

Design systems that rest on platform features like custom elements, shadow DOM, import maps, and plain-old CSS can adapt to multiple projects and frameworks. It remains true that legacy frameworks have varying degrees of capability when it comes to integrating with platform features newer than 2019, but it's not impossible by any stretch of the imagination.

Solving Integration Problems

Rather than being tasked with owning, implementing, and delivering solutions to legacy framework integration problems, design system teams should be empowered to consult with and advise those teams to solve the problems on their own terms.

Design system teams can solve integration problems, but they can't own them. It's crucial for teams to communicate clearly and openly, and to understand the business needs that design systems solve. When approaching a difficult integration, everyone at the table needs to understand the boundaries and junctions between business needs, framework limitations, and design system priorities. Downstream teams have to be willing to work with design systems people to integrate solutions which serve the broader business, and design systems people have to be willing and able to cross the aisle to work with downstream on their turf.

Clear boundaries and the application of Postel's law are the fundamentals of fruitful large-scale software collaboration.

Be conservative in what you do, be liberal in what you accept from others.

Many thanks to my design-systems colleagues Steven Spriggs, Brian Ferry, and Greg Gibson for their helpful notes on earlier drafts of this post.