Product Design Process: 4 Steps To Design A Product People Will Love

There is a myriad of methods out there to choose from when it comes to the product design process and development. In this article, we would like to give an overview of the steps and frameworks we consider essential and provide a toolbox you can pick ideas from when designing a Minimum Viable Product, which is the first version of a product with just enough features to satisfy early customers, create value and provide feedback for future development.

The ideal product design process can vary depending on different factors, such as the project scope, the size of the company, budget, deadlines — just to mention a few. In a good design process, the business requirements meet the user needs, which are satisfied within the feasible technical possibilities.

Even UX studio’s product designers don’t have just one, crystal clear and always followable guide for design processes. We all see the necessity of getting together from time to time and share our experience and knowledge acquired from different projects and clients with each other, so we can improve our processes effectively, meeting the requirements and demands of the market.

We encourage an Agile style of work, working in design sprints, but we are flexible. Should you need help with product design, fill out our contact form and let’s discuss how we can help you.

Steps of a user-centered product design process

the double diamond product design process

The Double Diamond is a product design process with four phases: Discover, Define, Develop, and Deliver. The product design process starts with a “diverging phase” of the diamond, a problem, and topic discovery. We do not define anything yet, but we step back a little and open our minds to new insights.

The second part of the diamond — Develop and Deliver — mainly feeds from the product discovery findings. However, the Discover-Develop tracks can also run in simultaneously and support and feed into one another at regular intervals, so this is not a linear process.

Step 1: Product discovery – What problem we want to solve and for whom

Product discovery is the preliminary phase of every human-centred product design process, and its purpose is to base the product idea on real demand.

However, carrying out research is important not just at the beginning, but during the project as well, whenever there are too many open questions and uncertainties. Validating ideas helps us to avoid burning money and waste time.

We need to reach out to both the stakeholders and the users to explore the problem (and opportunity) space and find the real pain points we want solutions for.

There are two frequently used product discovery activities we’ll be looking into a bit more:

  • Workshops (e.g. kick-off workshops),
  • Exploratory research; user research 
    (Market research findings are also important. We don’t do this one, but if you’re curious about the differences between user and market research, check out this article.)

Kick-off workshops

Meet the client, understand the current state of the project and the additional knowledge needed.

Workshop techniques are great for acquiring domain knowledge in a topic and get acquainted with the stakeholders. To create the first draft of our roadmap, we start every project with a kick-off workshop that usually takes about one to two days. At this time, we get to know the company, its processes, and roles and gather all information we can about the project.

If the client already has some quantitative and qualitative data about the market, client segmentation, competitors, target group, buyer personas, we go through them, make a common understanding of the objectives and facts, and build assumptions and hypotheses.

The more variety of expertise involved in the workshops, the more insights we can utilize from different stakeholders of the company. It’s important to understand experiences on previous solutions and key business objectives (such as KPIs, success criteria). 

Kick-off workshop techniques frequently used by us:
/Note: At this point, most of the workshop deliverables are assumptive, and that’s fine because we’re going to research what we need to validate or change.

  • Assumption matrix: We collect the stakeholders’ beliefs about different topics, find the most important, high-risk “leap of faith assumptions” so we can validate these with research and find out if they’re real.
  • Persona and/or Jobs-To-Be-Done workshop: Assumptive personas are our best guesses on who will use the product and why. It helps us to recruit for interviews and for the client to empathize with their future users.
  • Customer journey workshop: These workshops help us get a view on how people navigate through the product or service. It is also an excellent opportunity for knowledge sharing with our clients.
  • Value Proposition workshop: We map out the perception of the value of the product identified by users.  We also validate assumptions and thus Value Proposition for each customer segment. This provides vision and guides the design.
  • Brand Vision, Mission, and Values: The best way to reveal the vision is by asking the brand’s key personnel why it was created. For every answer, they provide, make it hard on them, and keep asking why. After a few rounds of whys, we get to the heart of the matter.

At the end of the kick-off workshops, we should have a clear overview of what we don’t know but should do so we can create a research plan to kickstart our discovery.

