Design Thinking Frameworks

12 June

I remember a time when a boss said to me, “I’ve been reading about Design Thinking, and from now on, we’re going to apply design thinking to how we do our work.” I thought, “Oh no, he’s read another blog entry and he’s going to start micro-managing the design team.” So I immediately called up my friend Google and asked the standard Google question - WTF?  

What I discovered was that a prediction from the 1960s - that analytical thinking and “creative” thinking would eventually join together - was finally becoming real. Various studies were showing how analytical ways of looking at things and “designery” ways of looking at things were very different, but that both were needed to come up with the best solutions. 

I tell my Agile Fundamentals classes that one way to think of Design Thinking is that after many years of The Business and The Tech Folks coming together to solutionise a problem (and then sending it to design for a beautification pass), we’ve now added a chair at the table for The designers right from the beginning, recognising that designers are problem-solvers in their own right. When all three groups work together using some sort of Design Thinking framework, the best work gets done.


Design Thinking Frameworks

For a graphical representation of these approaches, do a google images search for “Design Thinking”. You will see a wide array of diagram structures, from linear to circular to looping, and from simple to chaotic and confusing. What you’ll most commonly see is the Stanford’s 5-step pattern or variants of what’s called the Double Diamond. What I wanted to talk to you about in this blog is the pattern underneath all of these frameworks, and how this pattern works for an agile team, especially in the early stages of a project, whether it’s a huge project or something smaller, like a new feature or change for an existing app. 

Stanford has labelled the 5 steps in their design thinking framework Empathise, Define, Ideate, Prototype, Test. I’ll expand on these in a minute, but I also want to note that Google Ventures has adapted this approach to develop its famous Design Sprint process. This 5-step process uses the labels Understand, Sketch, Decide, Prototype, Validate. Similar enough that we can call them the same framework. Let’s walk through the steps and look at why this system is so productive. 

Although what’s called a Design Sprint is built around a 5-day sprint concept, the process can be run in 5 hours, 2 days, 5 days - whatever size is appropriate to the problem being addressed. So adapt what I’m going to describe to the size of your problem.


Design Sprint Format

Day One - Understand. This is all about learning about the problem, not solving the problem. Really - 20% of the time is devoted to a full 360 degree examination and analysis of the problem. This is done from multiple perspectives, and it involves presentations of facts, opinions, and current situations to help the solution team get fully up to speed in understanding the problem. Business people highlight their views and needs. Users might be interviewed to showcase challenges they have with what you’re working on. Owners of the existing technical systems present the challenges and opportunities of what the team has to work with. The solution team does little talking in this phase, other than to ask clarifying questions. I’d say that Stanford’s Empathise and Define stages are included in this Understand step. 

Day Two -  Sketch. The team spends this day in pure blue-sky creative expansion. This is the “there are no bad ideas” phase of brainstorming and concepting. If you google Design Sprint Kit, you can download a guide that explains a lot of really productive methods for getting this day to work well. Practices like Crazy 8s, silent/talking alternation, dot-voting to focus group analysis are explained in ways that help groups new to this way of working. This is Stanford’s Ideate phase. 

Day Three - Decide.  All the best ideas from the Sketch day are reviewed. Agreement is reached on which ideas hold the most promise for solving the problem. Key stakeholders may be brought in for observation and perhaps more clarification. Now another round of creativity takes place, but this time the work is not the expansion activities of the Sketch day. It is a contraction to a defined hypothesis for solving the problem. A plan is created for a prototype that will be built the next day. The Stanford model does this Decide step as a final part of their Ideate phase. 

Day Four - Prototype. Build the most functional version of the solution that resources allow. It could be a hacked code mockup using dummy data, or it could be a paper prototype that you can walk users through to test screen flow or interaction design. The more user-driven the prototype is, the more you’ll learn. 

Day Five - Validate (Stanford calls it Test). Put the prototype in front of users. Use an experienced user testing facilitator who will draw out of unconfident test subjects a wide range of useful responses. After a few test subjects have tested the prototype, the team analyses the results and comes up with one of two outcomes - “we solved the problem” or “now we know how to solve the problem.” 

That’s right - both outcomes are deemed a success; neither is a failure. And this is where the design framework diagrams get messy. They try to illustrate the iterative, recursive, looping nature of the design process - going back to the Sketch phase, changing that one failed element of the prototype, or even returning to Understand to see what it was that they missed as they tried to define the problem itself. 

But this basic pattern works. Learn as much as you can before you start designing. Come up with a bunch of ideas to address the problem. Combine the best ideas into a hypothesis. Prototype and test the hypothesis. Rinse/repeat as needed.


