How I work
Not a methodology. A set of habits that have proven out across 20+ products and 7 industries — adjusted to what each problem actually needs.
The stated problem is rarely the real one.
Clients arrive with a fix in mind. I spend the first part of every engagement stress-testing the brief — talking to users, pulling usage data, mapping what's actually breaking. More often than not, the problem that needs solving isn't the one in the brief.
I verify in code before I go deep.
Before committing to a design direction, I build a quick working prototype with Claude Code and put it in front of real users. A clickable thing in a browser surfaces different reactions than a Figma file. It's faster to find out you're solving the wrong thing before you've invested weeks in solving it.
Analytics show what users do. Interviews show what they think. You need both.
I get PostHog running early. Watching real usage patterns in production — not just the users who volunteered for a test session — gives a completely different picture of where things are breaking. Interview data tells you the why; event data tells you the what and the how often.
Quick wins and proper fixes run in parallel.
I work with engineering and product to triage: what can ship in days and immediately improve the experience, versus what needs deeper work. Quick wins matter — not just for metrics, but because users noticing that things are getting better creates the trust and patience that deeper changes require.
I work alongside the team, not at them.
Designers who throw specs over a wall get implementations that drift from the intent. I stay involved through build — reviewing output, catching edge cases, adjusting in real time. When I can close the design-to-production gap myself, I do.