Building the Design Organization

In 2017, Airtel Payments Bank was scaling digital financial products in a regulated, high-pressure environment. Product teams were moving fast, but design was not yet operating as a centralized strategic function. There was no mature design system, no regular research practice, and no formal design-review culture. Design work often arrived late, framed as execution.

The business needed product teams to ship faster and at higher quality, but the operating model produced avoidable rework. Inconsistent experiences, unclear handoffs, and uneven product quality slowed delivery and, in regulated financial products, put real pressure on customer trust and adoption.

The deeper challenge was not design quality. Design was treated as a service function. Product managers, under real pressure to ship, were used to bringing solutions rather than problems. Designers were used to completing tasks. Engineering received uneven handoffs. Leadership, in a sales- and telco-oriented culture, had not yet consistently seen design as a business capability.

Changing this was a trust problem before it was a process problem. Design maturity could not be installed; it had to be earned, gradually, across people who each had reasonable incentives for the status quo.

• A regulated banking environment with slow internal approvals.
• Legacy systems and constrained engineering bandwidth.
• Solution-first PM intake habits and low organizational design maturity.
• Hiring and budget constraints.
• Leadership skepticism from a sales/telco-oriented culture.
• Multiple product lines and constant business urgency.
• Low-literacy users requiring more explicit, trust-building experiences.
• Organizational politics and ownership tensions.

Nikhil built a regular field-research practice: monthly local-market visits and quarterly field visits across Indian states, focused mostly on Tier 2 and Tier 3 cities and sometimes rural areas. Over time, this practice grew into 50+ field studies across Tier 2, Tier 3, and occasional rural contexts, and the team published quarterly research reports for leadership and stakeholders.

Research moved product debate away from opinion-based pushback and toward evidence from real customer behavior, which is what eventually changed how decisions were argued.

The transformation rested on a small number of decisions made consistently over time, not on a single reorganization.

Every gain carried a cost. Building an internal organization required time, budget, and sustained leadership ownership. Moving design upstream raised the bar on the team: designers became accountable for business, data, and product strategy, not just for finished screens.

Reviews and signoff lifted quality but could feel like a brake on delivery. Asking PMs for problem briefs created early friction before it created partnership. And shared standards improved scale while feeling restrictive to designers who valued individual range. None of these were free. Each was a deliberate trade in service of a more reliable system.

Nikhil built the design operating model deliberately: structure, rituals, standards, and collaboration rather than chasing individual screens.

• Team: design capability scaled from 0→20, with 20 designers hired directly: visual designers, researchers, UX designers, and a UX copywriter.
• Structure: four pods, each with senior and junior designers, and four design leads reporting to Nikhil.
• Operating rhythm: Monday design reviews, 14-day product reviews, Friday critiques, weekly show-and-tell, sprint planning, design-dev sync, office hours, and weekly 1:1s.
• Growth: monthly three-hour upskilling sessions.
• Quality gate: design signoff at sprint end, before development handoff.
• Foundations: design-system governance (Vault) and quarterly research reports.

Nikhil led the shift, but the operating model only became real when designers, PMs, and engineering partners began using the same standards in live product work, not when a process was announced.

The outcome was not only a larger design team; it was a more reliable product operating system across regulated products that serve 12M+ monthly active users and 1B+ transactions since 2017, a foundation the wider product organization could build on.

• Design capability scaled from 0→20, with 20 designers hired directly.
• Design moved from scattered service execution to a strategic product function.
• Research became a recurring product input.
• Design reviews and critique created shared quality standards.
• Design-system governance improved consistency and handoff.
• Designers became more product-fluent, working in analytics and metrics language.
• Engineering handoff became more structured.
• Leadership began treating design as a business capability.

Later design-system and AI-assisted workflow maturity (Vault) contributed to an 85% reduction in QA time over two years. That outcome belongs to the AI-native Product Development story.

• Design maturity does not improve only because designers get better.
• It improves when the product system around design changes.
• Process adoption is emotional and political, not only rational.
• Introduce design maturity as leverage, not as correction.
• Artifact change is fast; operating-model change is slow.
• A Figma library can be built in weeks; design culture takes years.

Design transformation is not a Figma transformation. It is a trust transformation.

• Sequence the transformation more carefully.
• Start with a clearer design operating model.
• Create one or two visible business wins early.
• Upgrade the team's product thinking before expecting strategic partnership.
• Align leadership earlier, so PM and engineering adoption became easier.
• Avoid trying to improve too many systems in parallel.

• Design Operating Model
• Problem Brief over Solution Request
• Design Review / Critique Rituals
• Research-to-Decision Loop
• Design System Governance
• Design Signoff
• Trust Transformation Model
• Ambiguity to Outcome

Planned essays that will expand this story:

• Why case studies are too small for executive work
• Design transformation is not a Figma transformation
• How design earns executive trust
• Why PMs should bring problems, not solutions
• Design systems are product infrastructure

Operating Manual areas this story will connect to:

• Organization Design
• Hiring
• Design Reviews
• Product Reviews
• Research
• Design Systems
• Stakeholder Management
• Decision Making
• AI Workflow
• Career Ladders

Evidence areas tracked behind this story: organizational scale (0→20, with 20 designers hired directly), field research (50+ field studies and 500+ user interviews / research conversations), and product-delivery quality.

Ways this transformation can become reusable:

• LinkedIn post
• X thread
• Talk
• Workshop
• Operating Manual chapter
• Hiring rubric
• Design leadership course module
• Conference proposal