“Process is only useful if it serves people, not the other way around.”
—
People
Priorities
Process
“Process is only useful if it serves people, not the other way around.”
—
People
Priorities
Process
Process is only useful if it serves people, not the other way around. At its core, I think of design as choice architecture. Every decision shapes what people see, what they do, and how they feel. The frameworks I use exist to serve that belief, not the other way around.
I don't have a fixed methodology. I have a set of convictions about what good design process looks like, and I adapt from there depending on the team, the problem, and the constraints.
Start with Who, not What
Before any problem gets defined, any solution gets sketched, or any line of code gets written, the most important product question is: who are we actually designing for? Not a persona on a slide, but a real person with real constraints, real workflows, and real frustrations. I invest early in getting that answer with rigor, because every assumption made in its absence compounds downstream. The gap between what we think we know about users and what is actually true is where most design failures originate.
Prioritize ruthlessly
Not all problems are worth solving, and not all solutions are worth building. Before committing resources, I push teams to align on what matters most. A useful tool for that conversation is a simple risk matrix that maps design work against two variables: how well we understand the problem, and how much is at stake if we get it wrong.
Low clarity, high risk? Research heavy. High clarity, low risk? Move fast. The matrix doesn't make the decision, it makes the conversation honest.
Iterate with intent
I believe in MVPs, but not as an excuse to ship something half-formed. The goal is to learn fast, with the smallest investment that produces a meaningful signal. Every iteration should answer a specific question, not just add polish.
Lead people, not just projects
The best design process in the world fails without a team that's motivated, aligned, and psychologically safe enough to push back. In every 1:1, I start with the person, not the project. Understanding what someone is trying to grow into is as important as understanding what they're working on.
Know when to let go of the framework
The Double Diamond, Design Thinking, Jobs to Be Done. These are tools, not rules. I use them when they serve the work. When they don't, I set them aside. What matters is the outcome, not the methodology used to get there.