About me

Every messy problem has a hidden structure, a logic underneath the noise. Finding it, and building it into something that works, is what I have been doing for over a decade across design and product. But I have learned that the structure is never just technical. It lives in how people actually work, what they need, and what the business is really trying to achieve. My best work happens at the point where all three meet.

A mining client once asked me to fix congestion around a meal area. On paper it was a logistics problem. Spending time with the truck operators revealed the real issue: breaks were unequal, some drivers got less time than others, and everyone crowded in early to avoid losing out. I designed a staggered meal break logic that guaranteed every driver a minimum break while capping how long any truck sat idle. The congestion dissolved because the fairness problem was solved. Drivers stopped worrying about their breaks, and the business saw equipment park time drop significantly. The two goals were never actually in conflict; they just needed a structure where both could hold.

That instinct, going to the real activity rather than the stated request, has taken me to some unusual places. In the Philippines I worked pro bono alongside WHO, Google, and telco partners on typhoon disaster management. NGO responders needed to plan before, during, and after a typhoon: where people were, where they were moving, what their circumstances were. The telcos had the data; the data scientists knew what it could say; the responders knew what decisions had to be made. My role was to be the bridge. As design researcher and UX designer I ran workshops, ideation sessions, and usability tests to work out what decision-makers actually had to decide, then shaped concepts backward from that with the data science team. The solution reached millions of people and was later adapted for tsunami response in Indonesia. Structure that generalises to a different disaster in a different country is the strongest evidence that we found the real model underneath.

The same pattern carried me from design into product ownership. On an AI transformation for a mining client, I began with the research and future state journeys, then transitioned naturally into the product owner role, because I was the person who understood why each thing needed to be built. I ran prioritisation across three development squads spanning maintenance, procurement, and finance, with a client who wanted everything and resources that could not deliver everything. My approach was to quantify the real dollar impact of every candidate feature and prioritise against feasibility, so the hard choices became visible and shared rather than political. We delivered eight million dollars in measured impact across the three workstreams, and I stayed accountable through to user adoption, not just launch.

I will also argue for the harder path when the evidence supports it. On a change management programme for a manufacturer, the plan was a simple quiz app to educate the workforce. I benchmarked comparable efforts and made the case that a simple app would see low adoption and deliver no real impact, wasted effort dressed as progress. I proposed instead a gamified system that measured actual learning and engagement and rewarded people against it. The app became a genuine hit: high adoption, and tracked improvements in users' knowledge and success rates. The mechanism worked because the reward followed the thing that mattered, not just activity.

Across all of this, the constant is the same. People bring me situations they cannot quite articulate: a process that keeps breaking, a workforce that will not adopt, a flood of data nobody can act on. I go to the people inside the situation, find the system underneath it, and build that system into something real, working with whoever it takes, drivers, data scientists, executives, development squads. Thinking and making have always been one act for me, and the best structures are the ones a whole team can stand behind.