December 10, 2019

Design thinking in the product development process

Design thinking is a non-linear process that gives teams the tools to understand users’ needs, wants, and team assumptions to create solutions that can be prototyped, tested, and eventually materialized into a product. 

The design thinking process has become popular with teams over the past few decades and has been highly adopted by companies like Google and Apple. In simple terms, it is a process to solve problems in a human-centric way by allowing teams to focus on what is most important for users.

Despite its popularity and effectiveness, it is hard for teams to shift traditional waterfall thinking about design and problem-solving. Particularly, teams have a hard time understanding how to use the process and where to include other members of the team.

In a waterfall approach, product managers spend time to understand the problem, the business case, use cases, and the solution. It is after those steps that designers are included in the process to materialize the idea into deliverables such as visual designs. While this process solves the problem, it is my experience that many times it leads to incomplete, difficult use solutions. It also misses the value the design process brings when used with a cross-functional team to create better solutions for users. 

Working with product managers over the years I have come to understand that it is not that they don’t understand the process or that they don’t see the value, rather, it is the understanding of when to include team members in the six steps. 

The rest of the article is my attempt to take the six steps and align them with the different skill sets of team members. While you can include the entire team in these steps, I understand that it is not feasible for many teams. Jake Knapp in his book Sprint, takes these steps and cramps them into a one week block. He makes a good case for why you should include a cross-functional team in all the steps, but the process is flexible enough to allow teams to benefit from it and adopt a version that best fits their team. 

While reading through the different steps imagine your goal is to improve new users’ profile set up. Keep in mind that my examples are based on a team that works on a software product, but the principles still apply. The process is also not limited to products. It can be used to improve product support or services offered by a company. 

Empathize

This phase is about developing knowledge of what users do, say, think and feel. This phase can be done primarily by the product team with consultation from designers, sales, support, marketing, and engineers. This is where teams would directly observe what users do and ask questions like what motivates or discourages them. Teams at this point are trying to identify the pain points in the current process users follow. It is important to document the findings to carry them over to later steps. Teams can document facts, assumptions, and opinions on sticky notes, a whiteboard, or anywhere else that these ideas can easily be seen by the team. 

Define

With all the research data from the empathize step, teams can begin to identify opportunities in the process where they can innovate. At this point, the focus is not to come up with solutions. In our user profile setup example, think of what are the common pain points the team saw across different users. This step can be conducted with a broader team in the room and at the same time as the next step. Consider including designers, engineers, support, marketing, and sales if possible. Depending on the difficulty of the problem, designers and engineers may be enough. Teams can choose a set of skill sets that best fit their process.  In my experience in this step and the next, the more representatives from other parts of the business are involved, the more wholistic the solution will be. 

Ideate

Once teams understand the users’ needs and have identified areas to improve, teams can begin to explore solutions to solve the problem informed by the research. Ideas can come from anyone, not just designers or product managers. Anyone can wireframe an idea and share it with the team. The goal in this phase is not to scrutinize ideas on why they would or wouldn’t work quite yet. The goal is to come up with several feasible solutions that solve the problem. Once multiple ideas are in front, then the team can go through the process of identifying the pros and cons of each solution. A good result would be that in the end, one idea wins as a favorite of the team. This usually tends to be a mix of all the best parts of the ideas presented. In this step, you want to have everyone in a room. Include different members with different functions in the product development process as well as members of outside groups if it makes sense. Support can usually provide good feedback and whether an idea will help based on what they hear from customers during support calls. 

If there is more then one good idea considered as a possible solution that is also fine. The next step is to build a testable prototype. 

Prototype

Depending on what kind of product your team is working on, it will require different skill sets to build a testable prototype. In this article, we are focusing specifically on software products. The designer would be the primary member responsible for putting the testable prototype. The goal of this step is not to build a high fidelity prototype. It needs to be finished enough to communicate the intent to the user. It can be in the form of a Powerpoint presentation, an InVision wireframe. It needs to feel as real as possible without spending so much time on it that it cost too much to build. It has to be built with the idea in mind that it might be discarded because it was the wrong solution. This is a hard concept for teams because they may have invested so much time into it. That’s why it’s best to not build high fidelity code prototypes unless they are proof of concepts that eventually will become part of the implementation.

Test

The testing step is about putting your prototypes in front of users. In this step we are looking for the answer to the question ‘Does the solution meet the needs of users?’ Anyone can observe a usability test, but only one person should speak and moderate the interview. Everyone else should be in a separate room observing and taking notes. The goal is to test the solution, not make users feel like they are being tested or interrogated.

Implement

The final and the most satisfying part of the design process is the implementation. After all, this is the reason teams go through the process. To deliver solutions. In software development, this step is usually performed by engineers. It is an important step because teams want to make sure that all the research and effort that went into finding a solution is not missed or discarded. Introducing new concepts without going through the process again leads to hard to use products and more pain points.

Conclusion

In his book Sprint, author Jake Knapp provides a step-by-step process to cramp these steps into a one week block. Whether your team can do that or not, the goal is the same, to build products that are centered on the users’ needs and build them in a way that reduces the cost of doing so. The process is non-linear. Meaning that if at any point discoveries happen, the team can return to any of the previous steps and rethink the problem, assumptions, and the solution.