This whole ‘source of truth’ thing has been the root of many debates and a rallying cry behind some DS-focused solutions…but maybe its not the focal point we think it is.

This phrase has been at the core of many a design system conversation — where is ‘the source of truth’? Is it your design files, is it design tokens, is it live code? It’s never sat right with me, and it’s taken a while to feel like I’m clear on why.

When we say truth in this context…the truth of what? Tokens might be canonical, shareable sources for design decisions. Our live code is what our users experience, so that sounds like what’s ‘true’ in some regards too. But here’s part of the issue — I’m not sure what we mean by ‘truth’ in this context. There can be many forms for many reasons.

I’m siding more on the idea that the whole workflow contains our source of truth, from intent, through challenges and decisions to released solutions. What’s live might not’ve been the original intent. We might have tests that informed what went live. From problem space and through each discipline, we end up with a different view of what we’re creating, even just in our design systems. There might be one source of truth for design decisions, another for documentation, in engineering and so on, but this phrase often just seems to create a cloudy picture of which is somehow more true than any other source. To me, these sources combine to give us our truth — of intent and purpose, of construction and measure of success. It’s no more one thing than the other.

It’s weird and also feels really unhelpful. What d’you think?