Design systems aren’t a design problem — they’re an adoption problem.

At Gojek, I worked on solving both.

When people think about product design, they usually imagine working within a product team — clear scope, defined problems, and a full squad to execute.

Design systems don’t work like that.

When I worked on the Asphalt Design System (ADLS) for the Gojek app, the challenge wasn’t just designing components. It was building a product — and convincing an entire organization to use it.

Redefining End-to-End

On product teams, end-to-end means taking a feature from idea to launch. In a design system, end-to-end means something broader.

There’s no predefined problem. No guaranteed users. I had to:

• Identify gaps across teams
• Design and build scalable solutions
• Document and distribute them clearly
• Drive adoption across products
• Measure usage and impact
• Continuously evolve the system

In practice, it was 40% design & execution , 70% influence & negotiation.

The System at Scale

ADLS supports the Gojek app across 20+ teams, becoming a shared foundation for design and engineering.

• 62 master components across platforms
  • Android (View-based & Jetpack Compose)
  • iOS (UIKit & SwiftUI)
• Design tokens Color, Typography, Spacing, Radius, Shadow
• 4 themes
• 77K+ insertions, embedded in real product workflows
• Ecosystem of tools: Figma libraries, documentation (Lark), lint plugin, and internal tooling

The Real Challenge: Adoption

The hardest part wasn’t building the system. It was getting teams to trust it, use it, and rely on it.

Design systems don’t get adoption for free — they have to be introduced, explained, and often sold internally. I drove adoption through:

• Workshops to onboard teams
• Robust documentation for self-serve usage
• Direct collaboration with product teams
• Design System Reviews before engineering handoff
• Continuous support across teams

Sometimes we built first and waited for usage. Other times, teams created solutions first — and we absorbed them into the system. It was a constant push and pull between system and reality.

Navigating Real-World Complexity

Scaling a design system is never just about building components — it’s about balancing ideals with real-world constraints.

• Constant org and business changes
• New designers with different learning curves
• Inconsistent approaches across teams
• Tokens are scaling faster than components
• Tension between governance and flexibility

A key constraint: There was a dedicated engineering stream — but with different priorities across teams. Bandwidth wasn’t always guaranteed. Work required coordination, alignment, and prioritization.

This pushed the work beyond design — into influence, timing, and trade-offs.

Because in reality, the system isn’t defined by what we build —but by how we navigate what lies beneath the surface.

Impact

• Reduced design and development time for new screens
• Improved accessibility compliance
• Increased adoption across multiple products
• Fewer UI inconsistencies
• Better designer–engineer handoff

More importantly, it shifted teams from isolated solutions to a shared system mindset.

What This Taught Me

Design systems are not just about components or tokens. They are about driving behavior change at scale.

This work pushed me beyond execution into:

• System thinking
• Cross-team alignment
• Product ownership
• Internal advocacy

Because in the end: Building a design system is easy. Getting people to adopt it — like selling a product internally — is the real work.