Tailwind UDS
A design system where designers and AI tools speak the same language.
Our team builds AI tools for teachers and students. The existing design system was made for websites, in Bootstrap, while every AI coding tool writes Tailwind. So I extended it into one system where Figma variables, CSS tokens, and component classes all match.
Full case study coming soon. This is a short version while I rebuild it with the full evidence.
See the full prototype- My role
- Design System Engineer
- Team
- SDE team, ASU LEI · with Nishad Patne, Manmeet, Omkar
- Timeline
- 6 months · Sept 2025 – Feb 2026
- Used in
- ReQuesta · AIX Framework
- Components
- 70+
In 30 seconds
We were building apps with a system built for websites. AI tools wrote Tailwind; our system spoke Bootstrap.
Build on Tailwind, with a token structure where one decision creates a whole family of classes.
353 + 164 tokens, 70+ components, and code that works the first time, live in the AIX Framework app.
6 months, 5 phases, one system.
From research to production, built alongside the products that use it.
- 01 · Sept 2025DiscoveryEvaluated the existing system. Found the Bootstrap and AI-tool gaps.Done
- 02 · Oct 2025Foundation353 primitive and 164 theme tokens; token-to-class mapping.Done
- 03 · Nov 2025Components70+ components, annotated in Figma with class references.Done
- 04 · Dec – JanImplementationExported to CSS, Tailwind config, live in AIX Framework.Done
- 05 · Feb 2026 →ScaleStorybook and automated Figma-to-code sync.In progress
We were building apps with a system made for websites.
Every sprint needed workarounds. The team said it best.
Every time a requirement changed, I had to detach the component and rebuild it. If we're detaching every time, what's the point of a design system?
Designer painCopilot and ChatGPT always output Tailwind classes. Our system used Bootstrap, so I translated every class by hand.
Dev bottleneckWe needed a dropdown, a multi-step form, a tab panel. None of it existed, so everyone built one-offs.
Consistency gapAI gave me Tailwind. The design system gave me Bootstrap. It wasn't a design problem. It was a system mismatch.
System mismatchASU UDS, before
Tailwind UDS, after
I tested before committing.
I read the docs, then prompted AI tools and generated real component code with MCP. The output was Tailwind every time.
In plain wordsA design system is a shared kit of parts (buttons, forms, colors) so every screen looks and works the same. Ours had to match the code that AI tools write, and those tools write Tailwind.
Lightweight by design
Unused CSS is removed before deploy. Only what's in the UI ships.
AI already speaks Tailwind
Copilot, ChatGPT, and Claude default to it. Matching it means AI code works right away.
One token, many classes
Define brand once and Tailwind generates every class around it.
brandbg-brandtext-fg-brandborder-brandring-brandbg-brand-softbg-brand-mediumbg-brand-stronghover:bg-brandChange one token, update everything.
Primitives hold raw values. Themes give them roles. Components only reference themes, so they adapt to light and dark mode.
In plain wordsA token is a named design decision, like "brand color = ASU maroon". Change it once, and every button, link, and border that uses it updates everywhere.
Components70+
bg-brandtext-whiterounded-basetext-baseTheme tokens164 · light + dark
bg-{color}text-{color}border-{color}text-{size}rounded-{size}Primitives353
Maroon 700 = #8C1D40spacing 36font sizes 11Familiar names on top, Tailwind underneath.
Tailwind is inline by default. I used SCSS @apply to group utilities into named classes like .btn and .form-input, so developers write btn btn-brand and the Tailwind engine runs quietly underneath.
.btn-brand { @apply bg-brand text-white rounded-base font-medium; }
Every variant, every state, documented.
Each component has flexible properties, variants, and states, plus usage notes and class names annotated right in Figma.
- Design tokens
- Semantic tokens like
bg-brandinstead of hard-coded values - Accessibility
- Keyboard navigation, focus indicators, screen-reader labels
I shipped it in AIX Framework, then sat with the developer to get it right.
Before writing a line, I asked him how the class names should feel. He knew Bootstrap, so we kept it simple: btn btn-brand, not long utility chains.
In plain wordsA color picked in Figma flows automatically into the code, so what designers draw is exactly what developers ship. No copying values by hand.
- Figma variables
maroon/700 #8C1D40 bg-brand → light: maroon/700 - designtokens.css
@theme { --color-maroon-700: #8c1d40; } - styles.scss
.btn-brand { @apply bg-brand text-white; } - Live component
<button class="btn btn-brand">✓ Works first time
Manual export → paste into CSS → verify → fix mismatches → repeat
Token in Figma → synced to CSS → developer uses the class → done
What shipped.
Primitive tokens: colors, spacing, type, borders
Theme tokens, light and dark
Components, annotated
Source of truth
Early token decisions compound
One bad primitive name breaks every component downstream. The structure has to be right from the start.
Clarity enables speed
Class names that match what developers and AI already use meant almost no adoption friction.
Go deeper: governance and what's nextHow the system stays organized, and what I'm automating now+
Every component tracked from idea to annotation.
I planned and tracked the system in Coda, so the team had one shared source of truth.
| Component | States and shades | Annotations | Notes |
|---|---|---|---|
| Colors | Done | Done | |
| Alerts | Done | Done | |
| Accordion | Done | Not started | Add multilevel accordion |
| Buttons | Done | In progress | |
| Cards | Done | Not started | Font updated to Neue Haas Grotesk |
| Chat bubble | Done | Not started |
Design-to-dev workflow
Every component followed the same path: definition, states, annotation, handoff.
Biweekly health checks
Regular reviews kept the system reliable and cut repeat cleanup.
Ownership and review
Clear owners and lock-in points before anything went to code.
The system is live. Now I'm automating what's still manual.
Storybook
60%An interactive code reference for every component, not just a Figma link.
Figma API + Claude Code + MCP
30%Read tokens straight from Figma and write them to designtokens.css, removing the manual export.
Design engineer role
80%Writing SCSS, pairing with developers on naming, reviewing Storybook, building the pipeline.
Most design systems stop at documentation. This one is building toward a world where the design file is the codebase.
iSTART Early
Game-based reading practice for young learners.
Your move.
Open to Product Designer roles anywhere in the US.
gaurav.inbox29@gmail.com