From Chaos to Clarity: How Velocity Design System Cut Enterprise POC Delivery Time by 60%

Role

UX Designer

Company

Virtusa

Timeline

Nov 2024 - Feb 2025

Team

2 designers, multiple developers, product owner, client partners

Collaborators

One other UX designer, the developers who built the POCs, practice leaders and client partners

Scope

Design systemComponent designDesign tokensDocumentation

Impact

60% faster POC delivery, from 3 to 4 weeks down to 1 to 2

40+ components across BFSI, healthcare, telecom and insurance

Tools

Figma
Figma variables
Stark
Atomic Design
WCAG 2.1
Agile

Overview: A starter kit that was holding us back

When our teams were spending weeks rebuilding the same components for every client demo, I knew we had a problem. Enterprise clients in the BFSI, healthcare, and telecom sectors expected polished POCs quickly, but our outdated starter kit was holding us back.

Working alongside another UX designer, I helped create the Velocity Design System: a comprehensive, scalable foundation that transformed how we deliver client projects. What started as solving internal inefficiencies became the backbone for faster, more consistent enterprise solutions.

System preview

The transformation was remarkable: from an outdated, inconsistent, and limited starter kit to a systematic design foundation that is adaptable, scalable, and consistently modern.

A quick walkthrough of the Velocity Design System.

The impact: Our new systematic approach enables teams to customize interfaces to any client's brand requirements while maintaining structural consistency. Components scale seamlessly across different enterprise contexts, and the entire system updates cohesively when design standards evolve.

What changed: Teams now work with a living system rather than static templates. Every component is purpose-built for enterprise needs, documented for easy implementation, and designed to adapt rather than break when client requirements change.

Challenge: Our tools were slowing every client POC

Our reality was frustrating, and the problems were clear:

Execution inefficiency: Every new client POC meant starting from scratch, with developers spending days recreating basic UI patterns.
Consistency breakdown: Components were visually inconsistent across projects, making our work look unprofessional and disjointed.
Scalability limitations: The existing starter kit could not adapt to different client branding or enterprise-scale requirements.
Documentation gaps: Sparse guidelines left teams guessing about implementation, leading to varied interpretations of the same component.
Maintenance nightmare: Updates to one project could not benefit others, creating a cycle of duplicated effort and divergent solutions.

The bigger picture: Enterprise clients needed rapid POCs to evaluate solutions, but our delivery timeline was suffering. Internal teams were duplicating work, and the lack of standardization made maintenance impossible.

Two Figma file structures side by side. Before: a scattered approach with a short, unordered list of pages. After: an atomic hierarchy with pages grouped into foundations and a long, named list of components such as avatars, badges, buttons, cards, modals and tables. — Before and after: how the Figma file was organised.

Research: What teams and clients told us

The research revelation. I started by talking to our internal teams: designers frustrated with inconsistent spacing, developers hunting for the right component variant, and project managers explaining delivery delays to clients. The pattern was clear: our design process was systematic, but our tools weren't.

What teams told us:

I spend more time looking for components than designing solutions.

Every project feels like we're reinventing the wheel.

Clients expect consistency we can't currently deliver.

Client feedback through practice leaders. Some enterprise clients had legacy systems desperately needing modernization, and others had no design standards at all. They needed partners who could deliver systematic solutions, not just custom designs.

Why we chose evolution over revolution. Through our research, we discovered our existing starter kit had valuable elements. Certain interaction patterns worked well, and some visual decisions had proven successful with clients. Rather than discarding everything, we identified three core problems to solve:

01
1. Execution problem
Teams could not deliver consistent quality quickly enough for enterprise sales cycles.
02
2. Adoption problem
Internal teams avoided the starter kit because it was harder than building from scratch.
03
3. Scalability problem
The system could not grow with client needs or adapt to different branding requirements.

Competitive analysis insights. We studied enterprise design systems like Google Material, IBM Carbon, and Atlassian to understand how successful teams structure systematic design. These systems showed us that consistency does not mean inflexibility: the best enterprise systems provide structure while enabling customization.

Research notes on sticky notes under the logos of Material Design, Carbon Design System and Atlassian Design. The notes read: documentation drives adoption more than design quality; systematic thinking beats beautiful components; consistency does not mean inflexibility; atomic thinking is the industry standard; start with tokens, build up to templates; variants over multiple components; accessibility built in, not bolted on; responsive by default. — What the competitive analysis taught us.

Approach: Why Atomic Design fit how we already thought

