Scope, workflow, governance and the source of truth

A lot of what is talked about around design systems is the doing bit; the crafting of components, the tooling and design artefacts. Reading Ethan’s post ‘Truthish.’, I thought I’d contribute to the discussion he’s started.

Design systems, when done well can be a method for bringing people together and having more open and transparent communication. That doesn’t just happen on its own and needs a lot of work to enable that. Building a design system shouldn’t just be a case of building a library in a tool any more than design it should be just focusing on great components in code. It’s the things we can’t see that matter.

The experiences in Ethan’s piece are all things that exist out there in the real world so he’s totally correct in his assumptions and the gist of the piece. What’d I’d add to that is that these things can change if they’re conscious choices.

If we look at the notion of a “source of truth”, perhaps we could describe it as the most correct or definitive version of a thing. You can see, as he describes how if there isn’t consensus on what should be ‘the truth’ in a design system, that this might break down and ultimately lead to fragmentation and duplication, which is what the system itself should be helping to avoid. I’d argue that deciding on where the source of truth lies should be debated and formed as a joint decision, which is very much dependent on your org structure and weighting of specialisms. You could say the source of truth could be a brand book or style guide, a library in a design tool, design tokens or even the code itself. In my last company, we opted for the latter as that is what is actually used by our audience, but that was a deliberate choice that was right for us at that time.

Of course, this implies that there is already a method of making these decisions, and that a decision made would be happily accepted by everyone. Obviously, the real world has a habit of shattering more utopian ideals! What it shows is that who and how we communicate with others on our design system journeys is incredibly important, and overall, this is the key to whatever version of success looks like.

As someone leading or attempting to start a design system, this is far from easy. We can find ourselves being as much facilitators as we are working on more practical aspects, and might find ourselves out of our depth as we come across org fragmentation, a variety of opinions, and personalities to navigate. Maybe that’s not what we signed on for!

I’m a firm believer that, for the most part, we’re surrounded by good people wanting to do good work, and, above all, people want to be listened to and respected (though happy to be proven wrong!). This facilitation mode we need to engage enables us to actually design a governance process, workflows from concept to code and of course, decide on what the source of truth will be and most importantly why that is. This kind of design is easy to overlook but really integral to getting the most from a design system: why are we doing this? Are we agreed on what we’re doing? If not, why not? If we make a bad call, how do we solve it together?

So I guess, building on what Ethan started in his piece, I’d call out this space as being a core competency, whatever shape that takes for you. As he says, “Design systems work is fundamentally lossy […]. The more our mental models, our processes, and, yes, our sources of truth acknowledge that fact, the stronger our design systems will be.”