Writing
Method, observation, and the occasional argument.
These essays document how the work gets done: the methods that hold up under pressure, the constraints that shape every decision, and the moments where a project changes direction.
-
What affinity mapping actually reveals
An affinity map is not a finding. It is the substrate from which findings have to be extracted, and that extraction step is where most teams stop too early.
-
The brief that arrives pre-solved
The most dangerous brief is not the vague one. It is the one that arrives with a solution already written into it, presented as a problem to be confirmed.
-
Facilitation is not the same as participation
Running a Design Sprint remotely produced a lesson I had not anticipated: presence in a room and presence in a process are entirely different conditions.
-
When research findings get ignored
The research was thorough, the report was clear, and the recommendation was ignored. Understanding why that happens is more important than preventing it.
-
How to run a stakeholder interview that produces something useful
Most stakeholder interviews produce a list of preferences and constraints. That is not the same as understanding. The difference is in the structure of the questions.
-
The problem with personas
Personas are useful for building empathy in rooms that have none. They become harmful when they replace the actual users they were built to represent.
-
Why designers should own the sprint retrospective
The retrospective is the only moment in the sprint cycle where the team reflects on process rather than output. Designers have the most to gain from that conversation.
-
Why discovery takes longer than anyone budgets for
Every project brief underestimates the discovery phase. This is not a planning failure. It is a structural feature of working with problems that have not been properly framed before you arrive.
-
On hiring for craft versus hiring for fit
Hiring decisions in design teams often collapse the question of craft into the question of fit. They are related but they are not the same thing.
-
The difference between a prototype and a proof of concept
A prototype tests an experience. A proof of concept tests a feasibility assumption. Using the wrong one for the wrong question produces decisions made on bad evidence.