The Double Diamond 

Another design process framework you may run across is the Double Diamond. Developed in 2005 by the British Design Council, this is a 4-step process with the labels Discover, Define, Develop, Deliver. It is called Double Diamond because it looks like this:


 Double diamond


The idea is that, moving left to right through the diagram, the team expands - builds their knowledge and then brainstorms. This is followed by contracting to one concept proposal. This if followed by another expansion - building the concept out. And finally a contraction to either a resolution or new understanding of how to better address the problem in another iteration. Pretty much the same idea as the 5-steps processes.


Six Thinking Hats

I’ve been using Edward de Bono’s Six Thinking Hats process since it came out in the 1980s, and it is great for tackling big knotty problems, especially with larger teams that are not experienced in brainstorming etiquette. De Bono defines six forms of thinking that should be employed as we go into a problem-solving process. He uses colour to help us frame the thinking.

  • White - just the facts. The data and research needed to Understand the problem.
  • Yellow - optimism. In what ways are we confident we can address this problem? How will the world be better once we have solved the problem?
  • Red - emotion. How do we feel about this problem? Do we fear some possible solution approaches? Why do we feel strongly that we must do something about it? Are we already attached to a solution approach? Everybody lays their cards out face-up so we can be honest about the emotional aspects of working together.
  • Black - critique. This is the time to poke holes in other viewpoints or in the ideas that are developed.
  • Green - ideation. During this phase we brainstorm solutions.
  • Blue - synthesis. Here we make decisions, action plans, move things forward.


It should be obvious that Six Thinking Hats and Design Thinking share a number of attributes, but here is the key distinction and value of this Six Hats approach. When we are workshopping, we all put on the same hat at the same time. During an initial Understanding phase, we are all wearing our white hats, gathering and sharing facts. No criticism, no arguing, unless a fact is in question. We wear our yellow hats together to build a group-wide positive attitude toward solving the problem. We wear our green hats together in the “no bad ideas” phase of work. We review our ideas by alternating between yellow hats (“let’s identify what’s working here”) and our black hats (“let’s all feel free to criticise what’s not working here”). This structured approach takes advantage of those among us who so often say, “Playing devil’s advocate…” but limits their input to appropriate times in the discussion. It also challenges them to look for the positives, and it encourages the Pollyannas among us to apply more critical thinking to what might appear at first glance to be a good idea.  And finally, we all put on our blue hats to pull everything together, make decisions and action plans. 

When a group gets this Six Thinking Hats way of working together (and critique etiquette) under its belt, it can permeate the way that the group works the other design thinking frameworks to produce more focused discussions in their workshops.


Some Tips for Design Thinking Workshops

Design Thinking is multidisciplinary. I’ve had trouble getting some business or technology people to attend a workshop with the word “design” in the meeting title. (“I don’t have a creative bone in my body.” “I gave you the requirements. What more do you need from me?”) If that’s the case, then call it something else - problem-solving workshop, multi-disciplinary workshop. But whatever you do, call it a workshop and not a meeting. People loathe meetings because they famously get nothing done. Workshops are about getting s*** done. This gets people into the room in the right frame of mind. 

Get the right people in the room. The Understand phase needs the stakeholders and users to present the problem from their perspective. They don’t need to be involved from beginning to end, but they need to set the stage and to be available as the process moves forward and discovers new wrinkles that weren’t apparent in the Understand phase. 

Work with the right number of people. We all know that a room of 20 people is not going to have a quality brainstorming session. Too many people. A good team size for brainstorming is 3-7 people. Smaller than that may not include enough perspectives, and larger than that gets unwieldy. When I do need to include more people, I break the group into smaller teams, but still multi-disciplinary. Alternate between working in small groups and presenting their results to the larger group. Use both competition and idea-stealing/combining to drive the energy in the room. 

Use an experienced facilitator. There are many methods and exercises that a facilitator will know to use to help the group work in a somewhat structured manner. Creativity is a messy process, and if managed poorly, you can spend hours chasing down rabbit holes, going in circles, diverging when you need to be converging. A good facilitator will recognise when it’s time to let things go and when it’s time to put a lid on non-productive tangents. They will also know how to keep the group buoyant as it gets hit with the common brainstorming frustrations of chaos and a seeming lack of progress. 

I hope you have found something to apply to your next problem-solving challenge. If you would like some facilitation assistance or an introduction to Design Thinking, please get in touch.  


Post by Jim Simmons