Design Thinking in Software Development: Improve your Software Delivery in Five Easy Steps

For organizations currently employing or planning to employ Agile frameworks such as Scrum or Kanban, one of the most common problems teams face is uncertainty when embracing new features like Design Thinking. 

Design Thinking is a lean methodology wherein teams can define or further clarify user needs and transform them into proposed solutions. Through prototyping, brainstorming sessions, and testing, Design Thinking helps teams overcome uncertainty when facing new features. In this blog, we will cover the five stages of Design Thinking and how DevOps teams can improve their software delivery. 

Based on the model presented by the Hasso Plattner Institute of Design at Stanford, the Design Thinking methodology includes the following stages: 

1. Empathize 

In terms of software delivery, we often need a defined set of requirements in order to fully understand what needs to be built. However, we constantly face the common interaction with a customer who doesn’t understand what they really need. The first step of the Design Thinking process is to try to see through the eyes of the final user in order to determine what they consider as a need to be satisfied; this is what we call empathy. 

Creating empathy helps teams to not only understand what is needed in terms of delivery but also helps with understanding the users themselves. The perception of things may vary according to personal, emotional, and physical states. Therefore, it’s highly recommended to first understand the user’s current experience and what they expect to achieve. By applying this mindset, you will gain a better understanding of the true need based on the user experience. 

One of the most popular tools used to generate empathy is the “5 whys method” created by Toyota founder, Sakichi Toyoda. By using this method, you are able to identify the root cause of a problem by posing the simple question “why,” five times. First, you start by asking “why… the problem identified.” This will create a root map with several levels that will help you pinpoint the root cause of the main issue. 

2. Define

Once the empathy phase is completed, the next step in the Design Thinking process is to define the problem statement. This kind of statement contains the following attributes:

• A human perspective: This means it’s based on insights and needs of a person’s perspective and not based on a single point of view.

• A defined scope: Similar to projects, the scope helps us gather enough information to apply proposal solutions with enough freedom, in terms of creativity and implementation, and limit the range of impact.

• A verb: A good problem statement always contains a verb that identifies the action the person is doing or requires. 

• Achievable without assumptions: Include the whole team when defining the problem statement in order to remove any doubt or assumptions regarding what the team is looking to achieve. 

In DevOps, teams often refer to the problem statement as “the point of view,” due to the ability to identify specific users of an application or part of a software. 

With the problem statement definition, teams’ decision-making will be more engaged with the stakeholder’s expectation in terms of delivery. This provides guidelines during the decision-making process or when the team starts working on the implementation of a solution.

3. Ideate

Once you have established empathy and defined the point of view, it’s time to start generating ideas outside of the box (or what some call the comfort zone). In this zone, people start seeing things outside of their common and regular views, adding ideas from their experiences or perspectives.  

Due to the kind of response we are hoping to achieve, teams must provide never-seen-before solutions in order to solve the problem. Many times, traditional solutions might help solve a problem. However, these serve as temporary solutions, as they only focus on solving singular symptoms instead of the root cause. 

There are thousands of ideation techniques, some of them similar in terms of the main goal of each exercise. For that reason, we will focus on the most common and easy to implement: the brainstorming session. The brainstorming session may include the technical team, stakeholders, and even some final users to share their experience as part of the final behavior of the product.

To have a successful ideation stage, we should have:

• A set limit of time to discuss each section (a good brainstorming session must be under a timebox structure). 

• Constant visibility of each idea, most importantly the problem statement, as the base of the session. 

• Leave ego and criticism outside of the room, as this session is intended to improve creativity and unexpected reasoning. The best ideas often come after a crazy one, which is where we want to guide the team during this session.

• Quantity over quality. In this case, we want to provide all possible ideas. It doesn’t matter if it’s hard to implement or too expensive, we can start building new ideas from the ones we start with.

• Somewhere to write. Ideas can come on in the most unexpected ways, so it’s important to have a place to write your ideas down so you don’t forget them.

At the end of the session, the team can create a cluster of ideas in order to identify the most feasible ideas and the ones with the most impact in terms of the problem statement solution. It’s important to mention that there could be more than one idea that we could materialize as a “prototype.”

4. Prototype

The fourth stage of improving your software delivery with Design Thinking is more experimental than the others. Here, the team designs prototypes or low-cost investment features in order to create a functional solution to mitigate the problem identified. Once these prototypes have been tested, teams can review the results based on user experience feedback. 

This feedback is the first input required to start creating new prototypes in order to redefine the new proposed solutions. As we saw in the Hasso Plattner Institute of Design at Stanford, Design Thinking is not a sequential methodology. The ability to go back to previous stages helps the teams to identify whether the current approach is giving enough benefits or if they should improve the proposal with new ideas. 

The purpose of creating these prototypes is to gather as much data as possible, not only in terms of problem-solving, but also in implementation, application, and experience from the users. This data will eventually be transformed into new ideas or even new points of view, making more reasonable the idea that Design Thinking methodology doesn’t require a linear approach.

5. Test

The last step of this non-linear approach is the testing of the prototypes. As we mentioned before, the design team works with different types of possibilities to test the behavior, results, and impacts the prototypes may have in relation to the problem statement. 

In software delivery, the testing phase of Design Thinking will guide the team to identify whether the requirements defined were achieved or if there is any improvement opportunity. The loop is constantly passing from the ideation through the prototype due to the testing stage. This is a key stage in the Design Thinking process, wherein teams can apply continuous improvements and integrations to their project, adding further value to previous features and, at the same time, creating new ones. 

To summarize, Design Thinking is another excellent complement for Agile software development and a great way to improve software delivery due to the capacity to harmonize creativity, implement new requirements, problem-solving, and discover new improvement opportunities. Based on the model presented, DevOps teams can be more engaged due to the capacity to empathize, define and re-define human-centric problem statements, and ideate prototypes of the points of view presented. This gives the Agile team the opportunity to focus on problem solutions better aligned with the user experience and the effectiveness in terms of impact, feasibility, and satisfaction from the final user of their software.