What I believe. How I work.
I believe the best product design is invisible on the surface and obsessive underneath. My job isn’t to make things pretty. It’s to move business metrics without compromising the people on the other side of the screen.
The path here was a steady widening of scope. At Mobcoder I designed what I was handed, screen by screen, for other people’s clients. At Vaipratech I owned end to end UX for B2C products and learned that consistency is a system problem rather than a discipline problem, so I started building reusable patterns. At SpeakX I owned four domains at once, activation, engagement, retention and monetisation, for a product serving 10M+ users, and built the company’s first design system. At Dalvoy I am the only designer, which means the problem definition is mine before the solution is.
The numbers I am proudest of are the boring ones. A checkout rebuilt around UPI that converted at ~3× the overall rate on its cohort. A design system built and governed from zero, so those decisions held their shape across every screen. A result page redesign that moved practice starts +19.5% and payment success +30.8%. None of those were visual redesigns. Each came from finding the moment a user was about to do the right thing, and removing whatever stood in the way.
I work with product and engineering from problem definition through to measuring what shipped. I write as much as I design: briefs, decision memos, teardowns after launch. The written artifact usually does more alignment work than the presentation does. I want to understand why a product should work before I decide how it should look.
Six things I've shipped my way into believing.
Constraints are the brief
The best design solutions live within hard limits, not around them. I'd rather design for the constraint than negotiate it away and ship something that doesn't survive contact with reality.
Write before you wireframe
A problem statement written well saves more time than any sprint. I won't open Figma until I can articulate the problem, the constraint, and the success metric in one paragraph.
Error states first
Happy paths are easy. The 1% edge cases, empty states, error recoveries, degraded experiences, are where real quality lives. I design those before I polish the hero screen.
Log what you defer
Every decision scoped out is a debt. I keep a decision memo on every project: not what we decided, but what we knowingly deferred and why. It's the single artifact that prevents scope creep in engineering.
Users lie. Behaviour doesn't.
I use user interviews to understand mental models, not to validate features. If what someone says doesn't match what they do in the funnel, I trust the funnel.
Ship to learn, then ship to scale
A feature in 5% rollout with a clear learning objective beats a fully polished v1 that takes three months to get to users. Speed of learning is a design skill.
Want to work together?
I'm looking for senior and lead roles where I own a surface end to end and am accountable for what it moves. Fastest way in is email.