I figure out what to build. Then I build it.
I'm a product designer who works end-to-end — from the first conversation about what the product should do, through the information architecture and interaction model, to the final interface people actually use.
The work I'm most drawn to has real constraints: limited budgets, unfamiliar markets, infrastructure that pushes back. Those projects force better decisions. My two current case studies — a supermarket deal aggregator and a museum ticketing redesign — both came from noticing broken experiences in Nairobi and deciding to fix them with design.
What I do
The upstream work and the interface that follows
I make product-level calls — what to build, what to cut, how the system should behave — and then design the screens that make those decisions tangible. I don't hand off wireframes and walk away. I care about the spacing, the transitions, the way a loading state feels at 250ms.
I can also write frontend code. Not as a novelty — because closing the gap between the Figma file and what ships means fewer things get lost in translation.
How I work
Process
Find the actual problem
Most briefs describe a symptom. Before I sketch anything, I need to know if the problem is in the UI, the data, the business model, or the policy layer. Getting this wrong means designing the right solution for the wrong problem.
Name the constraints
What devices do users actually have? What's the data budget? What can engineering ship this quarter? I write these down explicitly. They're not obstacles — they're the brief.
Make the hard calls first
Which information goes first? What gets cut? What's the one thing each screen has to do? I make these decisions before opening Figma, because the interface should follow from them — not the other way around.
Ship, measure, be honest
I push for testable work early. If the numbers don't move, I write down why and change the approach. The reflection matters as much as the output.
Tools
What I use
How I collaborate
Remote is how I work, not something I tolerate
I've worked in distributed setups my entire design career. I have specific habits that make this reliable regardless of where the rest of the team sits.
Written-first
Every design decision lives in Notion or Figma. If it's not written down, it didn't happen.
Loom over meetings
I record design walkthroughs instead of scheduling 30-minute calls. Teammates review on their time.
Structured overlap
Syncs and pairing happen during shared hours. Deep work happens outside them.
Visible progress
Weekly design updates in Slack. Nobody should need to ask "where are we on this?".
Let's talk
I'm looking for product design roles where the decisions carry weight — where I can own the problem end-to-end, not just push pixels on a ticket. If that sounds like what you're hiring for, reach out.