How I work

My process is not linear. It never has been. Every project is different, and I adapt how I work based on what the project actually needs. A brand-new product from scratch looks very different from a redesign of something that already exists. But no matter the starting point, there are a few things that stay constant: I stay close to stakeholders, I move fast through ideas, and I test early.

New projects from scratch

When a project is completely new, I start by getting deeply familiar with the idea. I need to understand the vision, the users, the constraints, and the business goals before I touch any design tool. This means sitting down with stakeholders, asking questions, reviewing any existing research, and making sure I fully understand what we are building and why.

I take stakeholder alignment seriously at this stage because it plays a major role in everything that follows. If we are not on the same page early, we pay for it later in wasted iterations and misaligned expectations. Getting aligned upfront saves time and protects the quality of the work.

Redesigns and existing products

Redesigns are a different animal. The product already exists. Users are already interacting with it. My job is to figure out what is working, what is broken, and where the biggest opportunities are. I start with a heuristic evaluation of the current experience, systematically assessing usability against established principles to surface issues that might not be obvious at first glance. From there, I talk to users who actually use the product and identify friction points before proposing changes. I do not redesign for the sake of redesigning. Every change needs a reason, and the heuristic evaluation gives me the evidence to back it up.

Sketch

Once the direction is clear, I sketch. This is the first real iteration, and it is intentionally rough. Sketches are not meant to be pretty. They exist to get ideas out of my head and in front of people so everyone can react to something concrete.

I am proficient with tools like Miro and FigJam for collaborative sessions, but when speed matters, I reach for paper and pen. There is nothing faster for getting through multiple concepts during a hands-on working session. No loading screens, no pixel-nudging, just ideas on paper.

Wireframe & design

After sketches get feedback (and sometimes everyone is just on board right away), I move into wireframes and then high-fidelity design in Figma. This is where layout, hierarchy, and interaction details get locked down.

Once the design is in a solid place, I share it with stakeholders, PMs, and developers. During this phase, there are feedbacks, compliments, and more iterations. I work closely with developers to make sure the designs are feasible and realistic given any time constraints. If I am the one developing, this step is even tighter because I am already thinking about implementation while I design.

Test & refine

Testing does not wait until the end. I build prototypes throughout the design process to let stakeholders experience the product firsthand. My Figma prototypes are detailed enough that real users can test them and give meaningful feedback, not just click through static screens.

Sometimes testing happens with the team. Sometimes it happens with actual users on a design prototype before a single line of code is written. Testing happens at different levels and at different stages, and each round informs adjustments to the product.

The bigger picture

These phases are not a checklist I follow top to bottom. I move between them based on what the project needs at any given moment. A test might send me back to sketching. A stakeholder conversation might redefine the problem entirely. The process is built to handle that. It bends without breaking.

The one thing that stays constant: everyone stays on the same page. That is the hill I will always stand on.