frontend

Design Tokens vs Utility Classes: My Take

Thoughts from the intersection of code, craft, people, and progress.

Tokens win for clarity, scale, and design team sanity.

Design tokens and utility classes can both create consistency, but they operate at different levels. I prefer tokens because they capture shared decisions without requiring every piece of markup to provide a running commentary on its spacing.

The useful question behind “Design Tokens vs Utility Classes: My Take” is what changes in the work afterwards. A sound idea should improve a real decision, not only give us a neat phrase for describing it.

This matters because small choices repeat. What feels harmless once can quietly become the normal way of working.

Consistency is a conversation

A design system is often described as a collection of components, which is true in the same way that a kitchen is a collection of cupboards. The useful part is how people use it together and what decisions it helps them avoid repeating.

The strongest systems make the preferred path the easy path. They explain intent, show real examples, expose sensible constraints and leave a clear route for exceptions. A component without that context is only a reusable shape.

Consistency should reduce decision fatigue, not reduce thought.

Good systems do not remove judgement. They preserve attention for the decisions that genuinely need it.

That is not a dramatic conclusion, but useful work is often built from undramatic conclusions applied consistently.