Scaling Research Beyond the Product Team
A public playbook and a lightning talk for third-party MetaMask Snaps developers
Overview
Role: Senior UX Researcher
Team: MetaMask Snaps Product, DevRel, Marketing
Timeline: Q1 2024, culminating at ETH Denver
Product: MetaMask Snaps developer ecosystem
The Problem
MetaMask Snaps only succeeds if third-party developers build extensions people trust enough to install. Most of those developers have no research function of their own: no time, no budget, no researcher on staff.
My Approach
I built two artifacts from the same body of research, designed to work independently of each other.
The first was a one-page public guide, Snaps & User Research, condensing our findings into something a solo developer could act on in ten minutes: what research is (and the myths that keep people from doing it), when to run which method, and with key findings I discovered conducting internal research.
The second was a lightning talk at the Snaps Builder's Meetup during ETH Denver 2024, live to a room of the developers this research was actually about. I followed it with open 1:1 office hours for anyone who wanted to talk through their own Snap.
What Worked
The "myths vs. reality" framing lowered the barrier. Developers who'd never run a study stopped treating research as academic and started treating it as something they could do that afternoon.
Concrete findings beat abstractions. Naming specific install friction (CPU load, crashes, unclear onboarding) gave people something to fix.
Office hours turned a talk into a relationship.
What I Learned
Developers needed a different on-ramp than PMs or designers: less methodology depth, more "here's literally where to start."
The written guide had to stand entirely on its own. Most builders would never see the talk, so neither artifact could lean on the other for context.
Security kept surfacing as the real adoption blocker, ahead of usability. That reframed the guide's advice: the highest-leverage thing most builders could do wasn't a UI fix, it was making their credibility legible.
Why It Mattered
A single researcher can't sit in on every design decision. This project was a bet that research scales further as a capability other people can practice than as a service one person delivers. The guide and the talk were an attempt to hand that capability off.
