My process

How I work

1. 01

   Understand

   Where a project starts decides how I start.

   Starting from scratch

   When a product is brand new, I get deeply familiar with the idea before I open a design tool: the vision, the users, the constraints and the business goals. That means sitting down with stakeholders, asking a lot of questions and reviewing any research that already exists, until I know exactly what we’re building and why.

   Redesigning what exists

   A redesign is a different animal. The product is live and people already depend on it, so my job is to find what’s working, what’s broken and where the biggest opportunities are. I start with a heuristic evaluation, assessing the experience against established usability principles to surface issues that aren’t obvious at first glance, then talk to the people who use it every day. I don’t redesign for the sake of it: every change needs a reason, and the evaluation gives me the evidence to back it up.

   

2. 02

   Define

   One problem, agreed goals, a clear scope.

   Before anything gets drawn, I turn what I’ve learned into a clear problem statement, goals we can measure and a scope everyone signs up to.

   I take this alignment seriously because everything after it depends on it. If we aren’t on the same page now, we pay for it later in wasted iterations and mismatched expectations. Getting aligned upfront saves time and protects the quality of the work.

3. 03

   Sketch

   Rough on purpose, fast by design.

   Once the direction is clear, I sketch. It’s the first real iteration, and it’s rough on purpose: sketches exist to get ideas out of my head and in front of people, so everyone can react to something concrete.

   I run collaborative sessions in Miro and FigJam, but when speed matters I reach for paper and pen. Nothing gets through more concepts in a working session. No loading screens, no pixel-nudging, just ideas.

4. 04

   Wireframe

   Structure before style.

   Sketches that survive feedback (and sometimes everyone is on board straight away) become wireframes. This is where structure gets decided: user flows, layout and hierarchy, without visual polish getting in the way of the conversation.

5. 05

   Design & iteration

   High fidelity, shared early, refined often.

   Then I move into high-fidelity design in Figma, locking down visual detail, interactions and edge cases, built on the design system so it scales.

   I share the work early with stakeholders, PMs and developers, and iterate on what comes back: feedback, the occasional compliment, and more rounds. I stay close to engineering throughout, so the design remains feasible within the time we actually have.

   

6. 06

   Design engineering

   What ships is what was designed.

   More and more, I don’t stop at the handoff. I build production-ready interfaces and working prototypes myself, often with AI coding tools, so nothing gets lost between the design file and the product.

   Thinking about implementation while I design tightens every decision, and building it surfaces what static screens hide: real data, loading and empty states, and performance.

   

7. 07

   Test & refine

   Testing doesn’t wait until the end.

   I build prototypes throughout so stakeholders can experience the product first-hand. My Figma prototypes are detailed enough for real users to test and give meaningful feedback, not just click through static screens.

   Sometimes testing happens with the team, sometimes with users before a single line of code is written. It happens at different levels and stages, and every round shapes what comes next.