How I Work
My design process is ever-changing to match project constraints and the evolution of tools, but when possible, these are the beats I like to hit.
01 — Product Discovery
Every project starts with the problem, not the solution. Before anything else, I work in a triad with my PM and lead engineer to build a shared picture of the user needs, problem statement, and business context.
I use Claude to synthesize research inputs, pressure-test problem statements, and keep documentation current. The goal of discovery is a clear, shared problem statement the whole team has bought into before anyone starts building.
02 — Rapid Prototyping
I use Figma Make as my primary rapid prototyping tool, and have experimented with Google Stitch. These prototypes are intentionally rough, often stripped of branding, built to surface constraints and narrow scope before strategy gets locked.
This phase is particularly useful when scope boundaries aren’t immediately clear. The Disruption Hub case study shows this in practice.
03 — Explorations
Once scope is defined, I move into Figma for design explorations. Iteration happens fast and often. I review work in progress with my PM and lead engineer multiple times a week to catch misalignments early, while there’s still room to adjust.
04 — Design Review
At TripIt, design review happened at two layers: within the immediate agile team, and a weekly full-team review open to any PM or engineer across the organization. In practice, that room was regularly full of people with no formal obligation to be there. That didn’t happen by mandate. It happened because putting user needs at the center of every conversation gives people outside of design a reason to care, and over time, they showed up for it.
05 — Specs and Delivery
Spec work is collaborative by nature. I work closely with the lead engineer to document not just screens but logic: loading states, error states, validation rules, edge cases, and accessibility requirements. I use Cursor to help define and document interaction logic, and Notion MCP to keep specs and project documentation organized and current.
Once specs are delivered and the engineer is actively working tickets, I stay available. Logic questions that didn’t make it into specs, outlier cases that surface during build, additional documentation as needed. The work isn’t done when the file is handed over.
06 — Tracking and Iteration
Ideally every shipped feature gets measured and iterated on. What that looks like in practice depends heavily on the tools and access available. I’ve worked in environments where formal analytics tooling was limited, and learned to build feedback loops from whatever signal was available: customer support cadences, engagement reports, unmoderated research.
A note on process in practice
A full discovery process with dedicated research sprints and clean handoffs is an ideal. Most projects don’t live there. Knowing which parts of the process to compress without losing what matters is, in my experience, most of what the job actually is.