The product design process is the sequence a team follows to turn a market problem into a working digital product. Ours is called the Product Design Process (PDP). It runs across four phases (research, ideation, execution and technical assessment) split into twelve steps, each with a named owner and a deliverable the next step depends on.
Think of it as mise en place. Everything chopped, measured and within reach before the pan goes anywhere near the heat.
This post explains what product design is, why the sequence matters, and what happens in every one of the twelve design process steps. It is written for founders, product owners and executives deciding how much design work to fund before a line of code is written.
We are not keeping the method to ourselves. It is published in full, with every phase and worked examples, in our Product Design Process book, written by three of the people who built and run it at Imaginary Cloud. What follows is the working version of that method, the same one behind our digital product design.
Product design is the work of deciding what a product should do, for whom, and how it should behave, before anyone builds it. In the PDP, that work produces twelve named deliverables, from a user profile to a project plan with costs attached. (See our short definition of the product design process.)
The term often overlaps with industrial product design, which covers goods made through mass production: an iPhone, a toaster, a guitar, a chair. This article is about digital product design, a subset of it. A digital product is an intangible good set online, like a website or an app.
So is design about how a product looks? Not mostly, no. Aesthetics matter, but design is mostly about how the product works.
That distinction has a practical consequence. Steps 1 to 7 of the PDP, more than half of it, produce no visual design at all. They produce a user profile, a benchmark, a journey, a prioritised scope and a wireframe. Only then does anyone choose a colour.
The product designer works out which users the product serves and what they are trying to do, then turns that into something usable. The first step of the product design process is identifying the end-users' problems, which is why user research is step 2 of the PDP and not a screen.
Knowing who will use the product matters as much as knowing what problem it solves. The same problem gets a different answer depending on who has it.
The title covers several job functions. A UI developer, a UX designer, an interaction designer, an experience designer and a prototyper all fall into the category of product designer. Different companies draw the lines differently, which is why the PDP names an owner for every step rather than trusting job titles to do it.
Building the wrong thing well is the most expensive outcome available to a product team. It is also the one an unstructured approach produces most reliably.
We know because we did it. The projects described below shipped on time and to specification, and still failed in the market, because nobody had established what the market wanted before the build started.
Design is what closes that gap. Doing it properly takes business analysis, user research, an understanding of how people actually behave, and enough software knowledge to tell a good idea from an expensive one.
The reverse case is just as concrete. An app can rest on a genuinely clever idea and still fail if the navigation confuses people, the experience drags, and the end-user cannot manage it. A great idea will never be more than an idea if the product design does not meet the end-users' wishes.
Let us share a bit of Imaginary Cloud's history. Back in 2014, we designed a service called "The War Room". The promise was to put a product owner, a designer and a dev team in one room for three days to deliver an MVP (Minimum Viable Product).
The results were uneven. We delivered a few projects, but they all failed on the first market approach. The era of "if you build it, they will come" was long gone. The Lean Startup and the Google Design Sprint were on everyone's bookshelves and bookmarks, but neither was enough on its own.
At that moment, we realised that digital products need considerable research before being built. And no documented design process was available for us to use. So we built one: the Product Design Process (PDP).
The PDP is a collection of existing techniques, matured over time by the industry and chained together so that the product design team's workflow is as efficient as it can be.
To this day, our Product Design Process remains at the core of how we deliver digital products, and it is the process behind every project in our portfolio.
The Product Design Process (PDP) is a user-centred design process for digital products, and it follows a multidisciplinary approach. Its main goal is to get products to market quickly without skipping the evidence that should be holding them up. It works just as well on projects chasing growth through optimisation.
Our vision is simple. We want to deliver the best available solution to a specific problem, in a market where most competing products are shipped without one.
The first phase of PDP is the UX designer's responsibility. The objective is to gather evidence that will support every decision taken from here on, so that none of them rests on a vague assumption. This is where the main aspects of the business model and the user needs are identified.
1. Briefing. Assures that the whole team is on the same page and has all the relevant information: the project's vision and goals, as well as the business requirements.
2. User Research. The users' profile is discussed with the product stakeholders. Defining the target users' profile helps to identify their main goals and motivations. User research guarantees product usefulness and effectiveness from the user's perspective.
3. Design Benchmark. The team reviews similar and complementary products, the design patterns they use and the technologies behind them. That review shows where the new product can sit in the market, which conventions users already expect, and which features and design decisions would genuinely set it apart.
Ideation is the core of the creative process. It is where the concept of the product is formulated based on the user's needs and the business model, both identified in the Research phase. Here, the UX designer, the product designer and the product owner should work closely together.
4. User Journey. The ideal user experience is mapped by describing each user action. Various user scenarios are written and validated. It provides a global vision of the experience, ensuring consistency and fluidity, and serves as a base to establish the product requirements.
5. Decision Matrix. The decision matrix scores each candidate feature on two axes: how much it matters to the user and the business, and how much time and money it costs to build. What survives the scoring is the scope that can realistically ship within the constraints, at the product's current stage of life. What does not survive gets written down rather than forgotten.
6. Wireframes. Here the skeleton of the screens starts being drawn. The page structure and navigation flow are settled, which fixes where each piece of content lives before anyone styles it, and shortens the design work that follows.
7. Mood Board. Assures that the product's look and feel conveys the desired experience and is aligned with the user profile and market strategy. This step captures the product's "mood" through a collection of pictures, words and other visual elements.
In this phase, the product designer turns the concept agreed so far into screens people can actually look at and click through.
8. Style Guide. This is where the graphic interface gets its rules: colour palette, fonts, image style, input fields, buttons, and so on. Fixing those choices once, in one document, is what keeps every screen in the application visually consistent with the next.
9. Graphic User Interface (GUI) Design. The end-looking screens are executed by applying the Style Guide to the Wireframes. The ninth step gives stakeholders the final aspect of the product's screens, so they can approve it before implementation begins.
10. Prototype. A click-through prototype is developed, accessible online and shareable with other devices and users through a link and password. It allows navigation from screen to screen, which makes gathering feedback straightforward, whether from stakeholders, potential users or investors.
The main goal of this phase is to guarantee that every requirement and idea generated is realistic to implement, and achievable within the time and budget already set.
11. High-level Architecture. This step develops the technical design with the right balance between complexity and reach. It is also where external dependencies from third-party providers, such as Stripe for payments, Meta (Facebook) for authentication, or Amazon Web Services for hosting, are identified. It details how the product will be built, and which technologies and skills it will take to build it.
12. Project Plan. The last step defines the major milestones and gives a general understanding of the project's structure, phases, intersections and interdependencies. You end up knowing how to build the product, how much effort it will require, and the expected costs for each phase.
It is crucial to respect the order in which the phases are enunciated. The outputs of earlier phases are a requirement for the stages that follow. It is common practice in design to run several tasks at the same time; across phases, that does more harm than good.
Following the PDP brings a set of benefits compared with unstructured approaches. It reduces the time and cost spent on product design and development, it makes realistic schedules possible to plan, and it leads to a higher-quality product.
The reason is a cost curve that is well documented in software economics, though it is worth being precise about it. Boehm and Basili's peer-reviewed review of the field found that a problem caught after delivery can cost far more to fix than the same problem caught during requirements and design: for large, high-dependability systems, on the order of 100 times more (Software Defect Reduction Top 10 List, IEEE Computer, 2001). The exact multiplier is contested and depends heavily on the system: Boehm's own later work put the ratio closer to 5:1 for small, agile projects with continuous integration, which is nearer the profile of most digital products. The direction, however, is not in dispute: the later you catch a design or requirements problem, the more it costs.
The macro figure has been updated since. The US National Institute of Standards and Technology's 2002 study put the annual cost of inadequate software testing infrastructure at around 59.5 billion dollars. Two decades on, the Consortium for Information and Software Quality (CISQ) estimated the cost of poor software quality in the US at roughly 2.41 trillion dollars in 2022, of which about 1.52 trillion is accumulated technical debt (The Cost of Poor Software Quality in the US: A 2022 Report). The shape of the answer is the same, at a far larger scale: quality problems are cheapest to prevent early.
Design decisions behave the same way. Changing a wireframe costs an afternoon. Changing the same decision after the interface is built and shipped costs a release. Choosing to design by process rather than by improvisation is what keeps those decisions at the cheap end of the curve.
You cannot generate good ideas without understanding the problem at hand. And you cannot execute without understanding what needs to be built. Every time a new idea is prototyped on top of immature requirements, a great deal of what was already done has to be rethought or redesigned.
Forcing a complete rework will, at best, leave you with a product that looks patched rather than built as an integrated whole. That is why breaking the process into phases and steps in a defined sequence matters so much.
Respecting the order of the phases is essential, but within each stage you will find several steps that can run at the same time. That flexibility lets you accommodate different project characteristics and team preferences without compromising product quality, the timeframe or the budget.
Need to build on an existing product? Go back and revisit the earlier phases and steps. If new feedback has to be integrated into a prototype, the team should return to those earlier stages before making the changes. Making changes in the final design is always far more expensive than adjusting at each step as feedback arrives, which is why good communication carries the whole process.
During the process, in each step, there should be at least three points of communication: an initial workshop; a status update when the step's execution is at its midpoint; and a final meeting to validate the step.
Between checkpoints, the team should stay on the step in hand, without additional input that causes unnecessary diversions. At each meeting, the team should always have added value to contribute, and feedback to gather.
Following the same idea, if the product owner is not available for the midpoint status update, the team should start the phase's remaining steps rather than let the project stall. Constant communication with the product owner is a critical requirement for the success of PDP: it is what allows short cycles of feedback and, with them, short execution times.
To see our product design process in practice, take a look at our TravelWifi case study. TravelWifi is an e-commerce platform that provides portable internet solutions. Our mission was to visually reflect the several products the platform offers and match users' expectations by guiding them through a smooth, easy journey across the platform. The case study sets out the research, the interface work and what shipped.
To find out more about how we apply our product design process to our projects, feel free to visit our portfolio.
Once PDP is completed and the first version is launched, the product still needs improving, following a design, build and learn cycle. These post-launch changes are usually different from the ones identified while the prototype was being developed.
They tend to be small details drawn from users' feedback, with a low risk of compromising the existing graphic user interface design. That is the point of the twelve steps. The base is already settled, so what follows is refinement rather than rework.
Most steps do not require previous specific knowledge, but mastering PDP is easier if you do additional research and collect as many references as you can. The main advantage of applying PDP is that it makes the importance of each step and its deliverables obvious, which is what stops teams jumping into the later phases without the bases to support the choices they are making.
PDP is now a stable process, though never a finished one, because product design keeps moving. We will carry on updating it as necessary, integrating new tools and techniques that improve how the whole thing performs.
For a typical digital product, the twelve design process steps run over several weeks rather than several months. Research and ideation usually take the longest, because they set the requirements every later step depends on. The duration scales with the number of user journeys in scope, not with the number of screens.
UX design covers how a product behaves for the person using it: research, journeys, wireframes and usability. Product design covers all of that plus the business model, the visual interface and the technical feasibility of what is proposed. In the PDP, UX design owns the research phase and part of ideation, while product design owns execution.
Cost depends on scope, but the useful comparison is not design against no design. It is design against rework. Step 12 produces the expected cost for each phase before any implementation starts, so the budget conversation happens with evidence rather than with estimates made in the dark.
Not without paying for it. Each step's output is the input to the next: user research feeds the user journey, the journey feeds the decision matrix, the matrix feeds the wireframes. Skip a step and a later one runs on assumptions, and assumptions surface as rework once the interface is built.
Yes, within a phase. Several steps in the same phase can run at the same time to fit team availability. What cannot be parallelised is the phases themselves, because each one depends on the deliverables of the one before it.
A UX designer leads research and early ideation, a product designer leads execution, a tech lead runs the technical assessment, and the product owner turns up at three checkpoints in every step: an initial workshop, a midpoint status update and a validation meeting.
Yes. For a product already in the market, the process starts from the phase that holds the decision you are revisiting. Adding a feature usually means going back to user journey and decision matrix. A redesign usually means going back to design benchmark and mood board.
Twelve, one per step: a briefing, user research, a design benchmark, a user journey, a decision matrix, wireframes, a mood board, a style guide, GUI designs, a click-through prototype, a high-level architecture and a project plan with milestones and costs.
If you are weighing up how much design work to fund before development starts, we are happy to walk through the PDP against your own product and tell you which phases matter most for it. Get in touch, or read more about our digital product design and web application development work.
You can also read the whole methodology in our Product Design Process book. It describes every phase, with practical examples and what you should have by the end of each step. You can order it directly on Amazon.
Content manager, text editor, and presenter of strategic ideas, along with being an avid fan of the cinematic arts and visual storytelling.
Marketing intern with a particular interest in technology and research. In my free time, I play volleyball and spoil my dog as much as possible.
CEO @ Imaginary Cloud and co-author of the Product Design Process book. I enjoy food, wine, and Krav Maga (not necessarily in this order).
People who read this post, also found these interesting:
