Still Rewriting Your UI Every Time the Design Changes? | Spatial UI

In this episode, I break down Spatial UI as a practical approach to organizing visual roles in a frontend system — and show why it becomes especially useful when design requirements keep changing. We’ll start with a realistic MVP scenario: marketing wants to rethink almost the entire color system. The colors are already centralized in variables, but components still depend directly on values like slate-775, slate-850, or generic names like primary and secondary. The problem is simple: those names tell us what the value is, but not what role it plays in the interface. From there, we’ll look at Spatial UI — a model where the interface is treated as a set of surfaces at different levels of depth, and colors are defined by their visual responsibility rather than by a specific shade. I’ll also show how primitive tokens and semantic tokens work together, how to map existing components to roles like surface-base, surface-raised, surface-subtle, and surface-sunken, and how to migrate an existing project away from direct color dependencies. The result is simple: refactor once, and the next major design change can take minutes instead of hours — without touching dozens or hundreds of components. The main idea is simple: Your components shouldn’t know the color. They should know its role. Project: https://github.com/eugenezalens/cache-routes-independence Instagram: https://www.instagram.com/eugenezalens/