The Potter's First Unkneaded Grog: On the Brittle Rigidity of a Design System Without an Audience
A peculiar tension exists at the heart of modern front-end development, a tug-of-war between two often competing ideals. On one side is the pursuit of a perfectly engineered, internally consistent design system. On the other is the messy, unpredictable reality of how actual people use the things we build. I’ve come to think of this as the contrast between building a system to be admired by other builders, and building one to be used—truly and easily—by an audience.
The first approach is seductive. It begins with the noblest of intentions: consistency, maintainability, scalability. We meticulously define tokens for every conceivable color and spacing value. We architect a component library where every button, card, and input field is a perfect, self-contained entity, documented to a fare-thee-well. The logic is clean, the code is elegant, and from our insulated perspective, it is a thing of beauty. It’s like a potter preparing a flawless, refined clay, proud of its uniform texture. But in our focus on the material’s purity, we forget to add the grog—the coarse, granular material that prevents the pottery from cracking during the firing process. Our system is pristine, but it lacks the necessary grit of real-world interaction.
This brittleness manifests subtly at first. A button component, designed with perfect padding based on an 8pt grid, feels oppressively tight when a user needs to quickly tap it on a jostling train. A beautifully minimalist text input, with its slender border, becomes a source of frustration for someone with motor impairments trying to discern its active state. The system, in its rigid adherence to its own internal logic, has failed to account for the chaotic, human context of its use. It was built for the screen, not for the hand and the eye. It prioritizes the developer experience of consistency over the end user experience of clarity and ease.
The contrasting approach is less about building a monument and more about tending a garden. It starts not with a style guide, but with the audience. It involves observing, testing, and sometimes embracing the ‘ugly’ fix that serves a real need. This system is built with permeability. It might mean a component has a slightly different visual treatment in a high-stress part of the application because usability testing showed it improved comprehension. It accepts that a perfect theoretical model must sometimes yield to practical necessity. This is the kneaded grog. It introduces intentional, purposeful inconsistency to create a stronger, more resilient whole.
The choice, then, is not whether to have a design system, but what its ultimate purpose is. Is it a closed loop, an exercise in technical perfection meant to impress our peers? Or is it a living framework, designed to be stretched and adapted by the needs of the people it’s meant to serve? The former produces artifacts that are beautiful in the gallery of code but brittle in the wild. The latter builds interfaces that may lack a certain sterile purity but possess the rugged, enduring quality of something made to be handled. The most performant, stable layout is not just the one that loads quickly, but the one that feels right in the hands of its user, even when that feeling requires breaking a rule we so carefully wrote for ourselves.
Notes & further reading
A few pages I came back to while writing this: