In much of the design systems work I’ve done, I’ve frequently encountered a subtle, gently persistent impulse to frame most issues as technical in nature: that once this thing is implemented, some other, deeper issue in the design system will be fixed. Whether it’s semantic versioning for components; the software used to generate your pattern library; the repository structure for a given component library; the right governance model; a new architecture for your design tokens; or something else entirely — that thing is an important, if not critical, part of a healthy design system. But it’s still just one part of that greater whole.

I was reminded of this earlier today, when my friend and business partner Jeff Eaton threw together a great little Twitter thread about design tokens. Here’s one central bit that stuck out to me:

What I mean is that “design tokens” are a language for communicating intent between disparate parts of a system. By definition, that’s complex and nuanced work. It’s an attempt to make explicit and dependable something that has (in most publishing systems) been implicit and inconsistent. It faces all the challenges of language.

I love that. It subtly reframes design tokens not as an architectural issue, but as something broader than that.

It made me think of something I’ve mentioned elsewhere, in talks and on this little blog, that I hear a lot of design systems fatigue in the industry. Not that folks are tired of design systems, mind you. But rather, they built their system because something wasn’t working at their organization; and after shipping the system, things don’t necessarily feel better. But they definitely do feel different. Why is that?

I think it’s worth starting with a question: why create a design system? Personally, I’ve always been lightly skeptical of the “consistency” argument. That’s not just because design systems haven’t really solved that problem. But more importantly, “fixing inconsistent interfaces” very likely isn’t the biggest issue facing your organization’s digital efforts.

So, again: why create a design system?

Personally, when I’m talking to clients, I like saying something like this:

A design system should make it easier to talk about, and then execute, design at a scale that’s useful to you.

…yeah, okay, fair point. It’s a fairly anodyne statement. But I like it because it’s a decent opening to a much broader discussion: one that shifts focus away from client-side frameworks or specific design tools, and toward the question of what kind of design work does your organization want to do? It’s much bigger than the software package or design tool applied to a specific task. It is, as Jeff so beautifully noted, a question of communication and intent.

Without having that discussion, it’s very easy for organizations to adopt new things on an ad hoc basis, in an attempt to gradually patch themselves toward a better way of working. But all too often, these are short-term fixes that don’t acknowledge a deeper, underlying cause, something in the way your organization currently structures digital work. And frequently, that’s what’s preventing an organization from doing the design work it needs to.

Put another way, I’ve found the best place to start a design systems initiative is, well, to discuss the design work your organization needs to be doing. And part of that discussion involves acknowledging the organizational issues that might be preventing you from doing that work. Once you’ve identified the root causes, you’ll be in a far, far better place to choose the right things — and more importantly, to create a system that finally supports your design.

My thanks to Karen McGrane, who kindly reviewed an earlier draft of this post.