Anna

I start with people, not process. Before anything else I want to meet everyone — stakeholders, product owners, teammates — not as a formality but because how we work together matters as much as what we're working on. Misaligned expectations inside a team have a way of surfacing at the worst possible moment. I'd rather find them in week one.

From there I treat the brief as a hypothesis. Most problems look different once you've talked to users, looked at the market, and pressure-tested what's actually feasible. Reframing isn't a detour — it's usually the most valuable thing that happens on a project.

I ask a lot of questions early and stay curious throughout. What's already known? What does success actually look like to you — if this worked, what would be true? That last one is one of my favourite questions. The answer tells you everything about where a team really is.

The messy, undefined beginning is honestly the part I find most interesting. Once the problem is clear, the design tends to follow.

Research is always case-specific — the constraints, the client, the timeline all shape what's actually possible. What I do believe is that some is always better than none, and that talking to users, even briefly, changes how you see the problem in ways that secondary research rarely does.

I try to bring engineers in early. Not after the designs are done — early, when there's still room for their perspective to shape things. I've found that the designer-developer relationship either makes a project or quietly undermines it, and the difference is usually whether both sides feel like they're building something together. I make friends. It helps.

When I leave a project I try to leave more than screens. Design principles, job-to-be-done framing, the reasoning behind decisions. Someone is always going to inherit the work, and they'll face design decisions I won't be there to answer. A good set of principles means they don't have to guess.