A product that evolves as quickly as an AI platform has a natural tendency toward visual entropy. Every new feature introduces new patterns. Every new screen makes slightly different spacing decisions. Every new component interprets the design language a little differently. Over time, the product starts to feel like a collection of features rather than a cohesive experience.
Design system discipline is how we prevent this. Not a design system in the sense of a component library - though we have one - but discipline in the sense of strict, enforced constraints that every piece of the interface must respect.
The constraint set
Our design system is defined more by what it prohibits than what it provides. No hard borders between sections - use spacing and background shifts instead. No stock colour palette values - use the specific warm colour tokens we defined. No arbitrary font weights - body at regular, labels at medium, headings at semibold only. No decorative shadows - use them only on floating overlays where they serve a functional purpose.
These constraints sound restrictive. That is the point. When every engineer and every AI-assisted development session works within the same tight constraint set, consistency emerges naturally. You cannot produce a visually inconsistent component if the palette, the spacing scale, and the border rules are all predetermined.
Why warmth requires discipline
Our warm, content-forward aesthetic is harder to maintain consistently than a standard technical interface. A dark theme with sharp edges is forgiving - slight inconsistencies are masked by the visual weight of the dark surfaces. A light, spacious, warm theme exposes every inconsistency. A section with slightly different padding. A shade that is a few degrees off the defined palette. A border that sneaked in where spacing should carry the weight. These small deviations are highly visible in a minimal interface.
Maintaining warmth at scale requires more discipline, not less. Every component, every screen, every new feature goes through the same constraint check.
The component contract
Each component in our library has a clear contract: the props it accepts, the visual states it supports, and the spacing it claims. Components do not make internal decisions about borders, colours, or type sizes. They draw from the shared design tokens exclusively.
When a new pattern is needed, it goes through the component library rather than being implemented ad hoc. This creates a natural consolidation pressure - similar patterns get merged, unique needs get evaluated for whether they justify a new component, and the total number of visual patterns stays manageable.
Speed through constraints
Counterintuitively, strict constraints make development faster. When you do not have to decide whether to use a border or spacing, which shade of grey for a secondary text, or how much padding a section needs - because these decisions are already made - you can build new features rapidly without the cognitive overhead of a hundred micro-decisions.
Design system discipline is not about slowing down to make things pretty. It is about going fast without making things inconsistent.
- Cleo's Team