Design Systems · Telecom · 2021

Scale Engine

One coherent product language for 50M+ users — rebuilt from 14 disconnected team-level systems into unified design infrastructure.

Scroll to explore

← Drag or scroll →
01

Problem

14 Teams, 14 Languages

Consumer, business, and enterprise lines each built independent component conventions. Design time was consumed by solved problems.

34Distinct button implementations
02

System

Three-Tier Token Architecture

Primitive → semantic → component tokens. A single brand decision cascades through every product automatically.

340+UI elements catalogued in audit
03

Governance

Co-Authored, Not Mandated

Embedded contributors inside product teams. Adoption is the metric — not library completeness.

18Weeks to launch
04

Outcome

Unified Infrastructure

14 product teams on one system. WCAG 2.1 AA baked into foundations. Design velocity up 40%.

50M+End users impacted
Client
Verizon
Engagement
Design Systems Lead
Duration
18 Weeks
Primary Outcome
Unified Design Infrastructure
Stack / Tags
Tokens · Figma · React · WCAG

Artifacts from this engagement

Design Systems / Telecom

Scale
Engine.

Rebuilt Verizon's design infrastructure from 14 disconnected team-level systems into one coherent product language serving 50M+ users across consumer, business, and enterprise product lines. Not a component library — a living organizational capability.

0
Product Teams Unified
50M+
End Users Impacted
40%
Design Velocity Gain
2021
Year Completed
Client
Verizon
Role
Design Systems Lead
Timeline
18 Weeks
Outcome
Unified Design Infrastructure
03
Section 01
The
Problem.
What existed before the engagement — and why it could not scale.
14 Teams.
14 Design Languages.

Verizon's product organisation had scaled headcount faster than design infrastructure. Consumer, business, and enterprise product lines had each developed their own component conventions, design tokens, and interaction patterns. A button in the consumer billing flow had no relationship to a button in the enterprise dashboard. A team shipping a new feature would rebuild from scratch what three other teams had already solved.

The cost was not aesthetic inconsistency — it was operational drag. Design and engineering time was consumed by solved problems. The brief: build a shared infrastructure that teams actually adopt, that compounds over time, and that survives team attrition and leadership changes.

01
No shared token foundation — colour, spacing, and typography defined independently by each team. A single brand decision required 14 separate manual updates across products.
02
Duplicate component work at scale — internal audits found 34 distinct button implementations across products. Each solved the same interaction with different code, different behaviour, different accessibility support.
03
No adoption mechanism — previous design system attempts had been built, published, and ignored. Teams defaulted to their own conventions because the system had no governance, no evangelism, and no enforcement model.
04
Accessibility coverage was inconsistent — WCAG compliance varied wildly across products. High-visibility launches passed audits; background tools and business tier products did not. The brand carried liability it didn't know about.
04
Section 02
The
Process.
18 weeks. Five phases. One rule: adoption is the metric, not completeness.

Audit First.
Build Second.

No component was designed before the audit was complete. The existing landscape needed to be fully mapped before any architectural decision was made — or the system would solve the wrong problem with precision.

Key Insight · Week 3
The previous system failed not because it was poorly designed but because it was designed in isolation. The new system had to be co-authored by the teams who would use it — or it would be ignored by the teams who used it.
01
Component Audit
Weeks 1–3

Catalogued every unique component across 14 teams. 340+ unique UI elements identified. Mapped duplication, inconsistency, and accessibility gaps. Produced a prioritised consolidation matrix before a single design file was opened.

02
Token Architecture
Weeks 4–7

Designed the semantic token layer — primitive tokens beneath semantic tokens beneath component tokens. A three-tier system where a single primitive change cascades through every product automatically. Colour, spacing, radius, motion — all systematised.

03
Component Build with Teams
Weeks 8–13

Built core components alongside team designers — not for them. Embedded design system contributors inside product teams for 3-week rotations. Teams shaped the components they would ultimately adopt. The governance model was co-authored, not mandated.

04
Accessibility Pass
Weeks 14–15

Every component audited against WCAG 2.1 AA. Focus states, colour contrast, screen reader behaviour, keyboard navigation — all verified. Accessibility baked into the foundation rather than retrofitted as a compliance exercise.

05
Governance Launch
Weeks 16–18

