How I work
No fixed sequence of workshop rituals. Just a few useful habits, applied with care.
I start with the situation people are in: their incentives, constraints, workarounds, and the things they cannot afford to get wrong. Watching someone do the work often teaches us more than asking what feature they want.
A shared problem statement, a map of the current experience, and the assumptions worth testing.
A prototype is a way to think together. Sometimes that means paper. Sometimes it means enough working code to explore real data, latency, or an interrupted task. I choose the fidelity that answers the question.
Competing directions, a clear rationale, and a prototype built around the riskiest assumption.
I define what we need to learn before choosing a method. I look for breakdowns in understanding, confidence, and behavior. A successful test can be the one that gives us a good reason to change course.
Specific observations, changes we can trace back to evidence, and a record of what remains uncertain.
Delivery includes the decisions that happen outside a design file. I work with engineering on implementation, make unresolved dependencies visible, and help the team decide when a smaller release, a pause, or a cancellation is the responsible choice.
A delivery decision, a record of unresolved dependencies, and a handover someone else can use.
Can people understand it? Does it help them do what matters? Can the team build and maintain it? Do we know enough to stand behind the result?