Back
Systems/5 June 2026/Abhishek Dhall/6 min read

Design Systems, Not Just Colors

Most teams reduce design systems to components and tokens, but the useful part is the shared judgment behind them.

Interface blocks, grids, and token notes laid out on paper

When people say they want a design system, they usually mean they want less inconsistency. That is fair, but the system only starts becoming valuable when it helps people make better decisions without starting from zero every time.

For me, the useful part is not the token sheet. It is the logic behind spacing, emphasis, hierarchy, and interaction patterns. Once those are explicit, design reviews become calmer because you're discussing intent instead of arguing over random preferences.

A design system should remove avoidable debate, not remove thinking.

I also think systems work best when engineers can read them quickly. If a component library looks complete but still needs a Slack thread to explain every edge case, it is not mature yet. The system should reduce ambiguity in implementation, not decorate it.

That is why I care about naming, state coverage, and real usage examples more than polished Figma screenshots. Good systems are boring in the best possible way. They quietly make the product feel trustworthy.