Design Thinking at Cisco
I spend a lot of time explaining the value of design — the fact that design is not about pixels or mockups or wireframes. Design is about finding the right problem to solve, and then solving it in the best way possible.
Good designers are problem solvers. Great designers are problem finders!
This process of finding and solving problems is referred to as Design Thinking, and as part of the design transformation at Cisco we set out to create a design thinking framework would not only be used to up the game of our already amazing designers, but would also be something to enable the thousands of engineers who might not always have the benefit of working with a design partner.
The framework explained
The Cisco Design Thinking framework consists of three phases: Discover, Define, and Explore, and two guard-rails: Making thing and validating with users.
Lets take a closer look at the three phases.
In the first phase of Cisco Design Thinking, your priority is getting to know your users — with empathy.
By empathizing with users and truly understanding their core needs, current frustrations, and related pain points, you can uncover the valuable opportunities that drive true innovation.
We do this by immersing ourselves in the world of our user through research techniques like interviews and contextual inquiries. We interpret the information we are capturing through artifacts like Journey maps, empathy maps, and story boards. We aim to capture the current state of the world for our user, and then reframe the information in order to draw insight from it.
We document any opportunities using this standard format:
Once you have documented your opportunity, you and your team will likely identify many problems that will need to be solved. But which ones matter most to your users?
Your goal in this phase is to prioritize three — or fewer — clearly articulated problems that your solution will address on behalf of your users.
We use a template to capture these problem statements and they get amended to opportunity statement so that it looks like this:
Once the team has settled on their opportunity and problems statements, its then time to start creating solutions and for this we get into the explore phase.
You have a clear sense of who you’re building for, the opportunity at hand, and the key problems to be solved. Now it’s time for the team to start identifying creative solutions.
The key to the Explore phase is to ensure that the solutions developed explicitly solve the prioritized problems documented in the
I think of the explore phase as a continual loop of learning.
- We take a problem and begin by exploring as many solutions are possible.
- Pick the most desirable solution, and figure out how to quickly build an experiment that tests it.
- Run the experiment. Did is pass or fail?
- Continue to iterate on this one till you are happy at which point you can move onto another problem.
This constant looping of “build, measure, learn” is exactly what the Lean Startup methodology is all about. There is a lot of overlap between Design Thinking and Lean Startup and even Agile.
In fact the way I think about it is this:
Pulling it all together
All of these pieces of the framework come together and are applied first as a way to develop a high level direction for what we are doing, and then as a way to accelerate learning through the delivery of the proposed solutions.
Don’t look at the framework as a progressive linear process, but look at it as set of tools that you use depending on your current challenge. On any given project you will flip around between the different phases in order to achieve the outcome. The main things to remember are:
- Always make sure you are focussed on the right problem, before trying to solve it.
- Design thinking is a team sport. Collaboration with cross functional teams is critical to its success.
- When you are creating solutions, always focus on running fast experiments that answer what you need to learn, or validate assumptions you are making.
Supporting the framework
We have created a few supporting artifacts that enable the teams to practice this new framework. The most impactful artifact has been the field guide. This beautifully designed practical guide contains an explanation of each of the phases, along with lots of examples. The second half of the book is filled with tools and exercises that can be used along the way.
The Cisco Design Thinking framework is already being used by teams around the globe and is not just focussed on product development. We have executives, sales, HR, design, and engineering all using it to great effect.
Our next steps involve developing a learning framework around CDT that will allow us to train four different levels of Design Thinkers: Enthusiasts, Practitioners, Facilitators, and Coaches.
If you are interested in learning more about what we learned along the way, please don’t hesitate to reach out or leave a comment on this post.
Also, be sure to check out my previous article about why I chose to focus on why I chose Design Thinking for my team.