If you’d like to know more about how to organize a kick-off workshop, check out this article.

There are a couple of research methods out there; however, in the discovery phase of a product design process, we don’t aim to evaluate possible solutions yet as that comes later with usability tests. Still, we may already have assumptions to validate, and we certainly need to have a well-defined topic and a target group that is interested in our topic. At the same time, it’s crucial to keep an open mind to be able to discover entirely new aspects and problems of our audience.

Product Design Process: User's Needs

Of course, the research method that requires the least experience and professional knowledge is desk research, available for anyone who has a computer with internet access, an account for social platforms and some time to dig up the pain-points of online communities, find opinions and reviews shared in social platforms, forums, mailing lists, or blog comments.

Diary study can also be useful in some cases, or, if you want to gather data on a larger scale, you can use online surveys — preferably with a mixture of open-ended and closed questions — that can be used with qualitative insights from other methods.

Research methods we frequently use:

  • Semi-structured User interview is the method we use most frequently in the discovery phase, as it’s relatively easy to organize and provides great insights into exploration. The 10-15 interviews we start with usually provide enough insights to move forward. We try to recruit interviewees from each segment/target group we defined earlier and involve the stakeholders in writing the interview script.
    Our researchers evaluate the previous results before each interview and iterate the questions to get the most useful answers from the remaining interviews. If it’s necessary and our collaboration has the resources, we do follow-up interviews to dig deeper into sub-topics. 
  • Field research is among the most reliable methods as it is based on observing user behavior in their environment. But for this very reason, it’s also harder to organize and conduct without influencing the users’ behavior and interfering with the natural way of executing their daily tasks.
  • Competitive research can also be applied, as it’s very likely that by this point, the product team already gathered the main direct and indirect competitors from stakeholder meetings and user interviews. More knowledge about successful competitors can aid us with feature ideas or design inspirations and can help us to position our client’s product. Even if there is no in-depth competitive research, we should at least maintain a competitor list in a collaborative spreadsheet or any cloud-based tool. 

Step 2: Narrow down – Define

This step is about making sense of the data, synthesizing them, choosing one main goal to solve, figuring out the “How” and the “What”.

By the end of the discovery phase, we are likely to have enough insight to synthesize our findings, refine our previous assumptive deliverables or create new ones by user analysis, define the core problem we want to solve, build themes, and deduce potential fields of action. 

There are many synthesizing activities to use, such as:

  • User personas
  • Jobs-to-be-done
  • How might we
  • User stories
  • Storyboards and scenarios

These exercises can be used at various points of the product design process; at the very beginning, in an assumptive way, it can help with synthesizing the research data and define the project scope, but it can also be applied when ideating about solutions. The when and how really depends on the team, project, and available insights. In the following section, we focus on the methods we use the most.

User Personas
These are fictional (yet realistic) representatives, archetypes of our key user groups with certain goals and characteristics. We use personas to help us understand and map out the main segments of our users, with their different goals, and motivations. We can also use them to help us empathize with them in order to make a more suitable product.

At UX Studio, we do create assumptive, theoretical persona mock-ups at kick-off meetings. If provided, we can use already existing research data (e.g., survey results, built buyer personas, or other related market research findings) to start off with, but at this point in the design process, our personas should be validated and based on real user research data.

How we create personas:
There are many contradictory opinions out there about whether it’s good to give names and faces to personas, or if demographic data is relevant if it needs to be printed or should include an empathy map, and so on. This is how we usually do it:

  • You would rarely need to go above 3-5 personas, but the number highly depends on the project scope and product type; the broader the target audience, the more persona you may need. However, it’s better to iterate on categorization to avoid having too many personas as it can jeopardize your design process in the long term (it’s pretty hard to design for too many people with different sets of characteristics)
  • We don’t spend hours and days creating stylish persona posters to hang them on the wall because we know they’ll change and get refined, so there is no point to waste hours with this analog process.
