Ethan Marcotte: “The design systems between us”

Ethan Marcotte has written about seams and edges being a defining part of his work, and in his latest post¹ he applies that same lens to the theme of organizational structure and collaboration, and how design system success stories haven’t been easily replicated. He writes:

[I]n 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.

Ethan breaks out a few specific reasons why we haven’t seen a direct improvement in collaboration as a result of design systems: limited resources, front-end complexity, and costs of collaboration. At the risk of repeating myself, I’m really convinced that organizations should start with the last item on the list. Otherwise we’ll treat design systems as a self-contained solution — instead of as a byproduct of deep organizational work.

Why do we often invert the order? One thing I’ve observed when working with clients is that cross-team collaboration needs a champion with enough authority to make that work happen, coupled with support from within the organization. (You also see this play out in diversity, equity, and inclusion work, but that’s another blog post for another time.) Without that external force, it isn’t surprising that teams will often iterate fast and hard, and create things that are tightly coupled to their immediate needs — because that’s where they have control. These teams often don’t have the authority to officially collaborate with other teams, or they lack the incentives to do so because collaboration is not a top-level priority for the organization.

Retail therapy #

Another way of looking at this is to appreciate how quickly design systems went from a tool that teams used to create products, to a product itself that could be sold to organizations hungry for the same results. You might compare it to the appeal of a capsule wardrobe: it’s easier, perhaps, to imagine all the ways a well-considered, interchangeable clothing system can make your life instantly better, instead of addressing deeper issues at the intersection of materialism and identity.

Adopting or creating a design system could address some issues (especially at the final level of assembling content or product) but leave deeper issues untouched. Those deeper issues are often what lead to the design system falling into dysfunction or misuse. It can also lead organizations to mis-identify their problems — they are likely not the exact same ones that Facebook/AirBnB/Saleforce were trying to solve with their design systems.

Bridging the gap #

Ethan’s observation about the missed opportunities between design and implementation rings very, very true to me:

[T]here 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.

At Bluecadet our work tends to be more project-based instead of iterative product work. We’ve tried out a couple of things like InVision’s DSM — like Figma, you can pull tokens into your front end system with a little bit of elbow grease. It still requires coordination, though, and tight collaboration. When it’s worked well, it’s been the result of a designer and developer paired closely together.

I’m not convinced that there can be a universal product that addresses that design/implementation gap — it would likely be so specific that it would require a lot of work to modify. Perhaps the best we can do is focus on friendly API design that clearly defines the boundaries where human collaboration needs to happen.

Gardening, again #

Garden metaphors abound in web design circles, and I’ll risk adding one more to the mix: perhaps high-profile design system success stories can be compared to walking through someone else’s finished² garden. We see that garden in bloom, and we are instantly inspired — and then tempted to replicate it. But maybe it’s better to accept that creating our own garden will result in something very, very different — a reflection of our own plot of land, emerging from work done slowly over time.