Why design system coherence is really about respect for the craft
A few weeks ago, our team was implementing rounded corners on a component for a Fortune 50 client’s enterprise web platform. Rounded corners. The kind of thing that sounds like it should take an afternoon.
But here’s what actually happened: someone on the development team used a border-radius value that looked right — close to what was in the design comp — and moved on. When we caught it in review, the radius didn’t match the value already established by a related component in the same family. Same visual language, same page, two different interpretations of “rounded.”
And that’s the moment where a design system starts to erode.
I spend a lot of my time on details like this, and I’ll be honest — it can feel a little obsessive from the outside. Who’s going to notice a two-pixel difference in corner radius? Probably nobody on a single page visit. But compound that across dozens of components, hundreds of pages, and years of incremental decisions, and you get a platform that feels subtly off. Users can’t tell you why. They just sense it. The experience feels less trustworthy, less polished, less intentional.
At Johns & Taylor, one of our core values is Respect for Craft. And in digital experience work, craft lives in exactly these kinds of details — the ones that are easy to shrug off individually but devastating in aggregate.
Here’s what respecting the craft actually looks like in a design system: every component belongs to a family, and every family shares a vocabulary of visual tokens. Border-radius, spacing, color values, type scale — these aren’t suggestions. They’re the grammar of the system. When you modify one component, you check it against its siblings. When you introduce a new value, you ask whether it should become a system-wide token or whether you’re accidentally inventing a dialect.
We’ve built this into our workflow as a simple cross-reference step. Before any component ships, the person implementing it checks the visual tokens against every related component in the same family. It’s not a long process — maybe ten minutes — but it catches the kind of drift that compounds over time.
The rounded corners example is instructive because the fix was easy. We had a proof of concept in our component library that already established the correct value. The developer just needed to know to look there first. And that’s the real lesson: coherence isn’t about having better designers or more talented developers. It’s about having a system that makes the right answer easy to find.
I think a lot of organizations treat their design system like a reference book that sits on a shelf — something you consult when you’re confused, but mostly ignore when you think you already know the answer. The teams that do this well treat it more like a constitution. You don’t interpret the constitution differently depending on which judge happens to be reading it. The whole point is consistency of application.
This extends beyond visual properties, too. We require every component in our system to have one official name, one clear purpose statement, and documentation of when to use it — and just as importantly, when not to. Common aliases get listed so that when someone searches for “carousel” they find “slideshow” and don’t accidentally build a second one. These naming conventions sound bureaucratic until you’ve lived through the alternative, which is three teams independently building variations of the same component because nobody realized it already existed under a different name.
The practical benefit for our clients is straightforward: their platform stays coherent as it scales. New teams can contribute without accidentally fragmenting the system. And when brand evolution requires visual changes — updated color palettes, new typography, revised spacing — those changes propagate predictably because they’re built on shared tokens rather than one-off values.
Respect for craft means caring about the two-pixel difference. Not because anyone will write you a thank-you note for getting it right, but because getting it right is what separates a design system from a collection of components that happen to live in the same repository.
Same corners, every time. That’s the standard.
