Rasheed Wallace was a force of nature on the basketball court for both his skill and his legendary trash talk.

But one phrase in particular became his signature.

If an opponent got a questionable foul call and went to the free-throw line, Wallace would wait. If they missed the shot, he’d smirk and say it:

“Ball don’t lie.”

The game itself, not the refs, would reveal the truth. If the call was fair, the shooter would make their free throws. If it wasn’t, they’d miss. The shot settled it.

The myth of the design system as a “source of truth”

Design systems are often described as the single source of truth for an organization’s design and code. They define the components, patterns, and principles that teams are supposed to follow.

In practice, they’re often more aspiration than reality. Figma files are pristine. Documentation is precise. Tokens and variables are thoughtfully named.

When you open the actual product, though, things don’t always match. Buttons have different paddings across screens. Components are forked in ways no one remembers. That lovingly crafted color token system? Someone hardcoded a hex value instead.

So what’s the real truth? It’s not the design system. It’s the product that ships.

The interface in the user’s hands is the only truth that matters

A design system can document what should be, but only the live software reveals what actually is. If there’s a mismatch, the design system doesn’t win by default. The thing that users experience is the reality.

At the end of the day, the best measure of a design system isn’t how well it’s documented. It’s how well it aligns with what users actually see and interact with.

Ball don’t lie, and the software in the hands of users doesn’t either.