arcade design system
- role
- Design systems strategy, Systems architecture, Evangelism
- date
- 2022 – 2025
- team
- Design system, Product design, Client engineering
- my part
- I helped establish the design systems practice, defined the token architecture, and built tools to help platform teams understand and adopt it.
overview
Cash App already had design standards and strong platform teams. But each platform still translated those standards separately. Android, iOS, Web, Treehouse, and the rest each carried their own version of the design language. A design decision still had to be reinterpreted by hand before it reached product code.
I helped establish Arcade to move Cash App’s design language into code contracts that platform teams could trust.
ethos
I treated adoption as part of the system.
Earn trust without a mandate. Cash App had a grassroots engineering culture. Arcade had to become useful before it became expected. Engineers had to see that the system removed work without taking away control.
Put the system where decisions already happened. Arcade had to appear in code, Figma, platform packages, and review flows, not in a separate documentation site. Android and iOS leads were in the design loop from the start, so platform differences shaped the system before they became exceptions.
Make the designed path the default path. When the default path in code was the designed one, craft stopped depending on a reviewer catching drift later.
tokens
I defined the token model in three layers: base values, semantic intent, and component usage. Engineers could keep calling color-success even when the underlying green changed. That contract let design evolve without breaking every call site.
I built two explorers so teams could inspect the token graph without opening the pipeline or guessing through aliases. The explorers turned an abstract architecture into something designers and engineers could debug together.
the work
The source of truth lived in code. Every downstream target, including Figma, was a consumer. Tokens were authored in YAML, so linting and metadata lived with the source. Each platform had its own generator, isolated enough that one target could fail without breaking the rest. The outputs spoke local conventions: Kotlin and Gradle, Swift and SwiftPM, TypeScript and React, plus Treehouse, our internal server-driven UI framework.
That changed the level where design happened. When the Cash App button needed care, I sat in the implementation with the team until the radius, press state, and heart icon felt right. Code made the decision hard to undo by accident. When a discussion stalled, I built the smallest real version so the team could judge behavior instead of debate an abstraction.
what we built
We started where drift hurt most: high-traffic surfaces with repeated design decisions. Token infrastructure across more than seven theme variants. Generators for more than ten platform targets from one source. A Figma pipeline with bidirectional sync and automated PRs. Icon management that tracked thousands of changes without losing source history. Buildkite automation and @arcade/web as a published npm package.
I treated adoption as a design problem. As trust grew, contributors began extending the system instead of routing every decision back through me. My work shifted from writing most of the system to keeping it coherent.
what shipped
By late 2024, 145 flows had moved onto Arcade, covering about 85% of app traffic. By early 2025, coverage was around 95%.
I moved to org-wide AI work in early 2025. I still joined strategic calls, but Arcade no longer depended on me day to day. Design quality held because the default path worked.
95% of app traffic ran through Arcade-backed flows
what it enabled
Arcade’s point was the product. Cash App’s visual language evolved through it, from Money and learning surfaces to later AI work. Teams could ship new work that still felt like Cash App because the decisions were already in the system.