What I do
Research
Before any pixels are pushed, I need to know who I’m designing for and why it matters.
I watch users in context, sometimes that’s sitting beside them, sometimes it’s remote testing. I ask open questions, not to confirm what I think, but to see what they naturally do. I also dive into feedback, survey data, and support tickets. Even short conversations with customer-facing teams can reveal friction we might otherwise miss.
I map journeys, define pain points, and outline what success looks like, for the user and for the business. This phase keeps me honest. It makes sure the design solves the right problem.
Design
Design starts low-fi. I sketch flows, screens, and variants fast, ugly on purpose, to test logic, not aesthetics. Once things make sense, I move into Figma to shape structure, hierarchy, and interaction.
I collaborate early. I send things out for reaction before they’re done, so we can shape it together. I also build in accessibility and error states from the start, not as an afterthought.
For handover, I create design systems and annotate interactions clearly. Developers shouldn’t have to guess what a button does, or how a component responds to different states.
Test
Good design doesn’t happen in a vacuum. I test ideas before they ship.
Sometimes that’s a clickable prototype, sometimes it’s just a narrated walkthrough. I test with real users when I can but I also grab quick feedback from peers, product owners, or people who’ve never seen the flow before. If they stumble, I go back and rethink.
Testing also helps avoid expensive mistakes. It gives the team confidence we’re on the right path or a chance to course-correct before code starts.
Testimonials
