Twelve designers. Zero shared system.
When I joined, I audited the product and talked to the design team. The findings were familiar: no design system, just a basic UI kit with components but no rules, tokens, or patterns. Every designer was solving the same problems differently — tables, filters, empty states, error states, all inconsistent across modules. The product looked stitched together, visual language and interaction patterns shifting as you moved between modules.
Why this mattered for the business
Three things were happening at once.
- Enterprise expansion was bottlenecked. Inconsistency reads as immaturity. The further up-market we went, the more the cracks showed.
- Design and engineering time was being burned. Designers duplicated effort with no shared library; engineers rebuilt components that already existed under different names.
- The product wasn't AI-ready. A basic UI kit doesn't give an AI enough context to produce reliable output — without tokens, components, props, and documentation, AI could only guess.
A design system wasn't a nice-to-have — it was the prerequisite for the next phase of the company.
A framework, not a dogma.
I used Farid Sabitov's Design System Maturity Model as a framework, but didn't try to chase a specific level. Instead, I picked the characteristics that mattered for Sprinto and made them the roadmap — a complete token architecture, a scalable component library, a pattern library to solve UX problems at the system level, Figma-to-code parity, accessibility built in, documentation and contribution guidelines, and AI-readiness.
UI kit
A single file to reference — basic visual alignment.
- Styles
- Components
Design Library
Processes form around the library — a team starts maintaining it.
- Usage Analytics
- Governance Practices
- Design Language
- Usage Guidelines
- Pattern Library
Design System
Design, code, and other disciplines are connected into one system.
- Dedicated DS team
- Product Adoption Tracking
- Accessibility Built-in
- Regular Office Hours
- Built-in Content Strategy
- Design Tokens
- Component Status Page
- Component Management
- Shared Vocabulary
- Motion Guidelines
- Research Insights
- Release Notes
Scaled Design System
Usage across multiple products and platforms.
- Multi-product Support
- Deviations Management
- Usage Examples Bank
- Release Management
- Dependency Management
- Living Roadmap
- Internal GTM Strategy
- Branching Strategy
- Design System Champions
- Advanced Theming
- Localization Capabilities
- Contribution Model
- Automated Tests & CI/CD
- Visual Regression Testing
- Linters
Public Design System
Industry-leading innovation & influence.
- Product/Domain specific Design Systems
- Public Roadmap
- Versioned Documentation
- External Contributions
- Org-wide adoption metrics
- Advanced Enablement
- Multi-platform support
- Community Engagement
- Dedicated Support
- Open-source
- Custom Tools
- Dynamic Personalization
- Public Research Studies
- Community Resources
- Certification Programs
- Internal SSO Access
- MCP servers
- DS Assistants
- Third-party Integrations
This gave us a prioritized picture of what NeoGrid needed to be, without inheriting maturity-model dogma that didn't apply to our context.
Five principles guided every decision.
These shaped every component, pattern, and governance choice that followed.
The system is the source of truth
If a designer reaches outside NeoGrid for a one-off solution, that's a signal the system has a gap to fill — not a signal to allow exceptions.
Solve at the system level, not the screen level
Components solve visual consistency. Patterns solve UX consistency. We invested heavily in both.
Flexibility without fragmentation
Slots, multiple sizes, and clear extension points gave designers room to compose without breaking the system.
One language across design and code
The previous UI kit failed because Figma and the codebase had drifted apart. NeoGrid speaks one vocabulary — same names, same props, same defaults.
Built to be used by anyone, including AI
Structuring NeoGrid for AI-readiness turned out to be the same work as making it good for the team.
Tokens up. Patterns, not just components.
The bigger shift wasn't the component count — it was how we approached the whole stack, from the foundation to the problems designers kept solving differently.
Tokens
We started at the foundation: a complete token architecture covering colors, typography, spacing, radius, and shadows. This unlocked theming — light/dark and customer-specific theming without rewrites — and consistency, with every component referencing the same source of truth. We refactored typography to size and weight only, no decorative styles, just clarity and hierarchy.
One naming decision mattered more than it looked: accent-green, not accent-success.
accent-green#16A34A- Success
- Revenue +
- Active
accent-red#DC2626- Error
- Revenue −
- Overdue
accent-yellow#D9A400- Warning
- Pending
- At risk
accent-blue#2563EB- Info
- In progress
- Link
Semantic names read as more helpful — until the meaning they encode needs to change. The same three moments play out very differently depending on how the token was named.
accent-successmost design systemsaccent-greenNeoGridGreen also means “revenue +” and “active” — but the name only says “success.”
One token; each component decides what its green means.
Rework the color-to-intent mapping for every theme.
Redefine what each color resolves to. Nothing else changes.
Hunt down every alias that resolved to the old green.
Change one value; everything updates.
- Theming without rewrites
- Meaning lives in components
- Values change; names never lie
Tokens describe what something is. Components decide what something means. Conflate the two, and the system fights you every time the product evolves.
Components — 60+ from the ground up
Slots let designers compose modal headers, table cells, popovers, and accordion bodies without detaching instances, with suggested components educating the team on what should and shouldn't go in each slot. Props got simpler and names more consistent, dev-ready. Avatars, tags, and inputs supported multiple sizes, from compact to expressive, without breaking the system. And components got smarter — date pickers gained month/year range selection, popovers got an "Ask AI" variant, accordions and tags were rethought for richer content control.
For direction on structure and conventions, I looked at Atlassian Design System, Razorpay Blade, GitHub Primer, and IBM Carbon — then built NeoGrid around what Sprinto's product actually needed, not a copy of any one of them.
Patterns — solving UX problems system-wide
This is the part most design systems skip, and the part I'm most proud of. We codified patterns for problems designers kept solving differently: tables (row selection, hover-revealed actions, adjustable column widths, saved views inside the table itself), filters (one unified toolbar pattern across every data table), search (one canonical behavior everywhere), navigation (page headers with breadcrumbs, entities opening as full pages instead of drawers), and confirmations (when destructive actions need them, and when they don't). By solving these at the system level, designers stopped reinventing them.
Tables
- Row selection
- Hover-revealed actions
- Adjustable column widths
- Saved views inside the table
Filters
- One unified toolbar
- Consistent across every data table
Search
- One canonical behavior
- The same everywhere it appears
Navigation
- Page headers with breadcrumbs
- Entities open as full pages, not drawers
Confirmations
- When destructive actions need them
- And, deliberately, when they don't
Figma–code parity & accessibility
We refactored prop structures to align across Figma and code — same names, same variants, same defaults. This single decision dramatically reduced handoff friction. Accessibility — focus states, color contrast, ARIA patterns, keyboard interactions — was baked into the components themselves. Designers got it for free.
Everyone a contributor. One maintainer.
If only one or two people could contribute, the system would stall the moment we got busy. I owned the maintainer role — final say on what entered the system — while every designer could propose, branch, and contribute changes. Branches in Figma, DS Owner review, Jira tickets for trackability: safe conflict-free edits, clear ownership, a trackable history like a code repo. It turned NeoGrid into a shared responsibility rather than a top-down mandate.
ArtifactThe full “Contribute to NeoGrid” guide+
A test of governance: the AI components decision
Partway through, Sprinto's strategy evolved. The AI pod started asking us for AI-specific components.
Absorb everything into NeoGrid
"Of course, NeoGrid will own AI components too." That's the standard design-system playbook — one source of truth, all components live there.
Let the AI pod own it, separately, for now
AI components were brand new, with heavy iteration and breaking changes ahead. Same conventions and naming, but separate — with a future merge path engineered in from the start.
The instinct in design system work is to absorb everything. But a system that absorbs unstable surface area becomes unstable itself. Knowing when not to absorb something is part of governance, too.
A design system nobody uses is a parallel system.
We didn't want NeoGrid to be optional. Two migrations mattered: moving 146 components' worth of old-UI-kit instances onto NeoGrid, and — the strategic one — extracting NeoGrid out of the main Sprinto app repo entirely, so other Sprinto products and AI tools could use it independently. We hired a contract engineer specifically for migration so the rest of engineering could stay focused on product features. High-traffic flows migrated first; long-tail edge cases migrated last.
tracked
migrated
migrated (93.8%)
reusable everywhere
Adoption was high. Friction was real.
Designers were eager, but friction showed up in three places we had to actively manage.
- "When should I use this?" The most common DS Slack question wasn't pushback — it was designers genuinely trying to do the right thing. Every question got treated as a signal of where documentation needed to be better.
- "I need a new component for this." About half the time, the case was real. The other half, the existing system could solve it with composition — so instead of just saying no, we walked through how, and turned the answer into a usage example.
- Breaking changes during major releases. The hardest one. Shipping v2 of a component sometimes broke pod designers' v1 Figma files — props missing, layouts off. The fix: changelogs that communicated impact, not just changes — what changed, why, what it could break, what action was needed.
Most adoption friction in design systems isn't about the system itself — it's about the coordination around it. Releases are a coordination event, and we hadn't been treating them like one.
This is the part that surprised even us.
Sprinto has an internal AI tool, Kaizen, built on top of Claude. For a long time, Kaizen wasn't great at producing usable UI — it lacked the context to know what components to use, what props to pass, what patterns to follow. Once NeoGrid was independent and structured with proper components, patterns, and examples, that changed. Kaizen could generate production-ready component changes, using the right components, the right tokens, the right patterns. The AI had finally been given a real grammar to write in.
- Designers became builders — spec a flow in Figma, hand it to Kaizen, ship a working implementation. No engineer in the middle for small changes.
- PMs became builders — prototyping real flows in code, not slides.
- Engineering bottlenecks dropped — "wait for an engineer" on small UI fixes shrank dramatically.
- Iteration cycles tightened — a 3-day design → review → engineer → review loop became a 3-hour loop.
NeoGrid wasn't just a design system. It became the foundation of how Sprinto ships product.
What changed, after eight months.
on NeoGrid
pattern library
97.6% migrated
source of truth
reusable across products
production-ready UI
Beyond the numbers, the most visible impact is in the product itself. Tables behave the same way. Filters work the same way. Navigation feels unified. The micro-surprises that erode trust have become noticeably rarer. Sprinto stopped feeling like multiple products stitched together. It started feeling like one.
What I'd do differently.
None of these changed the outcome. All of them would have made getting there cheaper.
Lock token naming conventions before the first component ships
The reasoning behind color-named tokens held up, but I'd document the convention itself on day one. The migration would have been smoother with a stable naming convention from the start — it's far easier to set a convention on a blank slate than to retrofit one under a live product.
Build the contribution workflow before the first component, not after
Governance is easier to establish when there's nothing yet to protect. Retrofitting branching, review, and changelogs onto a system that already had momentum created friction that didn't need to exist.
Start the independent-package conversation earlier
Running the UI-kit migration and the monorepo extraction as two separate streams was the right call. But raising the independent-package question sooner would have folded some of that work into the first migration instead of requiring a second pass. Architecture decisions have a cost that compounds the longer they're deferred.
Trust first-principles thinking over waiting for tooling
The slot architecture was a bet we made before Figma shipped native slots as a feature. By the time Figma caught up, we'd already built the mental model and the implementation. That bet paid off — a reminder not to wait on tooling to validate a direction that already made sense.
Stable. Not finished.
The foundation is laid. The next phase is about depth, reach, and intelligence.
Theming
Multi-brand and white-label support. The color-named token architecture was built with this in mind from the start — a theme swaps what a token resolves to, nothing else has to change.
Accessibility
A systematic WCAG audit across all 60+ components. Not just compliance — genuinely accessible interaction patterns, not retrofits.
Usage analytics
Instrumenting which components actually get used, which get ignored, and where the system still has gaps — so the roadmap is driven by real usage data, not just requests.
Deeper AI
Expanding what Kaizen can do with NeoGrid — from generating changes within existing components to proposing new ones that follow the system's own conventions.