“I don’t get it; we’ve spent millions implementing a new system, so why aren’t we seeing improved efficiency and higher user satisfaction or the ROI that we were expecting?”
“We have so many problems to fix; where do we even start?”
“What aren’t people following the processes?”
If you’ve ever wondered about the answer to these questions, you aren’t alone. In fact, so many others have found themselves asking these questions the Explore Phase in design thinking was created as a catalyst to find the answers. Exploration is valuable since it provides designers with the opportunity to talk to end-users and learn about their work processes to identify what the problems are to then solve them in future phases. This blog post will explain exactly what the design thinking explore phase is and how it can be applied to your business transformation.
When to Use the Explore Phase in Design Thinking
The Explore Phase in design thinking is used when your business hasn’t yet defined the problem. For example, your business currently has many processes in the Procure to Pay (P2P) space that are manual, time consuming, and teams just aren’t following. There are so many areas that need to be investigated either in the up-front procurement or downstream in goods receipt and you don’t know where to start. In the Explore Phase, the design thinking team will uncover what is causing difficulties for the end users in the process. Through this, we can then identify and prioritize key initiatives to generate improved processes and return on investment (ROI).
Explore Phase Process
As part of this phase, design thinking leaders will help businesses determine what initiatives are in alignment with their corporate strategy. Here is what designers do in the Explore Phase in design thinking.
Long Term Goals and Key Initiatives
With the long-term strategy of the company in mind, it is crucial for the team to begin a discussion on the mission and vision of the organization. From there, strategic initiatives – what brings these goals to life – can be considered. Strategic initiatives typically speak to the vision, the benefits to the stakeholders and the work that is being done to grow the company and align various interrelated projects. Taken together, the long-term goals and key initiatives should act as the foundation for the next steps in the Explore phase.
Impact Effort Matrix
Next, brainstorm key initiatives and pain points. These initiatives are then placed on an effort-impact matrix. This matrix helps design thinking participants to categorize the critical initiatives into four categories:
-
Strategic initiatives: Big projects that require lots of effort but will produce a high ROI
-
Low-hanging fruit: Small projects that require minimal effort but will produce a high ROI
-
Maybe later: Projects that don’t need a lot of effort and will not produce a lot of ROI
-
Write-offs: Complicated or lengthy projects that will not produce a lot of value
The matrix is then seen as a valuable decision-making tool to optimize limited time and resources that can help align the project team's priorities. Depending on your business, this might look slightly different and can be altered to create a comparison between complexity and business impact/value. This step helps to determine which priorities should be tackled first. However, in cases where all initiatives are seen as high effort and high impact, a design thinking lead may ask additional questions to determine their relative order and importance.
Stakeholder Mapping
Stakeholder mapping is the visual process of laying out all affected stakeholders for the project on one map. This presents a visual representation of all the people who can influence and impact project progress and how they are connected. Each project will have internal and external stakeholders. These stakeholders must be identified and kept in contact with appropriate to their role. Depending on the project's complexity, the stakeholders may also need to be “prioritized,” which can be done with a power level of interest matrix.
Define Roadmap
A project roadmap provides teams with a high-level overview of the team’s goals and deliverables with rough timelines of when activities should be completed. This is not to be confused with a detailed project plan, which goes into a detailed breakdown of who is working on what and when. The when might be challenging to answer and could be a point of discussion amongst the team members in the design thinking workshop to determine if resources can support the initial timeline. The roadmap can be referenced by other teams within a business to track the overall progress of the team’s initiatives. Project managers can then use the roadmap to break down strategic goals into day-to-day tasks for the project team.
For accurate roadmap creation, it is encouraged to consider the technical dependencies in the project. To do so, teams may start with a high-level picture of the target architecture, including all core functional components and user roles in the system. Next, users can begin to outline their current state, including what systems are in place. From there, technical dependencies can be determined, providing project leaders with a technically accurate roadmap for the duration of the project.
Action Items
Finally, teams will consider the various items on the roadmap to the highest impact and consider the complexity of each step. In most cases, the top three can be selected to break down into tangible next steps, and names can be assigned. We believe this is always one of the best ways to end a design thinking session since team members understand exactly what to do next without feeling overwhelmed with all the information gathered.
Many have found participating in this phase of the design thinking process to be helpful. From a recent workshop conducted by the ConvergentIS team, users shared positive feedback stating, “I liked having an opportunity to listen to the challenges,” and the “candid conversation and focused engagement” helped achieve their end goals. This workshop typically takes about four hours in a low-touch scenario but may take longer depending on the level of technical detail that is required for your team.
This post on the design phase is the second in our design thinking in practice series. Read the first and the next post in the series.
Or, jump ahead and download the full guide below.