How I work
These aren't principles I follow from a framework. They're things I've learned — slowly, through projects that worked and ones that didn't. They shape how I start, how I push back, and how I know when something is done.
Problem framing
Before anything else, I try to understand what problem we're actually solving, for whom, what information we already have about it, and what success looks like if we get it right. The approach follows from those answers — not the other way around.
Skipping this step is the most common way to build the wrong thing well. It's also how teams end up solving a symptom instead of the root cause, and only realising it six months later.
"The quality of the work is proportional to the quality of the questions asked at the beginning."
Cross-functional collaboration
The moment I know a project is going to go well is when everyone in the room — business, engineering, data — shares the same objective and trusts each other's expertise. That moment doesn't just happen. Getting there is part of the job.
I've learned that when everyone feels ownership over the outcome, the day-to-day flows differently. People offer ideas outside their domain. Feedback lands better. And when things go wrong — they always do — there's a shared instinct to fix it rather than assign blame.
"Design doesn't happen in isolation. The best work I've been part of was built by people who trusted each other enough to say what they didn't know."
Systems thinking · Technical awareness
Digital products are made of software — and software behaves like a living material: interconnected, sometimes unpredictable, and always more delicate than it looks. Keeping that in mind changes how you propose solutions. Not everything that's possible is worth building, and some connections that seem invisible in a prototype can break something real when it ships.
I've learned to map the pieces before proposing anything — not because I need to understand how it's built technically, but because you can't design something scalable if you don't understand what's touching what. When you know the seams of the system, you make better decisions. And you sit more comfortably with the inevitable frustration of something that works in staging failing in production — because that's part of the craft.
"If you don't understand the material, you can't design for its limits. And in software, the limits are everywhere — including the ones you haven't seen yet."
Advocacy & negotiation
I always push to keep the user central. It's not optional for me — it's the thing I'll argue for in every meeting, with every stakeholder, at every stage of the process. But I've also learned that being right isn't enough if you can't bring people with you.
When I can't win the whole argument, I protect the minimum that keeps the experience honest. That's not compromise — that's knowing which battles matter and staying in the room to fight the next one. Dogma doesn't ship. Negotiated principles do.
"The user doesn't sit in the room. Someone has to make sure they're represented. That's what I'm there for."
Craft & perspective
Early in my career I thought design was the most important thing — and I fought for it like it was. Fifteen years later, I think the best thing that happened to my craft was learning to genuinely respect what engineering, data, and business see that I don't.
Understanding other points of view gives you better information to solve problems — and sharper instincts about which battles are worth fighting. Working across countries and cultures added another layer: mental models are not universal, assumptions are dangerous, and nothing should be taken for granted. The user in Mexico City and the user in Ankara both deserve to feel like the product was made for them.
"You stop thinking design is the most important thing. Then you become much better at it."
Want to see how these
principles look in practice?