IntroductionDesign Process
An overview of the process used by product designers to identify and define problems, then explore and deliver solutions to those problems.
Michael Croft
July 24, 2022 · 5 min read
Overview
Product design is a non-linear, highly-iterative process. It often involves working with incomplete information and using feedback from one design to inform the next iteration — which may be in a completely different direction. Many frameworks attempt to capture this process:
- The Design Thinking framework breaks this process into six steps: (1) empathize, (2) define, (3) ideate, (4) prototype, (5) test, and (6) implement.
- Google’s Design Sprint Methodology defines six phases: (1) understand, (2) define, (3) sketch, (4) decide, (5) prototype, and (6) validate.
- The Design Council’s Double Diamond Framework divides the process into four steps: (1) Discover, (2) Define, (3) Develop, and (4) Deliver. These frameworks largely define the same process, with varying degrees of emphasis placed on particular steps. For example, Google’s Design Sprint Methodology specifically articulates sketching as a top-level step — whereas this would fall under ideate within the Design Thinking Framework and under Develop in the Double Diamond Framework.
I prefer the Double Diamond Framework because the diamond analogy better captures the divergent-convergent nature of the process. The first diamond entails divergent research to identify and understand a problem, followed by converging on a specific problem to be solved. The second diamond involves divergent design ideation and exploration, followed by converging on a solution through testing and validation. Accordingly, I’ll break down the product design process according to this model.
Discover
The first stage is problem discovery. This stage is divergent in nature and involves trying to understand the problem space and the range of use cases it entails. The goal is to empathize with the user and develop an understanding of their needs, goals, and pain points. This involves foundational research that includes talking with the actual users. This helps us avoid incorrect assumptions about the problem space, and validate that the problem we’re looking to solve is real. Skipping this step runs the risk of developing a product that no one wants or needs, resulting in wasted time and resources.
Define
The second stage is problem definition. This stage is convergent in nature and involves synthesizing the research and insights from the discovery stage into a clear problem definition. This should include a clear statement of both the user problem to be solved and the business opportunity. Although this stage seems simple, it is often overlooked, resulting in misalignment within the product team during the solution phases. Aligning on a clear, concise definition of the problem at this stage is, therefore, necessary to set the team up for success.
Develop
The third stage is solution development. This stage is divergent in nature and involves brainstorming and sketching a range of disparate solutions. Designers should be highly-generative in this stage, drawing inspiration from a broad range of sources. Once potential solutions have been identified, designers create rough sketches to provide more clarity and shape. It’s important to keep designs low-fidelity at this stage, as the efficiency encourages broader exploration, and the roughness discourages attachment to any particular solution. A common mistake is to go too high-fidelity too soon, which can cause an unconscious attachment to an idea before considering broader solutions.
Deliver
The fourth stage is solution delivery. This stage is convergent in nature and involves prototyping and testing solutions from the development phase to help identify the best option. This typically involves prototyping solutions and testing those prototypes with users to gather feedback without having to build the full solution. This allows product teams to more quickly and efficiently test concepts with fewer resources. Some solutions may be rejected and discarded entirely, whereas others may require a pivot in direction. This may entail adding or removing features, or making changes to the proposed implementation of those features to improve usability. In some cases, the feedback may warrant reverting to the develop phase to identify an entirely new range of potential solutions.
Another consideration at this stage is technical feasibility. Some solutions may address the problem to be solved, yet still be discarded during this phase if their scope is too large and ambitious. Other solutions may be stripped back in terms of functionality to fit a more realistic timeline. Ultimately a decision is made by balancing the effectiveness of solving the problem against the feasibility and timeline of building that solution.
Finally, once a solution has been identified, the product team will begin building that solution. However, a product designer’s work is not yet done at this stage. Designers must continue working with engineering to ensure the chosen solution is built to specification. This will often involve further iteration to address unanticipated technical challenges and making tradeoffs to improve the velocity of delivery. Following launch, designers should continue to monitor the performance of the shipped solution and gather feedback. This new information is then used to further iterate and identify new problems to be solved.
Conclusion
This process is rarely strictly linear, and will often involve moving back and forth between stages after receiving new information and user feedback. As a product designer, it’s essential that you become comfortable making decisions without complete information and remain flexible enough to pivot your designs as such new information becomes available. This will help you remain focused on solving the user’s problem, and avoid becoming attached to a particular design solution.
