Problem first.
Everything else second.
What I'm here to do.
For the past several years I've been designing financial management products for local governments. Complex workflows, regulated environments, users who have real jobs to do and no patience for software that gets in the way. That context has a way of sharpening your instincts. You learn quickly what design is actually for, and what it costs when it doesn't work.
Where I do my best work.
I know where my best work happens. It's close to the problem, close to users, and in the middle of a cross-functional team that's actively trying to figure something out. That's the environment where good design decisions get made. Not in isolation, but in the middle of the conversation. I've learned to read a room, move it when it needs moving, and stay quiet when listening is the job. With AI changing how fast teams need to operate, the designers who thrive are the ones who can execute with real judgment and stay close to what actually matters.
How I approach the work.
Before any direction is set, there are things the team needs to agree on. What problem are we actually solving? Who's dealing with it, and in what context? What's the scope and what are the constraints? And how will we know if we got it right? Those aren't intake questions. They're the filter everything else runs through. I've seen projects go sideways not because the design was bad, but because the team never had a shared answer to those questions in the first place.
My process is built around getting to that shared understanding early, before the work gets expensive to change. That usually means facilitated sessions with product and engineering, users, and a lot of listening before a single sketch, pixel or line of code is created. The goal isn't to slow things down. It's to make sure we're moving fast in the right direction.