Rather than rebuilding from scratch, we needed a methodology that could systematize our existing design expertise while enabling enterprise-scale customization. After studying successful systems (inspired by Brad Frost's Atomic Design and analyzing Google Material, IBM Carbon, and Atlassian), Atomic Design emerged as the right framework.

The strategic insight. Our design team already thought systematically about components. Atomic Design would give us the structure to make that thinking scalable and enterprise-ready, enabling any client's brand to be expressed through our systematic foundation.

From internal system to client starter kit. We realized our atomic approach could become more than an internal efficiency tool. It could be a Design System Starter Kit customizable to any client's brand standards. That changes how we approach client relationships, from service providers to strategic partners offering systematic design foundations.

Why the starter kit approach works:

Accelerates product design with proven UI components based on enterprise patterns
Creates structured systems using atomic design principles that clients can understand and adopt
Ensures consistency across their designers and developers through a systematic methodology
Provides context of use through documented patterns and real-world implementation examples

Our atomic methodology:

Atoms: Universal design tokens (colors, typography, spacing, icons) that can express any brand.
Molecules: Functional components combining atoms: buttons, form fields, navigation items.
Organisms: Complex interface sections: headers, forms, content blocks.
Templates: Page structures demonstrating content relationships.
Pages: Final implementations with client branding.

Atomic design shown as five stages from left to right: atoms, molecules, organisms, templates and pages, each with a simple wireframe that grows from a single input field into a full page. — Atomic design, from atoms to pages. Image credit: Roopal Jasnani.

Decisions: Four choices that shaped the system

Atomic design over traditional component libraries. Rather than building isolated components, we structured everything systematically, from foundational tokens through complete page templates. This approach enables true scalability and consistent customization across different client contexts.

Two diagrams. The first shows the atomic hierarchy: atoms, molecules, organisms, templates and pages. The second shows the traditional component approach: header, side blocks, footer and text. — Atomic hierarchy compared with the traditional component approach.

Universal tokens over fixed brand elements. Instead of hard-coding visual decisions, we created flexible design tokens that could express any enterprise brand while maintaining systematic relationships. Color schemes, typography scales, and spacing systems could adapt without breaking component functionality.

Universal tokens, set up as Figma variables.

Modern design standards as foundation. We adopted Material Design principles and accessibility as our interaction foundation, so our components felt familiar to enterprise users while keeping the flexibility to express unique client branding through visual customization.

Accessibility checks at the atom level.

Two form components with the Stark contrast checker open on top. One dark-themed result shows a 14.63 to 1 ratio, the light-themed one 21 to 1, both passing AA and AAA. — The same check on a dark and a light form.

Material Icons for system-wide consistency. We standardized on Material's icon system rather than mixing styles, creating a universal visual language that clients could easily understand and extend with their own brand-specific icons when needed.

A grid of white Material icons on a dark background, each labelled: search, home, menu, close, settings, check circle, favorite, add, delete, arrow back, star, chevrons, logout, refresh, download, filter and more. — The icon set.

Usage: How teams use Velocity

For client POCs. Teams can now pull pre-built components and assemble functional prototypes in days rather than weeks. The system adapts to different branding requirements without breaking core interaction patterns.

For internal tools. Our own teams use Velocity for dashboards, admin interfaces, and internal applications. The consistency has improved our own product experience significantly.

The typical flow:

01
Designer selects components
02
Developer implements using documented specs
03
System handles responsive behavior and accessibility
04
Client receives a polished, consistent experience

Build: 40+ components, documented for developers

The system spans 40+ components organized into logical groups: navigation, data display, feedback, and input elements. Each component includes multiple states, responsive variants, and accessibility considerations.

Component documentation. Each component includes detailed specifications that make implementation intuitive for developers and adoption easy for other designers. The documentation covers usage guidelines, interaction states, responsive behavior, and integration examples, which removes the guesswork that used to cause inconsistencies.

Component specifications: anatomy and spacing.

Implementation standards. We kept documentation that bridges the designer and developer gap. Every component includes code snippets, spacing specifications, and behavioral guidelines that keep implementation consistent across projects and teams.

Spacing measurements on a navigation bar at two sizes, with the gaps between items marked as 24 and 233 pixels. — Systematic documentation: spacing values per size.

Component highlights. Data tables that handle enterprise-scale information, form patterns that reduce user error, and navigation systems that work across complex application hierarchies.

An overview of the Figma component library: form fields, colour scales, breadcrumbs, file upload states, navigation bars and a grid of alert variants in blue, green, red, yellow and cyan. — The component library, organised in Figma.

Reflection: What I learned, what I would change, and what is next

What's next for Velocity

The immediate roadmap focuses on advanced components: complex data visualization, workflow patterns, and mobile-specific optimizations for client field applications.

Storybook integration. We are planning to translate all components and their variants into Storybook, creating an interactive component library that developers can use for implementation and testing. It will be a living documentation system where teams can see components in action and understand every state and interaction.

We are also exploring automated testing for component consistency and building integration guides for the development frameworks our client teams prefer.

Longer term. The system could evolve into industry-specific variants (healthcare compliance patterns, financial data security components) based on client feedback and usage.

What this project taught me

Systems thinking: Systems thinking is as important as individual components. The most elegant button does not matter if it does not work within a larger ecosystem. Understanding how teams actually work, with their constraints, timelines, and frustrations, shaped better design decisions than aesthetic preferences did.
Documentation is design work: Clear usage guidelines and implementation notes are not afterthoughts. They are what make a design system usable. I learned to write for busy developers and stressed project managers, not just other designers.
Internal adoption: When our own teams embraced Velocity for internal projects, the quality and refinement improved rapidly. That internal validation made client presentations more confident and credible.

What we could have done better

Earlier stakeholder alignment: We could have involved practice leaders and client-facing teams earlier in the design process. Their insights about client expectations and common customization requests would have shaped better initial decisions.
A progressive rollout: Instead of launching the complete system at once, a phased approach starting with foundational elements might have enabled smoother adoption and earlier feedback.
Usage analytics from day one: Building in component usage tracking and feedback mechanisms from the start would have given us data on which components were most valuable and where teams struggled.
Cross-functional workshops: More structured collaboration sessions with developers during the design phase could have prevented some of the implementation challenges we met later.

Impact: Client POC delivery time fell by 60%

What I learned. Building for scale means making hard decisions about flexibility against consistency. The best system components are the ones teams do not have to think about. They just work.

I would love to hear your thoughts on this systematic approach to design systems. What challenges have you faced with design consistency at scale? How do you balance system flexibility with maintaining standards? If you would like to discuss design systems, enterprise UX challenges, or this project in more detail, get in touch.