Methodology
How I work
Five steps from diagnosis to shipping.
With hypothesis-driven design and SUM benchmarking as named methods, plus what twenty years has taught me about workshops that end in commitments.
A note on paper, before the methods
Every project I’ve shipped started on paper.
There’s something magical about scratching a pen on a page and drawing letters that helps me unblur what’s about to be created and connect with the matter more profoundly than I can on a screen. Twenty years in and the first hour of any project is still pen on paper: the questions I want answered, the people I think I’m designing for, the shape of the thing I’m about to build. The screen comes second.
I mention it because the rest of this page is about methods and tools, and methods without that earlier private thinking step are just frameworks dressed up as work.
01 · Step
Diagnose the business and the product system
Before the pixels, the question is what behaviour matters. I spend the first month of every engagement listening (to the CEO, to engineering, to support tickets, to users when I can get them) and writing down what I hear in plain language. By week four I usually have a one-page diagnosis.
The output isn’t a recommendation deck. It’s a shared map. A team that agrees on the diagnosis can disagree productively about the solution.
This is also where I work out what not to do. That part comes from two places: deep solitary thinking of my own, often on paper, and pressure-testing with the team. Subtracting scope is harder than adding it; most teams I’ve joined had a roadmap full of things nobody could honestly say belonged.
In practiceGVC cashier rebuild02 · Step
Shape the smallest thing that teaches us something
Big bets are cheaper when the first iteration earns the right to the next one. I treat each early build as a deliberate test of an assumption, not a delivery.
The four-line shape matters because it forces a commitment. “We believe X” is harder to wriggle out of than “we should think about X.” When the bet fails, the four lines are also the cleanest post-mortem you can run: which line was wrong?
In practiceHypothesis-driven design03 · Step
Design the system, not just the screen
Loops, incentives, pricing, community, data: the screen is the visible end of the system. If the system is broken, no amount of pixel craft will fix the product. If the system is right, even a rough screen can carry the experience.
This is also where I push back hardest when a stakeholder asks for a “redesign.” Often the screen is fine. The system around it isn’t.
In practiceSellerCrowd04 · Step
Prototype fast with AI
Claude Code, prompt specs, eval loops. Shipping has become a new way of thinking. The cost of finding out whether an idea is good has collapsed.
Prototyping is no longer a separate phase reserved for the things engineering can afford to spike. “What if it looked like this?” is now answered in twenty minutes, not three sprints.
What it doesn’t change: the judgment about which prototype to build. That’s still the senior IC’s job. Models are fast and literal; they need someone in the room who knows what the team is actually trying to learn.
In practiceBuilding in 202605 · Step
Ship, measure, adjust
The work isn’t finished when it’s pretty. It’s finished when the numbers move.
SUM is one tool inside a broader habit: ship the thing, watch the metric, and be willing to revert. The version I’m proudest of is rarely the version I drew first.
In practiceSUM, the single usability metricA note on workshops
The point of the workshop, every time, is to end with commitments.
Not with vague alignment, not with a nice deck, not with a “we should follow up on this.” I almost never run a Sprint by the book: the right workshop is the one I custom-craft for the team in the room, using Gamestorming’s recipes as building blocks.
The single most useful facilitation move I know is voice-leveling: giving everyone equal time to speak, and controlling the loud voices so the quieter ones share their thinking first.
All three produced commitments the team kept.