I sit at the intersection that most design teams lack — someone who speaks design, understands ASIC and MiFID II well enough to have the regulatory conversation in the room, and knows what a UHNW client expects versus what a retail trader needs. That means engineering doesn't wait for legal to translate requirements. Legal doesn't get surprised by what design shipped. And the product actually works for the people on the other side of the screen.
Different businesses need different approaches. Fast fashion thrives on speed and social currency — and that's a valid strategy for the right market. But when I'm designing for a client whose users manage real capital, 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 UHNW wealth dashboard and a retail trading app serve different people with different expectations. I bring the domain depth to design for both — not by guessing, but by understanding their workflows, risk profiles, and regulatory context.
Build for What Comes Next
I design the hardest flow first — the one with regulatory constraints, edge cases, and real money at stake. Products that survive their first regulatory audit don't need to be rebuilt from scratch when the next one comes.
In the Room from Day One
I work alongside engineering, legal, and product from the start — not as a separate function that hands off specs, but as someone who understands enough of each discipline to keep the team aligned and moving.
Systems That Scale with the Business
Every problem I solve becomes a reusable pattern. When ACY faced 8 regulatory updates in 2 years, the design system absorbed them in days — not because I predicted each change, but because the architecture was built for change.
I don't design to impress other designers. I design to make the team ship better, the business grow more safely, and the users trust the product enough to come back.
