Solving product logic
at the early, messy stage.
Product logic — the data model, the edge cases, what happens when someone says no.
I've been a Head of Design and a founder, and both taught me the same thing: the part of the job I protect is the weeds. Those days where your brain melts a little because you've gone through so many flows, sketched out so many stories, prompted so many use cases. So I've made it official — I'm an IC by choice, not by circumstance.
Running teams showed me where products actually get won: in the unglamorous logic underneath them, back when it's still cheap to change. Getting that right early is the highest-leverage work I know — and honestly, it's where I have the most fun. The seat I want is inside a squad, next to a PM and an engineering lead, arguing it out on a working prototype instead of a spec.
I've worked in teams across the UK and the Pakistani public and private sectors. In most of them I've owned that early stretch outright — running the research, drawing the first flows, and building the prototype everyone argues over before anyone writes production code. The leadership years didn't replace that work; they taught me how to make it land.
Experience
A hands-on IC role in practice — I build the prototypes myself, with one designer alongside me, de-risking core architecture through working prototypes before build. Also co-founded Kair alongside this role, leading the physical and digital design of air-quality focused products.
Shifted the design team from engineering-led delivery toward customer-led product design. A short-term engagement based in Lahore.
Taking the time to solve the right problem — including founding design work on Kickd.
Redesigned the application suite across mobile and desktop, and introduced a research-led prototyping flow that cut capture time.
Redesigned the fostering and SEN application processes, using prototyping to drive culture change in local government.
Redesigned internal money-movement logic for a major UK financial institution.
How I work
I push teams toward intentional logic and strip out whatever turns out to be clutter. Most of that work is just asking every question I can think of, however small — they all move the answer.
The part I'm best at is holding the micro and the macro at once: connecting pieces of a problem that look unrelated to everyone else in the room. It's why I like the early stages, when those connections are still cheap to act on.
The prototype is the meeting. One room, one working thing, edited live — not a spec each side reads differently.
The artefact belongs to the room. A prototype that stays mine reads as a verdict on everyone else's work. One the team can break and change gets claimed by them.
The prototype is the onboarding document. On a team that keeps turning over, the thing that runs carries the knowledge people take with them.
The logic stack is part of the speed. Lovable for flows and responsive behaviour, Figma for craft and quality, Claude for the specificity a static file can't carry — micro-interactions, notification logic, event taxonomy — and MCP to keep Supabase, Mixpanel and Sentry beside the work instead of behind a request. It exists to decide faster and unblock logic early: the argument happens on something running, in days.
Mentorship
When a team is misaligned it shows up in the product — and it's the youngest designers who get disheartened first. I know; I was one. So I stay close to the people around me: clear, actionable feedback, real ownership, and the confidence to bring me half-formed work without over-justifying it. Mentoring is the part of seniority I'd do unpaid — the words below are from designers I've worked with, and they say it better than I can.