The most valuable thing I do is reduce translation loss between design, legal, and engineering. Legal speaks in regulation numbers. Engineers speak in components. Traders speak in risk exposure. I speak all three — which means each group stops making expensive assumptions about the others.
Different financial products need different design approaches. A retail trading app optimises for speed and simplicity — and that's valid. But when I'm designing for institutional clients managing real capital, or for platforms where a single UI error could trigger a regulatory violation, the priority shifts: stability over novelty, trust over conversion tricks, and solutions tailored to each user's risk tolerance rather than one template for everyone.
The best teams I've worked with don't treat design as decoration or compliance as a checkbox. They treat them as the same conversation — what does the user need, what does the business require, and how do we ship something that satisfies both without cutting corners? That's where I add the most value.
Right Solution for the Right Client
A wealth management dashboard and a retail trading app serve completely different people. I've designed for both — and the difference isn't just visual. It's understanding how each group actually works, what risks they care about, and what rules apply to them.
Build for What Comes Next
I start with the hardest flow — the one with regulatory requirements, edge cases, and real money on the line. If you get that right first, the product won't need to be rebuilt when the next audit or regulation change comes along.
In the Room from Day One
I join engineering standups, understand how they structure components, and adjust design specs so they make sense from a build perspective. When Legal flagged a copy-trading feature as "financial advice" under ASIC rules, I created a Legal-First Checklist so that never happens again. When the CFO needed to review investor deck charts, I onboarded him into Figma so he could annotate discrepancies directly instead of describing them over email. The pattern is the same: I learn enough of each person's world to remove friction, not add to it.
Systems That Scale with the Business
Every problem I solve becomes a reusable pattern. When a platform faces regulatory updates, a well-architected system absorbs them in days — not because you predicted each change, but because you built for adaptation from the start.
I'm not trying to impress other designers. I want the team to ship better, the business to grow safely, and the users to trust the product enough to keep using it.
