Periodically and inconsistently - but roughly once a month - I run a free Zoom session called Design Systems Open Space.
It’s a chance for folks who work on design systems to gather together, meet each other, and share challenges we’re facing.
Each open space focuses on a different topic - and we used this month’s session to explore the question that just won’t die: What should be your design system’s source of truth?
Here are my reflections from the session
This was actually interesting
Despite my trepidation (read: anticipatory fatigue) I was surprised to find myself amidst a genuinely interesting and thought-provoking discussion. We explored aspects of this question that I haven’t encountered before - I learned a lot from the conversation and come away with new insights and ideas.
Single source of “it depends”
I was heartened to discover a clear point of unanimity: it’s basically impossible to define a universal single source of truth for design systems.
As one participant put it, we’re really dealing in a single source of “it depends”.
The source of truth for maintainers might be different from the source of truth for users
One of the variables impacting our source of truth is whose perspective we’re approaching the question from.
For system maintainers and contributors, we’re likely thinking about where we go to store, document and maintain the system.
For people using the system, it makes more sense to consider the place they go to reference and use the system.
These places can be different and, indeed, they often are.
Design the system to meet people where they are
Even within a team of maintainers, skillsets and tooling may mean create different access points to the design system they look after. Whilst we can probably expect developers to work on the codebase, content designers might be updating documentation via a content management system, and designers might be defining components in Figma. Whilst the system itself may have a canonical source, these access points are, for all intents and purposes, the main source of truth from the point of view of the individual maintainer.
And even if we do succeed in establishing one destination from which our systems team can maintain it, access points for our users are likely to be far more varied. The most important thing, one attendee posited, was to design around user tasks or “job stories”. Rather than forcing everyone to a single destination, consider the users task and design a system that propagates its constituent parts to meet people where they are.
Communication is critical
Given that people experience our systems differently depending on their vantage point, we agreed that clear communication was essential.
Rather than assuming that everyone is aligned on the bounds of our systems, the language we use, and the way things get defined, distributed and evolved, we must over-communicate to the point of tedium to build shared knowledge.
Is the real source of truth the friends we made along the way?
One comment that really stood out to me in this discussion was that the real source of truth is the people within our organisation: their individual and collective knowledge; the way they collaborate; and the touch points at which they come together.
When we talk about the systems source of truth we tend to concentrate that conversation on artefacts: docs or code? Figma or GitHub? But it’s the human systems in our organisations that determine what enters our system in the first place.
Does it actually matter?
Design systems do not have a single source of truth. Individuals may experience the system through one, primary destination - or they may not. But the point is that a system is a system, a collection of constituent parts that work together to form something coherent, multifaceted, and complex.
Fixating on a single source of truth forces us into linear thinking, which is antithetical to the very notion of a system.
As Geri Reid, who kindly helped me facilitate today’s session, put it in the notes she shared with me afterwards:
“This confusion over the whole source of truth thing is a problem of own making in design systems.
Design systems are about people so I feel like we’re perhaps overcomplicating something that isn’t really even a thing.
Let’s never talk about this again.”