A few months back, I wrote about how early advocacy promised that design systems would improve the consistency of our products, and how that promise never really materialized. Lately, I’ve been thinking about another piece of that early conversation: namely, that design systems would introduce new, more collaborative ways of working.
Here’s a 2016 post from the Airbnb Design team, in which they describe how their design system helped improve collaboration between designers and engineers:
The gap between designers and engineers has only increased. Design teams can often struggle to reach a cadence that balances the creative process and cycles of continuous innovation. Quality suffers, the experience becomes less cohesive, and talented people spend an inordinate amount of time simply managing communication across disciplines.
The process Airbnb describes might be pretty familiar to you. A designer might “mock up” new features in a design application like Sketch or Photoshop, and then hand off those designs to an engineer for implementation. Two disciplines, each with its own workspace: a layout application for designers; for engineers, code.
To close their “collaboration gap,” Airbnb started to build, well, collaborative software:
…we’re investing in code as a design tool. Moving closer to working with assets that don’t only include layout and design, but also logic and data. This helps bridge the gap between engineers and designers, thus reducing the need for design specs–or redlines–and the steps between vision and reality.
In other words, Airbnb built a suite of social tools, which each incorporated live patterns from their design system. Designers could pull live data and content into their prototypes; engineers could be more directly involved in early design explorations. These tools allowed designers and engineers to effectively sit side-by-side, and quickly assemble new concepts from live patterns in the design system. And according to Airbnb, that collaborative infrastructure is what brought design and engineering closer together.
I think this is a wonderful article, and an even better case study. What’s more, it’s representative of much of the advocacy of the time: an argument that design systems would enable designers and engineers to work more closely—and more effectively—together.
But in my experience, design systems haven’t brought this kind of rich, cross-functional collaboration to most organizations. Instead, the existing divisions between design and implementation have become entrenched, and massively so.
Now, this siloing isn’t because of design systems—not really. I can think of a few factors that contributed to the current state of things, and I’m going to look at each in turn.
A matter of limited resources.
First and foremost, there’s surprisingly little ready-made technology out there that’s interested in bringing design and engineering closer together. Now, that’s not to say collaboration hasn’t improved at all: platforms like GitHub or Glitch have made engineering environments much more social and collaborative; utilities like Figma and Abstract have done the same for design. In other words, design applications have made it much easier for designers to work together; development applications have made it easier for developers to work together.
But it’s been over four years since Airbnb’s post. In that time, the gap between each discipline’s workspace hasn’t changed significantly. Maybe your teams would benefit from something like Airbnb’s Airshots utility, which allowed its users to quickly preview thousands of pattern permutations across different devices or language sets. Sadly, there are few products like it. What’s more, there are surprisingly few products focused on the space between design and implementation—on bringing design workspaces and engineering workspaces closer together. This means that if your organization wants to close that gap, you’re going to have to take on a fair amount of custom development.
There are some tools to help with this, of course. Figma’s API provides read access to values defined in art files, which can more tightly integrate design decisions into production code—for example, by programmatically extracting design tokens from a Figma file. But these are pieces of the puzzle, not a finished solution. So for many organizations undertaking systems work, the costs to building custom workflow infrastructure can be prohibitively high.
And there are other costs to consider.
A matter of front-end complexity.
Just to underline something: these frameworks can offer real, tangible benefits to organizations that use them. I’m not here to suggest those benefits aren’t there, nor am I here to criticize the frameworks themselves. (I’m not qualified, not really, and folks like Tom MacWright and Tim Kadlec have written far better pieces than I ever could.) But what’s rarely discussed is the social and organizational cost of that complexity.
When starting a project, I’ll often ask a new client how a non-engineer might make a change in their product’s design. For example, if a designer wanted to update a line of CSS, does an engineer need to implement it for them? If the designer can do it themselves, what technologies will they need to install? What component structures or syntaxes will they need to learn? How will their work be reviewed, and by whom? Can the designer deploy the change themselves?
I’m not asking these questions to suggest a designer should be able to directly update the design.Footnote 1 Rather, they’re helpful in evaluating the amount of collaborative friction that’s built into the product’s technical architecture. Put another way: what kind of decisions does your technical stack make about who’s allowed to contribute to the front-end? And how expensive will it be to alter those decisions, and introduce a different way of working? For many organizations, the technical barriers to cross-functional collaboration can be unacceptably high. And what’s more, the cost of that complexity is rarely acknowledged.
There’s a broader point here, one that extends beyond front-end frameworks.
A matter of collaborative costs.
Modern digital teams rarely discuss decisions in terms of the collaborative costs they incur. It’s tempting—and natural!—to see design- or engineering-related decisions in isolation: that selecting Vue as a front-end framework only impacts the engineering team, or that migrating to Figma only impacts designers. But each of these changes the way that team works, which impacts how other teams will work and collaborate with them.
Yeah, I realize that sounds a bit obvious. But we’re often inclined to think of a design system as distinct from an organization’s broader structure, which isn’t the case. More often than not, your design system becomes a mirror of the way your team already works. If you’d like to rethink the way your team works, it can’t be seen as something that just happens when you adopt a design system. Improved collaboration needs to be a stated goal at the outset, with clear proposals about how to get there. And every decision made throughout the process needs to measured against that goal.Footnote 2
Mark Llobrera said something recently that really stuck with me:
…the work that goes into making artifacts, deliverables — and, yes, patterns — is where the value lies, more than in the artifact itself.
As Alla Kholmatova said in her book Design Systems, a design system is “a set of interconnected patterns and shared practices.” Design systems work is much, much more than a pattern library: it’s the way your organization works with those patterns. As you start defining your design system, it’s worth having a hard, thoughtful discussion about the way your team works, and how a design system might support a better way of working.