The world’s on fire, so I’d like to talk about an essay I enjoyed.

The essay was Robin Rendle’s “Systems, Mistakes, and the Sea”. (I should note that I have deeply envied enjoyed everything I’ve read of Robin’s writing, and I bet you’d like it too.) Robin digs into some of the difficulties involved in working with design systems, especially those that have reached a certain scale.

Here’s one bit I liked:

In time I found that the curse of design systems work was seeing everything that’s broken, whilst on the surface it all looks fine. When you try to repair these problems though that’s when the whole thing collapses and the ruse is up. Every test in your app will break, old parts of the codebase will shatter and engineers will panic as if somehow the sinking ship was your fault and not the work of the gashes in each flank that you’re trying to repair.

If you’ve worked on, with, or near a design system, I’d bet much of what Robin describes feels very, very familiar to you: the small problems that feel huge; the frictions that can creep into your workflow; the immovability of certain parts of the system. And when you’re in the thick of working through an issue, it can sometimes be hard to understand why things aren’t moving more quickly, or more easily.

Robin brings a helpful name to this problem, by way of the philosopher Timothy Morton: hyperobject. A hyperobject is an entity whose scale is too big, too sprawling for any single person to fully appreciate their scale. Climate change, financial markets, socioeconomic classes, design systems — they’re systems we move through, but their scale dwarfs our own.

The concept’s not without its critics, mind. But I think the idea of invisible scale is helpful when working within a design system. As Jina Anne recently wrote, a “design system” encompasses more than just front-end patterns or design tools: it’s the ways in which a digital team or organization works. Unfortunately, we almost exclusively interact with that system — that hyperobject — through narrow slices of it. A product team defines a new design pattern; a developer refactors a module; a design team may migrate their component layouts from Sketch to Figma.

In my experience, the challenge of design systems work is helping teams think in more cross-functional, interdisciplinary ways. They need an awareness on how changing a single slice will affect the hyperobject — or more specifically, how it will affect the other teams and people who work within the system. As Ursula Franklin once wrote,

A change in one facet of technology, for instance the introduction of computers in one sector, changes the practice of technology in all sectors. Such is the nature of systems.

Personally, I much prefer to think not in terms of systems but of a web of interactions. This allows me to see how stresses on one thread affect all others.

I love that metaphor. A design I change, a pattern I build: they’re not just artifacts, but threads in a larger web. The results of my work — of our work — ripple throughout the rest of the system, and a systems worker strives to understand that.

Note: In addition to Robin’s “Systems, Mistakes, and the Sea”, this post was shaped by discussions with Karen McGrane and Jeff Eaton. Additionally, my thanks to Jina Anne for her essay on the human scope of design systems.