Design isn't decoration. It's a solution: for your business, and for the people using it.
Here's what actually happens when you hire me. No case studies, no jargon: just the questions founders ask me, and how I answer them with work.
Understand
"I already know my product and my customers. Can't you just start designing?"
I could but then you'd be paying me to guess.
Before I open Figma I want to know two things: How your business makes money? What your users are actually trying to get done?(Who are they? How old?) Have they used something like this before, or is your product the first of its kind for them? A 55-year-old landlord and a 24-year-old first-time renter need very different things from the same screen. That isn't a design opinion. It's something I find out.
"Research sounds slow and expensive."
Skipping it is what's expensive. Every redesign I've seen fail was a beautiful answer to the wrong question. One focused week means every decision after this has a reason behind it and I can show you the reason instead of asking you to trust my taste.
- 1Stakeholder interviews
- 25-8 user interviews
- 3Analytics & support-ticket review
- 4Competitor and pattern audit
- 5A first-pass journey map
- 01A short findings doc: who your users are, what they're trying to do, where they get stuck
- 02The 2-3 problems worth solving first and the ones we deliberately leave alone
- 03A shared vocabulary, so we stop talking past each other
Define
"So what are we actually building?"
Now we decide together.
I turn what we learned into a clear problem statement, the journey as it is today, and the journey as it should be. This is where I'll push back if a roadmap feature doesn't serve the user or the business.
Not because I like saying no, but because you're paying me to protect the product, not just to draw it.
"What if I disagree?"
Good. You know your business better than I do. I bring the user's side and the evidence; you bring the strategy. The decisions we make here are what the whole design rests on, so I'd rather argue for an afternoon now than rebuild in month three.
- 1Problem statement & success metrics
- 2Journey maps and task flows in FigJam
- 3Scope cut for v1
- 4A decision log so nothing gets relitigated
- 01A one-page problem statement and success criteria we've both signed off on
- 02Journey maps and task flows - the product's skeleton before any UI
- 03A scoped v1: what's in, what's out, and why
Design
"Finally! the beautiful part."
Yes, and it will be beautiful. But look at what's underneath it.
Every layout, label, and button state comes from something we learned earlier: how familiar your users are, what they're afraid of getting wrong, what they need to see first. Aesthetics do real work: they build trust in three seconds and make a complex product feel easy.
Empty states, error states, the "what happens when it fails" screens: those are design too, and they're usually where products lose people.
"Will I see one design or options?"
Options: two or three distinct directions early, with the tradeoffs spelled out.
I'd rather you choose than accept a default. Then we converge fast, and I work in the open: you'll see drafts as they take shape, not a big reveal at the end.
- 1Low-fi flows → hi-fi in Figma
- 2A component system from day one (tokens, type scale, spacing)
- 3Every state designed, not just the happy path
- 4Async crit via Loom and Figma comments so time zones aren't a blocker
- 01Wireframes → high-fidelity screens, with the reasoning attached to every major decision
- 02A clickable prototype you can put in front of real users - or investors
- 03All states covered: empty, loading, error, success, and the awkward edge cases
If you've scrolled this far, we probably think about design in a similar way. The workflow page shows how I work; this one shows why I enjoy it. If you'd like both on your product, let's talk.
Validate
"It looks great. Ship it?"
Almost. First we check it with the people it's for: watching them try to do the task, not asking whether they like it. This is the cheapest moment to find out a flow doesn't make sense. We usually find two or three things; fixing them now costs a day. Finding them after launch costs a quarter.
- 15 moderated sessions on the prototype
- 2Unmoderated task tests when we need numbers
- 3One round of fixes
- 4Then re-test the risky flow only
- 5Async crit via Loom and Figma comments
- 01A short test report: what worked, what didn't, what changed
- 02The revised design - with evidence that it works, not just that it looks right
Ship & learn
"My developers will just figure it out from the Figma file, right?"
Let's not make them. I hand over a spec your team can build from without pinging me every hour: organized files, components, spacing and type rules, behaviours notes for every state. I stay in the build. Design QA before release, and I'm reachable when an edge case shows up that neither of us planned for. Then, once it's live, we look at the numbers we agreed on in week one. That's how we know it worked, and what to do next.
- 1Dev-ready Figma with a documented component system
- 2Handoff walkthrough with engineers
- 3Design QA on staging
- 4A 30-day post-launch review against the success metrics
- 5Async crit via Loom and Figma comments
- 01Dev-ready files, build spec, and a walkthrough with your engineers
- 02Design QA before launch
- 03A post-launch review: what the numbers say, and what I'd do next
- 04The option of ongoing design support as you grow
So how do I work with it?
"Can't I just generate the designs with AI now?"
You can generate screens. You can't generate the decision about what the screen is for. That still comes from knowing your users and your business. So I use AI hard, but in the right places.
Where AI does the heavy lifting
- Research synthesisClustering interview notes and support tickets, so my hours go to insight, not transcription.
- More directions, fasterDozens of layout and copy variants in the time it used to take to make three. The judgement about which is right is still mine.
- Working prototypes, not just clickable onesCoded prototypes built with AI tools, so users test something that behaves like the product — and your engineers get a reference that already runs.
- UX copy iterationVoice and tone variants, edge-case messaging, error states written for humans.
- Design QAMissed states, inconsistencies, and accessibility issues caught before a human ever sees them.
Where AI doesn't get a vote
- Talking to your usersI do that myself, every time.
- The decisionsWhat to build, what to cut, what to say no to.
- The final craftAI gets me to 70% quickly. The last 30% is what your users actually feel.
- Your confidential dataNothing goes into tools that don't meet your policies — and I'm transparent about where AI was used in the work.
So I know what it looks like when an interface pretends to be more certain than the model behind it and I design so yours doesn't.
See my speciality: AI & probabilistic UX →Grouped by the job, not the logo.
The tools change; the jobs don't. This is what I reach for at each step.
Think & research
- Notionresearch repo, decision log
- FigJamjourneys, workshops
- Claudesynthesis, drafting
- Google Workspacescheduling, docs
Design
- Figmadesign, components, variables
- Figma Dev Modehandoff
Prototype & iterate
- Figma prototypesflows
- Lovablecoded prototypes, real behaviour
- Claude Code + MCPFigma ↔ code
Feedback & testing
- Mazeunmoderated tests
- Google Meetmoderated sessions
- Hotjar / PostHogheatmaps, replays
- Typeformsurveys
Collaborate & ship
- Loomasync walkthroughs
- Slackday-to-day
- Linear / Jiratickets with engineers
- Figma commentsasync crit
How I collect it and what I do with it.
Stakeholder opinions are useful. Watching a real user get stuck is what changes the design.
- Moderated usability tests5 per round on Meet, recorded. Watching someone attempt a task tells me more than any survey.
- Unmoderated task testsIn Maze: when we need a success rate, not a story.
- InterviewsBefore design to understand; after launch to learn what changed.
- In-product signalsHeatmaps, session replays, drop-off points, support tickets.
- Async critIn Figma comments and Loom: feedback on your schedule, not mine.
- Weekly working session30 minutes, decisions made, decision log updated.
- Engineering review before hi-fiFeasibility answered early, not at handoff.
- One placeEverything lands in Notion, tagged by theme and severity.
- Prioritized against the metricsThe success metrics we set in week one decide — not who said it loudest.
- You get a one-pagerWhat we heard, what we're changing, what we're not and why.
Every engagement starts with 2–3 numbers we care about: activation, task completion, time-to-value, support volume, conversion. Design decisions are made against them, tests are scored against them, and 30 days after launch we look at them together. If the design didn't move them, that's my problem to solve, not yours.
Five things I won't compromise on.
- Research before pixels.Every decision has a reason I can show you.
- Design is a solution.For your business and for the person using it at the same time.
- Familiarity changes everything.Age, context, and experience with products like yours shape every screen.
- Clarity over clever.Especially in AI products, where the interface has to be honest about uncertainty.
- AI accelerates. It doesn't decide.Everywhere it makes the work better; nowhere it would replace understanding your users.
Want to see how this would work for your product?
Tell me what you're building and who it's for. I'll come back with how I'd approach it — before you commit to anything. No pitch, no pressure; just a conversation about your product.
Or see how I work with Realode for shorter contracts