We love how these stylish persona artifacts look, but they become pretty useless, pretty fast, when new findings force them to evolve.
  • Our persona sheets include goals, motivations, frustrations, behavior patterns, background, and context-specific details (details relevant based on the project, e.g., which mobile platform they use). We also add a profile image, name, some personal details, and demographic data to help with building more empathy and make them easier to remember.
We use a great online collaborative tool, Miro to create, share, and update our digital personas.

There are plenty of methods for synthesizing information, but we only dig deeper into the ones we use most frequently. You can find a few related, downloadable templates here.

JTBD is another framework we can use to find out more about the users’ needs and preferences. It is absolutely compatible with user personas, so often used together.

The personas focus more on the users’ behavior and attitude, thus helps with empathizing and segmenting the different types of users, while the JTBD places a more significant emphasis on features, aims to discover the purpose why people ‘hire’ a product in order to solve a specific problem and fulfill a need.

The “template” JTBD structure

A famous JTBD example is about McDonalds milkshake. When the company wanted to increase the profit on their milkshake product, they first started interviews with representatives of their persona groups, the customer types they knew to be the main milkshake consumers.

The researchers tested the temperature, the viscosity, and the sweetness of the milkshake with this group, but they couldn’t find out what the problem was and how they should improve the product.

So they tried another approach; started observing and interviewing consumers onsite, in McDonald’s restaurants. It turned out that people bought milkshakes mainly to keep them full till lunch and entertained them for the whole journey of driving to work.

As a result, McDonald’s made the shake thicker to last longer while commuting and moved the milkshake machine from behind the counter to the front, where the customers could easily and rapidly buy a milkshake with a prepaid card when rushing to work, avoiding the queues. Solving the real job-to-be-done, resulted in a sevenfold increase in the sales of the milkshake.

“How Might We”
The HMW exercise is a great way to narrow down problems and to discover possible opportunity areas.

We are not looking for exact executions on solutions here yet, but rather brainstorm, explore questionable areas of one core challenge while keeping an open mindset for innovative thinking.

For this to work, first, we need a clear vision or goal, a Point-Of-View statement that is made based on a deeper user need discovery. The POW should be human-centred, neither too narrow, to sustain creative freedom when brainstorming, nor too broad, so it remains manageable.

For defining the POW statement, your previously made personas and jobs-to-be-done (as a result of your user’s need discovery) come in handy. By synthesizing the essential needs to fulfill, you can make a template like this to create your statement:

In short: 

[User . . . (descriptive)] needs [Need . . . (verb)] because [Insight . . . (compelling)]
Once you have the POW statement, you are ready to form short questions that can launch brainstorming on actionable ideas. For example:
How might we…? 

In What Ways Might We….?

What’s stopping us from…?

In what ways could we…?

What would happen if…?

Then you may ask follow-up questions on the previous questions to examine the angles a bit deeper.
By completing HMW sessions, we can get one step closer to forming ideas about exact solutions and executing the best solution.

Look and feel, mood boards, branding
Of course, at this point, we’re far from creating high-fidelity prototypes and design systems, but it’s important to set a couple of broad, basic directions to have a general idea of where we’re heading and keep nurturing the creative imagination as we progress in the design process.

(Moodboard and Brand wheel)

Depending on how many designers working on a project, you can share the workload and either work on the same design or split up the tasks and progress simultaneously (e.g., one does the prototyping and the other building the design system and hi-fi part).

At this point, we should have a condensed brief of research findings, a strategy, and a clear idea about what problem we want to solve.

Step 3: Brainstorm solutions, define and prioritize features.

The tips and techniques mentioned here can be done or can at least be started way before this step; remember, this is not a linear process and you may use these techniques in a different order at different times of the project timeline.

The developing/ideation phase begins when we have a good understanding of the project goals, and we narrowed down what we want to solve first.
(Note: by development, we don’t mean any code-related development yet). 

If there are still open questions about what features we should start with, the Kano model and Impact-Effort Matrix could serve us well.

Impact-Effort Matrix – To fasten up decision-making about what to implement.

User journeys/customer journeys
Both customer journeys and user journeys are tools for mapping out the flows users go through, using a service or an application with one specific task to carry out.

