Julio Reguero

Design Process

My Product Design Process: Overview of key activities involved in each phase


In user experience design, there’s no shortage of perspectives on the creative process. In this page, I have defined what I consider an “ideal” product design process, based on my years of experience working in creative roles. This non-linear design process outlines six steps to help any project team proceed systematically throughout a product lifecycle. Iteration happens at every stage of the design process. Each stage involves relevant stakeholders that take part in the process to make the product experience for customers delightful and usable.



I start each project by gathering as much information as possible. I commit to developing an understanding of the problem domain and target audience. I'll combine forces with product and engineer stakeholders to join this collaborative effort and answer essential questions about the project, like: what problem are we solving, who it is for and how it will be used, why does it matter, what the desired results are, and how we can track success. Based on what we learn, we can apply the knowledge from talking to stakeholders and end-users to better understand and reframe the problem, and iterate our project objectives and approach.

The following are some of the research techniques and activities involved in this step: analyze requirements and available analytics, identify early assumptions, interview users to understand their wants, needs and pain points, create personas and map their journeys with a set of product use cases, create user flows, define the problem statement, define clear project goals and objectives, analyze the market competition, and keep an eye on design principles and existing guidelines and best practices.



This phase ranks very highly in importance due to the need to spread the word about findings, organize stakeholder buy-in, and get everyone working on the product on the same page.

With all the previous research and knowledge, we can understand who the product is for, their challenges, and the main use cases in which our target audience is likely to be involved. Then we run ideation sessions looking for suitable solutions before determine what to build. We start with an idea, explore aspects of that idea – go wide – and diverge into many directions to explore new possibilities. Then we converge. Having explored a number of options, we dismiss the paths that are dead-ends and focus on the paths that converge around our vision. The purpose is to align the project team around the strategic direction of the product, but not get too bogged down in constraints early on in the process.

TIP: The best way I’ve found to quickly and easily communicate with my team how I plan to tackle a problem at this stage is with hand-drawn paper sketches, white board flows and wireframes.



Once we have a base set of requirements, we need to assess and prioritize each one against the project’s goals. I classify each requirement as essential, non-essential, or nice-to-have. It allows the team to more effectively plan and phase how the project will proceed and what scope will be tackled when. This is easier said than done. It forces us to analyze what’s truly important and what falls into “nice to have”. That often means letting go of some of our favorite ideas and focusing on the foundational elements that move the team toward the product vision. At the end of this stage, we’ll have moved from a conceptual idea to a more tangible set of requirements necessary to build it.

The product strategy will contain the list of features we will build first. Prioritization can’t be done in isolation. It’s part of the strategic planning process of any project. Furthermore, it’s essential to tie the resulting release schedules and roadmap back to the product’s value.



After we’ve prioritized requirements and collectively defined a feature list and release plan, we can begin the design phase.

Working side by side with the team, I help to give shape to potential solutions and discuss basic structure, layout, and content. Real collaboration is fostered by receiving instant feedback and reshaping the product from discussions. During this process, we take the final sketches and wireframes and create low to mid-fidelity clickable prototypes that we could test with real people from our target audience. After testing the product and modifying the protos, then finally we get to the pixel-perfect, colorful, detailed design mockups. Preparing and sharing of design specifications (principles, guidelines, colors, typography, iconography) to the development team is also part of this stage.



Part of the prototype stage overlaps with testing. Here we conduct several rounds of user testing, iterating the prototype after each test based on what we observed and feedback that the users shared. During this process, there will undoubtedly be instances when something we originally conceived doesn’t work out (at least as we planned) and introduces new, unanticipated requirements. This is to be expected. When this happens, we have to identify scope impacts and negotiate when and how to incorporate this new scope into the bigger plan and project phases.

Taking everything that had been learned from user testing, we made one final iteration to the prototype so that we could test and validate the design with a set of participants.



Since engineers participate in early stages of the process, they can start implementation while the design phase is in progress. The development team builds the back-end functionality first, and connects it with the UI once they get the design artifacts they need — Zeplin is a good design hand-off collaboration tool between designers and engineers. While implementing, it is possible to raise the need of minor changes in the design.

As the product comes to life, either in QA environment or production, through incremental build phases, our focus shifts from the trees back to the forest contemplating big questions such as:

  1. How well does what’s been implemented map to our original priorities and plan? Does it provide the desired solution to user’s problems?

  2. Is it easy to use for the end users?

  3. What changes or trade-offs were made either for the better or for the worse?

  4. What have we learned during the process that may alter the direction we need to go with the next planned phase or release?

  5. How will new requirements be addressed and integrated into the project plan?

The goal is to step back and assess what we’ve delivered as a team, and determine if we need to calibrate or change direction in future releases. The process goes on until the desired experience and customer satisfaction is achieved.

TIP: Mixpanel is a great tool to get valuable customers insights, make smarter decisions, and act faster based on how customers use the product.



  • An amazing user experience can only be provided by following an iterative design process, one we as designers need to embrace and drive if we want our product concepts and ideas to see the light of day.

  • To create useful products, designers need to first empathize with users and find the audience’s pain points, and then come up with a set of hypothesis — for example, about users, their goals and how they will use a product. To reduce uncertainty these hypothesis need to be tested.

  • All major stakeholders in a company contribute in the process by performing their tasks and collaborating with other people to accomplish the project’s goals.

  • Design takes place within an iterative cycle of learn-prototype-test-build-measure where designers validate ideas with users as early as possible.

  • Design is a messy process. The path from initial ideation to detailed design and implementation is anything but linear or predictable. Even when a product vision is clear, the development process has twists and turns. Designers must be adaptable to changes that present themselves.