No products in the cart!
Please make your choice.View all catalog
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.
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.
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:
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.
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.
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:
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:
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.
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:
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.
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:
[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.
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.
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.
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:
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.”
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.
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.
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.
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.
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.
How we build prototypes:
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.)
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:
Ideating and prototyping should be an iterated process, such as continuous discovery with user research beyond MVPs.
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.
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.