Among the many (many, many) points Ursula Franklin makes in The Real World of Technology, she suggests that technology is best understood not as software or gadgets, but as a practice: as a way of doing something.

Looking at technology as practice, indeed as formalized practice, has some quite interesting consequences. One is that it links technology directly to culture, because culture, after all, is a set of socially accepted practices and values. Well laid down and agreed upon practices also define the practitioners as a group of people who have something in common because of the way they are doing things. Out of this notion of unifying practice springs the historical definition of “us” and “them.” I think it is important to realize that the experience of common practice is one of the ways in which people define themselves as groups and set themselves apart from others. “Around here, that’s how we do things,” a group will say, and this is their way of self-identification, because “others” may do the same thing differently. A different way of doing something, a different tool for the same task, separates the outsider from the insider.

“Around here, that’s how we do things.” I don’t know about you, but that line rings real true for me. Take any technology you work with — React, Figma, Webpack, Invision, Bootstrap, what-have-you — and look past its specific features. Instead, think about how it changes the way that you work. How it structures your work; reshapes it. That technology makes many things possible, sure, but it also prevents you from walking down certain unsupported paths. It’s a way of doing something.

If that’s true, then let’s look at the way our industry talks about design systems. To do so, let’s review a few quotes from some systems’ websites. (All emphasis mine.) To start us off, here’s GitHub’s Primer CSS framework:

Our goal is to create a system that enables us to build consistent user experiences with ease, yet with enough flexibility to support the broad spectrum of GitHub websites.

Here’s Instacart’s Snacks library:

Snacks is a JavaScript and React based component library. It has a default theme matching Instacart’s styles, but can accept theme configurations.

Here’s the Pluralsight Design System:

The Design System strives toward a cohesive design language for Pluralsight’s products, a shared vocabulary for our teams, and basic building blocks to accelerate development.

Atlassian Design introduces the AtlasKit library thusly:

These components are Atlassian Design Guidelines(ADG) compliant, reusable, well-maintained and accessible.

And finally, here’s the introduction to BuzzFeed’s Solid library:

Solid uses immutable, atomic CSS classes to rapidly prototype and develop features, providing consistent styling options along with the flexibility to create new layouts and designs without the need to write additional CSS.

Now, I chose these quotes not because they’re doing anything wrong — each of these systems is beautifully, thoughtfully made. But each of these quotes does something that is, I think, quite common: when our industry talks about the value of a design system, we focus first on the consistency it will provide.

And hey, don’t get me wrong: that’s good! Our interfaces are legion, and they benefit from consistency. (Our users do, too.) But a design system that optimizes for consistency relies on compliance: specifically, the people using the system have to comply with the system’s rules, in order to deliver on that promised consistency. And this is why that, as a way of doing something, a design system can be pretty dehumanizing. Jeremy recently suggested as much, and Dave agrees; and as someone who occasionally worries about automation in design, I share their concerns.

But it doesn’t have to be that way. (Probably.) (Hopefully.)

Going back to The Real World of Technology, it’s worth noting that Ursula Franklin contrasts prescriptive technologies — which divide work into small, easily-reproducible tasks, so that they can be performed by unskilled laborers — to holistic technologies, which are quite different:

Holistic technologies are normally associated with the notion of craft. Artisans, be they potters, weavers, metal-smiths, or cooks, control the process of their own work from beginning to finish. Their hands and minds make situational decisions as the work proceeds, be it on the thickness of the pot, or the shape of the knife edge, or the doneness of the roast. These are decisions that only they can make while they are working. And they draw on their own experience, each time applying it to a unique situation. The products of their work are one of a kind.… Using holistic technologies does not mean that people do not work together, but the way in which they work together leaves the individual worker in control of a particular process of creating or doing something.

Emphasis mine, because I’m not sure I know of a design system that operates in a holistic way. Does the system you work with allow you to control the process of your work, to make situational decisions? Or is it simply a set of rules you have to follow?

It’s a question I’ve been asking myself since Mark Boulton shared his concerns about modern digital design systems. And more specifically, it’s something I’ve been wondering since Mark quoted Otl Aicher, who described the system behind the 1972 Munich Olympics identity as “a strictly designed grammar [that] allows free, playful application.”

Which brings me back to my earlier question: when was the last time a design system empowered you to make a decision about the best way to proceed?

To be clear, I don’t have an answer. I don’t know if there is a design system operating at scale that empowers its designers and developers to use situational judgment, that “allows free, playful application.” If there isn’t, then we’ll collectively need to figure out what that looks like. Very soon.