What I do
Research
Before any pixels are pushed, I need to understand the product, the users, and the business behind it.
I look at how people actually use the product. Sometimes that means sitting next to them. Sometimes remote testing, session replays, or data from support and feedback tools. I ask open questions, not to confirm assumptions, but to learn what really happens.
I work closely with product owners and stakeholders to clarify goals, constraints, and success metrics. I map journeys, define problems worth solving, and align user needs with business outcomes. This phase keeps the team focused on solving the right problem, not just building features.
Design
Design starts low-fi. I sketch flows, screens, and variants fast, ugly on purpose, to test logic and structure before visuals.
I think in systems, not screens. I focus on flows, edge cases, states, and how decisions scale across the product. Once things make sense, I move into Figma to refine hierarchy, interaction, and visual clarity.
I collaborate early and often with product managers and developers. I share work before it is polished so we can shape it together. Accessibility, error handling, and real-world constraints are part of the design from day one.
For handover, I create clear specs, reusable components, and design system updates so teams can move fast without guessing.
Test
Good product design is validated, not assumed.
I test ideas early and continuously. Sometimes through clickable prototypes, sometimes walkthroughs, and sometimes quick checks with people who have never seen the product before. If users hesitate or misunderstand, I go back and adjust.
Testing helps reduce risk, align teams, and avoid costly rework. It gives confidence that what we build is useful, usable, and worth maintaining.