Customer journeys/experience maps encounter the online and offline aspects of the users’ flow, providing a more holistic view of the process. As the output, the customer journey diagram basically lays out a big table. The columns of the table represent different phases or steps a customer goes through.

These can be unique in every project, but most customer journeys contain three phases: before, during, and after the usage of our product.

These can be unique in every project, but most customer journeys contain three phases: before, during and after the usage of our product.

As opposed to customer journeys, user journeys analyze a smaller part of the journey, focusing only on what happens in the application; for example, during a sign-up process. At UX Studio, we mainly use user journeys, but for longer projects with a bigger scope, especially if there is already existing user data about the customers and there is a journey that goes beyond application usage (e.g., arriving at the airport and using a ticket machine software), the customer journey is the preferred tool.

How we do user journeys: 

  • To start off, determine the two or three most important goals to achieve with your product. Every journey must have a task, a motivation, and context.
  • It’s also good to include a simplified empathy map nested within the journey map, indicating what emotional reaction the user has to each step. These are good indicators for us to which points we should handle with extra care and improve on. These emotions can be assumptive but also based on solid data we gathered from our product discovery and research before. Use your personas.
  • Creating user journeys is still part of the experimental phase, so we encourage you not to stop with one idea but try out different paths, reorder the steps, complete the ideas, and explore. 
  • You want to find many different versions for each journey, as sometimes there are great first ideas, but oftentimes these are not the best solutions. For this reason, create at least three different journeys for each goal. Then, once you come up with several solutions, decide on the winner.

User stories
User story creation is a good way to define features with stakeholders. What we want to accomplish in the product, why, and as what kind of user. It helps us stay focused on what features are necessary and what could lead to a “feature creep.”

High-level example:
As a sales agent, I want to turn more leads into customers so I can increase my income.
And a more detailed version of the example above:

As a sales agent, I want to keep track of unprocessed hot leads so I can make sure I don’t miss out on an ‘easy’ deal.

We can do it in several ways and styles, if we do it with developers, it may become more technical and scrum-oriented.

Building the IA, sketching and wireframing

Building an Information Architecture is basically the blueprint of the design structure, the foundation of our first wireframes. IA is formed by creating a hierarchy and categorization of the information that results in a coherent, meaningful, navigable system. How we sort out the features, functions, and available data in our product will have a great impact on the user experience.

Our best intentions with features can diminish if users don’t find them.
Card sorting is a great technique to validate our IA. You can do it on paper, but there are online tools that you can use, such as Optimal Workshop.

Read an article about redesigning a complex IA


You may start sketching way earlier, right at the beginning when the first problems gain their shapes. Sketching is great not only to serve as the base when building something but also to help understand a problem and share ideas within the team.

Sketching on paper, where complex interfaces and functions of the software don’t limit or distract us, is an effective and rapid way to explore ideas and spot any design problems early on.

We don’t need to be skillful sketch artists or graphic designers who can draw and paint photo-realistically. The point here is not to create a refined artifact, but to focus on single ideas, flows, and possible layouts, and use simple placeholder boxes for images and text. It’s about exploring ideas of execution, so no need to worry about the copy yet.

It’s very recommended to showcase these first sketches and wireframes to the developers and other team members at an early stage because they can assist us with information on what is feasible technically, which saves us from unnecessary rework.

A blank paper and a pencil are all you need, but if you’d like some guidance, you can download sketch mockup sheets from here.
The output, a wireframe, is basically the skeleton of our upcoming prototypes — a barebone, static structure that will soon evolve to a refined design. Wireframes can be made on digital platforms as well using tools such as Axure, Adobe XD, Sketch, Figma, or even Photoshop.

Wireframe in Sketch

At this point, you should have the concept, the “what to do”, and the strategy of how to prioritize. We have the definition of our MVP, the core features, the core problem we want to solely focus on. 

If you are searching for the most suitable UX agency, contact us, and let’s see how our UX experts can help you with your current challenge.

Step 4: Narrow down – Deliver

Prototype, test, iterate, implement.
This phase is all about doing the right thing in the right way, reaching our goal, refining our MVP, and implementing the solutions. 