Launched the contribution model — how teams propose, review, and ship new components. Established the design system guild: a cross-team body with clear ownership, versioning protocols, and deprecation standards. The system was designed to evolve, not to be complete.

05
Section 03
The
Solution.
Four architectural decisions that turned fragmentation into infrastructure.
01
01
Three-Tier Token System

Primitive → Semantic → Component. A brand colour change updates one primitive token and cascades through every product automatically. The first system where a global decision could be executed in minutes, not weeks.

02
02
Co-Authorship Model

Design system contributors embedded inside product teams for build sprints. Teams who helped build components adopt them without mandate. Ownership creates adoption. This was the adoption failure mode solved — not by policy but by process.

03
03
Accessibility-First Architecture

Every component spec included accessibility requirements before visual design. WCAG 2.1 AA as a minimum for all components. For the first time, accessibility compliance was structural — not a QA step applied after shipping.

04
04
Living Governance System

A design system guild with clear contribution, review, and versioning protocols. New components proposed by any team, reviewed by guild, released with semantic versioning. The system was designed to grow without central bottleneck.

Scale Engine · Token Architecture + Component Coverage
Primary
Primary-Dark
Accent
Surface-01
Surface-02
Surface-03
Consumer · Billing
Consumer · Plans
Business · Dashboard
Enterprise · Admin
Business · Self-Serve
Fig. 01 — Scale Engine token architecture + team adoption rates. All 14 teams above 75% adoption at 6-month mark.
06
Section 04
The
Outcome.
What changed — in velocity, consistency, and structural capability.
14
0
Teams Unified
Consumer, business, and enterprise product lines
40
0%
Design Velocity Gain
Feature delivery speed across all product teams
340
0→1
Component Consolidation
340+ unique elements reduced to a coherent library
100
0%
WCAG AA Coverage
Full accessibility compliance across all components
A brand-wide design change now takes hours, not weeks — the three-tier token cascade means a colour update propagates to 14 products simultaneously. No manual propagation, no missed components, no version drift.
New product teams onboard to the design system in 2 days, not 2 months — comprehensive documentation, embedded contributor model, and clear contribution paths mean new teams are productive from week one, not quarter two.
The system is still in active use — and still growing — 3 years post-delivery, the Scale Engine continues to expand. 40+ new components contributed by product teams. The co-authorship model created a self-sustaining system, not a maintenance dependency.
Accessibility liability eliminated across all consumer products — the shift from post-hoc compliance to structural accessibility removed a meaningful legal and reputational exposure at enterprise scale.
"

What Raghvendra built wasn't a design system. It was a design operating system. The Scale Engine didn't just unify our components — it changed how 14 different teams think about shared infrastructure. That mindset shift is the actual deliverable. The components were almost incidental.

VP Design Infrastructure
Verizon · 2021
07
Section 05
Key
Learnings.
What this engagement confirmed — and what it permanently changed about how design systems get built.
01
01
Adoption is the Product.

A design system that isn't adopted is a design artefact. The adoption model must be designed with the same rigour as the components. The Verizon engagement proved that co-authorship — embedding system contributors inside product teams — is the only reliable adoption mechanism at scale.

02
02
Tokens are the Foundation.

Teams who skip the token layer and build components directly create design systems that cannot scale. A three-tier semantic token architecture is non-negotiable for any system serving more than three product lines. The upfront investment compounds at every subsequent change.

03
03
Completeness is an Anti-Goal.

The previous system failed partly because it tried to be complete before launching. The Scale Engine launched at 60% coverage with a clear contribution model. Teams filled the remaining 40% over 6 months — and owned what they built. Coverage by ownership, not by central production.

04
04
Accessibility is Architecture.

Accessibility retrofitted is accessibility compromised. Building WCAG compliance into component specifications before visual design is the only approach that produces genuine coverage. At 50M+ users, partial accessibility is not a minor gap — it is a structural failure.

← Previous Case Study
Service Center
Transformation
Porsche · DesignOps · 15 Centers
Next Case Study →
AI
Blueprint
Rapipay · AI Strategy · 100M Users

Building a
Design System?

DesignOps 360 is the engagement model for organisations scaling past 5 product teams. Token architecture, component build, governance launch — 12 weeks, transparent pricing from ₹8L.

Initiate Inquiry ↗

Explore More
Work.

Nine more case studies across enterprise systems, AI strategy, design leadership, and product — all following the same structural logic applied here.

View Selected Work ↗