Design systems
A design system built so a government product can't quietly drift
As a national government product grew from onboarding into dashboards, finance, and support, every new screen was a chance to re-invent a button or re-pick a colour. I built the design system underneath it — primitive scales feeding semantic tokens feeding components — so consistency and accessibility are decided once, in the system, not re-argued screen by screen.
- Role
- Manager, UX/UI Design — design system architecture, tokens, and components
- Timeframe
- 2025
- Context
- National government product · Digital India Corporation, under MeitY
A design system isn't a component library. It's the contract that keeps design and code from drifting apart.
A government product never stays one product. What began as an onboarding flow grew into dashboards, a finance module, and a support system — and every new surface was a fresh chance to re-invent a button, re-pick a blue, re-check a contrast ratio, and quietly ship the fourth slightly-different version of the same thing. Across enough teams and enough quarters, that drift is how a product stops feeling like one product. I built the design system to make it structurally impossible — not just discouraged.
What drift actually looks like
One base collection, everything downstream
The system resolves in three tiers, and nothing hard-codes a value:
- 01Primitives
The raw colour and type ramps — every value the product can use, named for what it is, not where it's used.
- 02Semantic tokens
Roles like surface, border, and danger point at primitives. Screens reference the role, never the raw value — so meaning stays stable even when a value changes underneath it.
- 03Components
Every component binds to semantic tokens, not fixed styles. Change the token once and every instance updates — no find-and-replace, no drift.
One source of truth
Contrast is a property of the system, not a per-screen judgement
Colour roles map to base tokens per light and dark mode, so accessible contrast is decided once — in the token layer — instead of re-checked on every screen by every designer. Get it right in the system and every surface inherits it. There's no way to accidentally ship an inaccessible pairing, because the accessible pairing is the only one the tokens expose.
Decided once, inherited everywhere
Every state a government form actually meets
Most component libraries ship the happy path and improvise the rest. Government forms don't get that luxury — they hit read-only fields, server-side warnings, validation errors, and disabled states constantly. So each component ships with the full set — default, hover, focused, error, disabled, success, warning, read-only — across sizes, designed centrally, once.
Built to survive a second and third team
A design system is only worth building if it holds up after you leave the room. This one was built for that: variables so design and code share one source instead of a screenshot; semantic roles so a rebrand is a token change, not a redraw; and states documented so the hard cases are settled centrally instead of re-improvised by whoever ships next.
It isn't only components, either — it's the rules for using them. Each pattern ships with usage guidance and explicit anti-patterns, so the designer who joins next year inherits the judgement, not just the parts.
Usage, not just parts
Onboarding shipped on this system and produced the results in the Visvesvaraya PhD scheme case; the dashboards, finance, and support surfaces are designed on it now, rolling out in phases as engineering capacity allows.
In the wild
What I took from it
The interesting part of a design system isn't the components — it's the decisions you get to stop re-making. Contrast, spacing, states, the meaning of danger: decided once, in one place, inherited everywhere. On a government product that has to stay accessible and consistent for years, across teams that rotate, that isn't polish. It's the only way it holds together at all.
The token system is shown in full; the one product screen uses dummy data and is shared with permission. Happy to walk through the token architecture in more depth in conversation.