CASE STUDY · DESIGN SYSTEM · ENTERPRISE SAAS · 6 MIN READ
THE DESIGN SYSTEM CAME BEFORE THE FIRST SCREEN
A token-first design system for a six-module enterprise HRMS — built solo in under a week with an AI agent, and now used in both design and development.
ROLE
Sole designer of the design system
TIMELINE
4–5 days for v1
TOOLS
Figma · Claude + Figma agent (MCP)
CLIENT
Enterprise HRMS · Indian client · NDA
SOME OVERVIEW
Product context
The client is an Indian enterprise building an HRMS: one platform for employees, policies, payroll-adjacent masters, settings and super-admin controls. It was planned as a large product that would keep growing, module by module.
Before any screen was designed, I built the design system on my own. Three designers then designed the platform on top of it, and the development team built the same components in code.
Key point
On a platform this big, inconsistency compounds. Every screen drawn without a system is a screen someone redraws later so the system had to come first.
THE ASK
Problem statement
The system had one job: let several people build a large product in parallel without it drifting apart.
A team of three designers
USER
is
building a six-module enterprise HRMS.
USER ROLE
They need
one shared set of tokens and components
USER NEED
so they can
ship every module looking and behaving the same.
GOAL
And the developers needed the same thing from the other side: component names and states that match what they build.
WHAT IT HAD TO HANDLE
What the platform demanded
Looking at the platform’s first modules, four demands shaped what the system needed to cover.
Six modules, three designers
Login, employee management, policies, settings, masters and super admin — designed in parallel.
Data-heavy screens
Tables, filters, bulk upload and row actions appear on almost every page.
Light and dark from day one
The theme layer carries both modes, so no component hard-codes a colour.
Built in code too
Developers implement the same components, so names and states had to match.
GETTING TO WORK
Three principles
Three rules kept a fast build from turning into a messy one.
01
Theme before components.
Tokens first, so every component — and every AI-generated variant — is on-brand from the first run.
02
Borrow structure, own the brand.
Component anatomy comes from a proven open-source kit; the look comes entirely from the client’s theme.
03
Every change is versioned.
A changelog with semantic versions, so designers and developers always know what moved.
HOW I BUILT IT
Theme first, then the agent
Step 1 — the theme, by hand
I started with the foundation, not the components. The tokens sit in three layers: a base scale, a theme layer with light and dark modes, and a full colour palette. Typography, shadows and spacing were set the same way, so nothing downstream would need a raw value.
Token layers — 12 base values feed 25 theme tokens in light and dark, which feed 190 colours
Step 2 — components, with an AI agent
With the theme in place, I worked with Claude and the Figma agent (through Figma’s MCP connection) to build the components. I used an open-source kit’s structure as the reference for anatomy, and the agent generated each component’s variants and states directly against my tokens.
WHAT THE AGENT DID
— Generated component frames, variants and states
— Applied theme tokens and text styles to every layer
— Repeated the same pattern across all 28 components
WHAT I DID
— Built the theme and the naming before any component
— Chose which components and states the platform needed
— Reviewed every component and fixed what didn’t hold up
Why the order mattered
Because the theme came first, the agent never had to guess a colour or a font. Its output was on-brand from the first run — my time went into judgement, not pixel-pushing.
Component sheet — every variant and state, built on theme tokens
Step 3 — a changelog the whole team writes in
Once three designers and a development team depend on a system, an unannounced change is a bug. The system has a changelog page with semantic versions and a status legend — added, changed, deprecated, removed, fixed — and every entry names who made it.
Changelog v1.0.1 — fixes and changes logged by the designers who found them
WHAT SHIPPED
What’s inside
28
components with full states
227
design tokens in 3 layers
69
text styles
2
modes: light and dark
Components include buttons, inputs and text areas, selects and dropdowns, date picker, OTP input, number and search fields, tables, tabs, pagination, modals, drawers, alert dialogs, toasts, tooltips, avatars, breadcrumbs, skeletons, switches, radios and the side menu.
In use — a master-data list and form, built entirely from system components
SO, DID IT WORK?
Impact
v1 took four to five days. The client doesn’t share product metrics, so I measure this by what the system made possible:
— The system existed before the first screen — nothing had to be redesigned to fit it later.
— Three designers built the platform’s modules from the same components and tokens.
— The development team built the same components in code, with matching names and states.
— Changes are versioned, so a fix in one place doesn’t silently break another.
LOOKING BACK
Pausing to reflect
Working with an AI agent changed where my time went. The slow part of a design system used to be drawing every state; here it was deciding what the system should be — the theme, the naming, the components the product actually needed.
Next, I’d add usage guidelines to each component — when to use it, and when not to — and finish the five components still paused. A system is only as consistent as the decisions written down next to it.