METAMASK DESIGN SYSTEM

MetaMask is the world’s most-used crypto wallet, with 30M+ monthly active users across the browser extension, Portfolio, and mobile on iOS and Android. Three surfaces, three codebases, one brand that had to feel like a single product on all of them.

I joined the design system team to build the layer everything else sits on: the component primitives, the tokens beneath them, and the documentation that told every other engineer how to use them. The architecture was already set and had a strong owner. My job was to build inside it, not to redraw it.

I shipped 101 merged pull requests into the MetaMask extension and 3 into the shared design system package. Almost all of it was the bottom of the stack, the components nobody demos but everything depends on.

• The button family. ButtonBase, then Primary, Secondary, Link, and Icon on top of it, plus the size, ellipsis, and href behavior that every one of them inherited.
• Text and Box. The typography component and the layout primitive, including responsive width and height sizes and the text-direction support the internationalized builds needed.
• The icon system. Auto-sizing, a full audit that retired unused sizes, and a naming pass so icons could be found rather than guessed at.
• The banner family. BannerBase, then severity variants, BannerAlert, and BannerTip, for the wallet’s warning and confirmation surfaces.
• AvatarIcon and HeaderBase, plus the Storybook MDX docs and stories that shipped with each component.

Public record: metamask-extension and metamask-design-system.

The system had an owner. I built to the standard, not around it.

The design system had a lead with a specific and exacting point of view, and every component went through his review before it merged. That meant a lot of iteration on things that never showed up in a release note: prop naming, default elements, how a component collapsed at a breakpoint, whether a variant should exist at all.

A meaningful share of my pull requests were explicitly housekeeping, going back through Button, ButtonBase, ButtonLink, ButtonIcon, and Text to bring their APIs into alignment after the fact. That work is invisible from the outside and it is the reason a system stays usable at the third year instead of the first.

It also taught me the thing I would not have learned owning a system alone: how to ship inside a strong opinion I did not set. Most design system roles are exactly this. You inherit decisions, you argue the ones worth arguing, and you execute the rest well.

Components landed in the extension first, then moved outward as the shared package picked them up. Adoption was not a mandate, it was a migration: teams upgraded the package, inherited the new primitives, and fixed the small breaks that came with them.

The public record is the honest measure here, and it is all still open: 101 merged pull requests in metamask-extension and 3 in metamask-design-system, spanning the button family, Text, Box, the icon set, the banner family, AvatarIcon, and HeaderBase, each with its Storybook entry.

Every component shipped with Storybook MDX documentation and usage guidance, because a component nobody can find gets rebuilt from scratch three directories over. I worked on the CI path too: Jest, end-to-end tests, and Lighthouse checks in the pipeline so regressions and accessibility failures were caught before merge rather than after release.

TypeScript-first throughout, with semantic HTML and modern CSS underneath. When the codebase moved to TypeScript I went back and repaired the stories and readmes the migration broke.