How I work
A few methods I come back to
Over the years I've built a handful of repeatable ways of working — for getting teams close to users, making decisions defensible, and giving designers the room to do their best work.
The way I lead comes down to a few convictions: get the team in front of real users, turn what they learn into clear decisions, and remove whatever gets in the way of good design work. Over time I've turned each of those into methods I can reuse.
The Design Jam
Rather than disappearing and returning with finished wireframes, I bring users and engineers into the design process together. The Design Jam is an abbreviated, focused design studio with a one-hour commitment: a brief framing of the problem, then independent sketching, then presenting and critiquing each other's ideas.
Putting users and engineers in the same room is deliberate — users bring domain expertise, engineers bring technical reality, and the combination produces ideas neither group would reach alone. It also helps adoption: when engineers have helped shape a solution, they're more invested in building it well.
A frequency-and-impact prioritization framework
Research surfaces more problems than any team can fix at once. To keep prioritization honest, I rate issues on two axes: how frequently they show up across participants, and how much they'd hurt the experience if left unresolved. High frequency plus high impact rises to the top.
The value isn't the scoring itself — it's that it gives product partners a defensible, shared basis for deciding what to fix first, instead of prioritizing by whoever argues loudest. It turns a subjective debate into a conversation everyone can follow.
Service models that let designers focus on design
Good design teams need clear ways of working — otherwise designers spend their energy negotiating scope and chasing intake instead of solving problems. I build that scaffolding so they don't have to.
Most recently I've been developing a complexity-scoring model that routes incoming design work by effort and impact, paired with a service catalog that sets clear expectations for how teams engage with design. I'm currently aligning that model with our enterprise Architecture and Product partners so design plugs into how the wider organization plans and prioritizes — not as a side function, but as part of the same system.
I don't do this work because process is the goal. I do it because the right scaffolding is what frees designers and researchers to do the work that actually matters.