Low-fidelity Prototyping
Making our ideas tangible with quick prototypes and test them out as soon as you can save a ton of time and resources. For the sake of definition, what we call a prototype here is a modest-looking clickable digital product that resembles the features we aim to develop, but in a simplified way.

Paper prototypes exist too, but we prefer the freedom and opportunities only digital solutions can provide. The goal here is to find out the usability issues before starting the detailed designs to avoid burning time and doing reworks.

Low-fidelity, interactive prototype for testing

How we build prototypes:

  • We mainly use Axure for interactive low-fi protos. With Axure, you can add dynamic elements, Javascript, create databases, which are uniquely complex features in the world of prototyping tools.
  • There are always three essential questions the user needs to be able to answer on every screen you design: Where am I? What can I do here? How can I move forward?
  • Forget lorem ipsum and be scarce with dummy text. A sensible, contextual, guiding copy is just as important as visual hierarchy and affordances.
  • Follow UI patterns and keep best practices in mind (a couple of great resources of inspiration: Mobbin, Muzli, UI patterns).
  • Keep it simple. We’re testing the usability of layouts, key user flows, and navigation at this point. Don’t test refined visuals yet, unless it’s not an MVP and you are testing already existing features in a live product.
  • Design for mobile first if the project allows you.

Create the first protos as soon as you can and evaluate them for usability tests. Refine your prototype iteratively after every usability test until you’re confident that you ruled out every major usability risk. (And of course, later on, continue usability testing before and during every new feature.)


High-fidelity prototyping
Now that you have the base of a usable product, it’s time to make the whole thing sexy by adding the visual attributes, colors, icons, shadows, and images and refine the look and feel. The product’s design language has to be in harmony with the target audience and should be aligned with the brand’s vision. When testing the high-fidelity prototypes, visual elements are also important, and it leads to creating a stable, harmonized design system that you can rely on. 

Quick tips for hi-fi prototypes:

  • We mainly use Figma, Sketch, or Adobe XD in UX studio, however, the choice often depends on the preferences of the client’s team and the technical requirements. 
  • Create and maintain a design system based on brand guidelines and vision. Design systems facilitate effective collaborative work, alleviates decision fatigue, and assist designers in keeping consistency throughout the product. Even if it’s an MVP, you’ll be wanting to scale up your product if everything goes right, so building a design system is inevitable at some point when managing a successful product design process. It’s better to start building it sooner than later. 
  • Some tools, like Figma, have a built-in collaborative feature (that sadly Sketch still lacks), but Abstract also can be a great complimentary software for version control and storing files in the cloud. We export our design files to Zeplin for the developers.

Ideating and prototyping should be an iterated process, such as continuous discovery with user research beyond MVPs.

Product Designer Position Open


Launching the MVP product doesn’t mean the job is done, and the product design process is over. Testing and designing should be an ongoing, iterative process that is the key to improve the product and bring it to success. 

Follow along with the metrics; get client feedback, use analytic tools and heatmaps (such as Google Analytics, Countly, Hotjar), do A/B testing, and measure the success of your choices. 

As I mentioned at the beginning of this article, this collection of ideas and steps are not set in stone, simply aimed to raise awareness of the available tools and methods to start off a product design process. The whole process becomes super iterative when working in a dynamic environment, such as agile.

The main takeaways perhaps are to make your process user-centered, apply design thinking, and execute it as a non-linear, iterated process. Do user research whenever you can to design with the people, not just for them.

Take the next step to improve your website’s UX

UX studio has successfully handled 250+ collaborations with clients worldwide.

Is there anything we can do for you at this moment? Get in touch with us, and let’s discuss your current challenges.

Our experts would be happy to assist with the UX strategy, product and user research, and UX/UI design.

Anett Illés

Online marketer at UX studio.
Foreign-language learner, yogini, dog owner, volunteer.
I have an incurable case of wanderlust and a desire to help others.

Fruzsina Funtek

UX/UI Designer, functional design believer, amateur poi juggler, music and expressive dance lover.