Welcome to Design Thinking

Download the deck in PDF | Watch on YouTube

Transcript

Welcome to Design Thinking. Hi, I’m Coach Takeshi. In this short video, I will explain what is Design Thinking, how we do Design Thinking, and most importantly, why we do Design Thinking.

Let’s start with clarifying the difference between Design Thinking, Agile and Lean. Well, consider them all the same.

Technically they all come from different origins; Agile from the software development world in the late 90s, and Lean from Lean Manufacturing made famous by the Toyota way, and Lean Startup after the first dot-com bubble burst again in the late 90s.

But they are all models of a common purpose: to get “experimentation and iteration” right. They are all processes, frameworks and approaches of “trial and error.” So go ahead and consider them all the same.

Design Thinking actually has an earlier history than Agile. It started in the late 1950’s around the same time as Systems Thinking. Yes, contrary to popular belief that Design Thinking is only for the creative type, actually Design Thinking emerged as an engineering practice – the first book that mentioned Design Thinking was by John Arnold in 1959 and was aptly titled “Creative Engineering.”

Although each Design Thinking, Agile and Lean, and even Systems Thinking come from different origins and have distinctive features in their practice, they share a lot in common and are highly compatible with each other. For example in my case I regularly use Design Thinking and Agile Scrum in combination.

Therefore when to use Design Thinking and not Agile or Lean is an irrelevant topic. Each Design Thinking, Agile and Lean are not single methodologies, but a collection of methods, tools, frameworks and approaches. So just like picking a tool from a toolbox, we just pick and choose and combine the most appropriate tools regardless of their origin.

So now that we’ve got our glossary clarified, let’s take a step back and address the often-heard skepticism that Agile, Design Thinking, Lean, all this stuff sounds like a fad. Aren’t they just things that consultants try to sell as the latest must have management tool, technique and methodology? And sooner or later, they’re going to be replaced by the latest hype that’s just old wine in a new bottle, right? Very valid question.

See, Design Thinking, Agile, Lean did not invent trial and error. Things like PDCA, plan-do-check-act, also known as the Deming’s circle used in Lean, and the OODA loop, observe-orient-decide-act, which is an iterative decision-making framework developed by a USAF colonel back in 1976; these loopy way of thinkings are not new notions and have been around for decades.

And then when we think of our philosophical fathers like Socrates and Confucius whom their writings are essentially all about learning from trial and error, the teaching has not changed. It’s all about experimentation and iteration. And that probably won’t change for the remainder of human history; it’s the nature of trial and error – the only way we’re going to learn trial and error is, you guessed it right, by trial and error.

See, it’s because by default, we humans don’t like trial and error. It’s coded in our biology – we hate change and uncertainty. It’s our survival instincts to resist change and avoid uncertainty. It’s that strong. But at the same time, it’s also universal knowledge and wisdom that risk taking is rewarding. Risk taking by trial and error is simply the best strategy out there for evolution. This battle between two opposing forces, resistance to change versus trial and error, we’ve been doing that for thousand of years and probably longer, and it continues today.

Design Thinking, Agile, Lean, what ever they are called, are simply our latest attempts to get trial and error, experimentation and iteration right. Hype or not it doesn’t matter what they are called, the spirit is same.

So, PDCA, OODA, Lean Startup, Agile Scrum and Design Thinking, they all share a loopy, iterative characteristic. This contrasts to waterfall, the linear, deterministic way of doing things. All of these loopy frameworks are different variations of the same thing: experimentation and iteration. And they share the common objective of addressing shortcomings of what we know as waterfall. Let’s take a more detailed look at this in our next section, Why Design Thinking?

Waterfall is a linear, sequential form of project management where a predictive big plan is made upfront, and phase-gate executed all the way to the end. Now don’t get me wrong, I’m not saying waterfall is bad. In fact, waterfall is good. We owe modernity to waterfall. Without waterfall, we wouldn’t have high-rises, bridges, subways, safe air travel, our favourite packs of Danone yogurt and Kellogg cornflakes on supermarket shelves, not even fast food chains like McDonald’s and convenience store franchises like 7-11. It’s a clean, transparent form of project planning and execution that produces stable results in mass quantity.

The challenge here is that, waterfall is not the best approach to what we call complex adaptive challenges – projects and endeavours of uncertain and ambiguous nature. Pretty much every new product development today, is a complex adaptive challenge. Thanks to globalization, industry 4.0 and the service economy, consumers are offered more choices today. And thanks to social media and the internet, consumers tastes and preferences shift and diversify at unbelievable paces. Simply put, it’s hard to predict what people want, nowadays. So, if we develop a new product or service with a hard assumption upfront, there’s a good chance that we may miss product market fit by the time we get the product out to the market. In waterfall, we can only find out if our assumption was correct at the very end. It’s an expensive way to fail. Hence we should reserve waterfall only for projects of certainty.

And for projects of uncertainty, better do it in iterations. With Design Thinking, we experiment with prototypes. What we think may sell is a hypothesis. Unless we test it with the market, we can’t say for sure it will sell. And building a full scale, complete product for something that so far we have little or no evidence that it will sell, is a risky endeavour. So we build a prototype of the product for the sole purpose of testing the idea – more specifically, for collecting real information to learn whether or not the idea works or not. Typically we will have an in-between answer – there were things that didn’t work but elements of the prototype that did. So we keep those parts that worked and iterate the process.

Note that I highlight “product development” under the Design Thinking header. Agile, Design Thinking and Lean Startup are not used for “managing” processes, they are used for “developing” solutions.

It’s not easy to adopt iterative ways of product development though. Most people, particularly those who are used to waterfall project management will find the ambivalent nature of product development with Agile and Design Thinking very uncomfortable. Like very.

In waterfall, there’s a clean plan and a target output, and as long as there is quality execution, there’s the comfort and confidence of building an end product exactly as planned

Meanwhile, with Agile and Design Thinking, we actually don’t know exactly what we’re going to build. We sort of know it and we do have an idea of a target outcome and it’s somewhere around here, but we don’t know exactly what’s it’s going to look like. Convincing stakeholders to fund a product development project with a vague idea of what’s being built, is often an uphill battle.

And then this: first step we’re clear on what we want to do, second step we have a general idea of what to do, but thereafter… This takes, a serious leap of faith.

The cure to this is to find the right balance of freedom within a framework. That’s the reason why Design Thinking is process driven – while Design Thinking is indeed a creative practice, there’s an “engineerical” aspect to it and requires discipline to follow.

So how do you resist the temptation to tackle a hot project in a gung-ho all-in way, and instead mentally prepare yourself for rounds of careful, diligent iterations? And how do you convince impatient stakeholders that want big results fast and secure to instead sponsor your endeavor with the right, supportive mindset?

Try making the economic case for innovation by iteration, because it’s simply smarter.

Let’s take this example of a hypothetical high risk, high return project. The probability of success is low at only 20%, but expected return on investment is high at 20x. Actually, it’s not a bad investment opportunity. If you look at the weighted average ROI, it’s $100 times 20% times 20, which comes out to $400, a quadruple expected return. This is actually not an uncommon risk-return profile, startup projects are like this and venture capital firms invest in these kind of projects day-in-day-out.

Now, the $400 ROI is based on the assumption that investment is made in one go. Let’s look at the scenario where we invest in an incremental, agile way. So we invest in five goes, $20 each, and every iteration we see continuous improvement that contributes to an increased probability of success, say at a rate of 20%, what happens? These are hard assumptions but not necessarily untrue from reality – as a startup, spending money wisely in increments to build-measure-learn with prototypes and minimum viable products, or MVPs, every iteration, will likely get us closer to product market fit. So if we tally up the improving weighted average ROI from each iteration, we end up in this example with an ROI of $1200. That’s three times the ROI compared to investing in one-go, waterfall like. And the good news is, it doesn’t stop there. As by the time of the last iteration, on the assumption that we’ve nailed product market fit, we get to keep on milking the cow until the market shifts. So, iteration de-risks, and iteration makes money. Cool, right?

Okay, time to talk about how to do Design Thinking.

There are a few variations of Design Thinking processes. Here I’ll use the Stanford d.school version that goes through a five-step divergent and convergent process.

Step 1 is to diverge on understanding the user with “empathize.”

Step 2 “define” is to converge that learning into defining the problem.

We diverge again in step 3 with “ideate.”

We then converge the best ideated solutions into a “prototype” that we create in step 4.

Finally in step 5 we test the prototype with customers and stakeholders and validate if our idea was on, off or somewhen in between.

With those learnings, we iterate. If our idea was on course, great, let’s continue! If our idea was off, no worries, let’s pivot. And most likely there were good things and bad things about our idea, so let’s tweak our idea and try again. This part is same as Lean Start-up – build, measure, learn and persevere, pivot or tweak. And we repeat until we’ve nailed product market fit!

Again, step 1 is divergent. We “empathize” to understand the user.

Best way to understand a user is to talk to them, and listen to them.

In Design Thinking we listen with empathy. That’s because we want to understand the user’s real wants and needs. If there is one thing that I’ve learned from my over a quarter of a century life as a marketing professional is to never believe a customer’s wants and needs at face value. Customers often don’t know what their real wants and needs are; we marketers learn it the hard way – you respond to a customer request to exactly the spec they’ve asked, only to receive a lukewarm reception. A good marketer is asked to guess the customer’s unconscious desires, and the key to unlocking that is empathy (and lots of trial and error).

Empathy Maps and POV statements are great tools for note taking and thought summarizing in user interviews.

Take interview notes with an Empathy Map, pay attention to the difference between what you observe and infer. Beyond what the user says and does, make an educated or intuitive guess of (and validate by asking back) what they think and feel.

And then later on summarize your thoughts into a POV statement – something like for example, “John, a frequent traveler, is in need of a better alarm clock app because his sleep is irregular and sometimes he sleeps through the alarm buzzer.”

Step 2 is defining the problem.

From the POV statement, we generate a matching question statement that the defines the problem. “How might we (HMW)” question formats are particularly useful.

In the previous example, the POV was “John, a frequent traveler, is in need of a better alarm clock app because his sleep is irregular and sometimes he sleeps through the alarm buzzer.” The HMW statement can be as simple as “How might we create an alarm app that will wake him up for sure?”

In step 3 we ideate solutions.

The importance is to diverge, diverge, diverge into lots of ideas so that you give yourself many choices.

Start with quantity over quality: one of my favorite exercises is something called Crazy 8s where you force generate 8 ideas in 8 minutes. You’ll be surprised how out-of-the-box ideas are born when desperate under time pressure!

Continuing with the alarm app solution for jet-lagged Jason:

– “How about we create an app that buzzes in random ring tones and volumes?” or,

– “How about we create an app that automatically texts a wake-up call request message to someone?” or,

– “How about we…” and so on.

And then in step 4 we make the hard choice of selecting the one best idea and making it into a prototype that you can test with the user in the final testing stage.

There are many ways to prototype. Let’s start with prototyping a service model.

Many of our product development today are for service products. And even for hardware products, often cases the real value of the product is the service model around the usage of the product. So in that case let’s find a way to demonstrate the service model as a prototype.

A storyboard will do the job. Scribble a cartoon sequence, a manga if you are an anime otaku, to visually show the story. It’s a great way to get your idea across and test for reactions.

If your product or service is delivered in a physical space, try prototyping a store concept.

Using 2D or 3D perspective drawings are great ways to demonstrate not only things like in-store marketing campaigns, but also tradeshow booths and even new patient experiences for medical services.

If your product is an app, be careful not to overdo the prototyping.

Resist the temptation to jump to creating a hi-fi prototype with fancy software like Adobe Illustrator and XD or mockup services like InVision.

The objective of prototyping is testing. So if a lo-fi sketch version will do, just stick to that. If you need something more interactive, consider making a mid-fi prototype with paper mockups.

And yes, there’s so much joy in crafting paper mockups.

This is one of the things that I miss from doing Design Thinking workshops in a face-to-face environment. Nothing beats the fun of seeing a whole bunch of executives rolling up their sleeves and mass consuming cardboards and masking tape.

One final word of advice on prototyping.

Many of us are OCD and perfectionists and there’s the tendency to go overboard in prototyping.

Remember, prototyping is for testing. All we want is the user to see the general concept, the gist of what’s being proposed and not the full details. On top of that, often cases after we’re done with testing, we’ll be discarding the prototype and move on to the next iteration, because it has already served its purpose.

So if you end up producing a quality piece of a body but not the whole picture, that’s not going to help. And the work can end up as waste – or “muda” in Lean terms.

Just create what we call as a “walking skeleton.” Something that is barebones but shows how your idea works. You can worry about putting on more meat and making it pretty later on in the next iteration if the customer testing was successful.

Resist doing a perfectionist job and instead be a good-enough’ist. Prototype a walking skeleton.

The final step is testing.

These are actual scenes of testing in a Design Thinking workshop that I facilitated.

Finally, I’d like to close this section with how much time it takes to do Design Thinking.

Design Thinking can be a weeklong or longer process if you elect to do so, but often times you can do it like in a few days or even as a one-day exercise.

As a matter of fact, you can do Design Thinking in less than 30 minutes if you want. Here’s a rapid Design Thinking practice exercise that I do in my training sessions. It’s really simple. You pair up in buddies and by gifting each other an origami craft, you can go through the full empathize, define, ideate, prototype and test stages in just 30 minutes.

It’s a great introductory exercise to experience Design Thinking, so find someone nearby and give it a try. It’ll be fun and pleasant for both you and your experiment partner.

Now that you know how to do Design Thinking, let’s take final look at why Design Thinking again from a wider perspective.

This is a visual from my favorite Design Thinker Marty Neumeier.

We are all highly efficient and effective, experienced professionals. So when we see a problem, snap, we know what to do. From know to do, we’re quick to take action.

Now that’s all fine for most day to day stuff, but once in a while, we do need to know to stop.

Design Thinking encourages that. So, from know – do, to know – stop, observe, orient, retrospect, think, introspect, design, devise, create – and then finally, do. This is the essence of Design Thinking – it’s in the ability to intentionally create this middle step.

Now the interesting thing about creativity is that it’s not a random process. When we study the creative geniuses of past and present, we almost always see rules and rituals that these crazy people apply to their work. Design Thinking is a culmination and essence of common creative process we’ve learned from these geniuses. It’s a cheat sheet for the common man on how to activate our creativity.

But the key thing here is that creativity is not reserved for the geniuses – we are all creative. When we were five-year-olds, every kid in the playground playing in the sandbox was creative, right? We just have to reactivate our creativity that we left in the sandbox decades ago.

So make Design Thinking personal to you. If the empathize, define, ideate, prototype and test terminology don’t resonate with you, replace them with words that do to you, like feel, think, imagine, build and try.

Another thing to note is that Design Thinking doesn’t have to be a linear process.

We have an amazing cognition facility called intuition, and that’s how our brains work. With intuition, we jump back and forth among thoughts.

So while doing Design Thinking, if your intuition tells you to quickly test out something while ideating, go for it. And when you’re building a prototype and you have the urge to replay the conversation you had with the user, and as a result of your re-empathizing you feel you need to revisit your problem definition and tweak it, be my guest.

Just because Design Thinking is process driven, doesn’t mean you have to always follow the sequence. Break the rules, break a leg.

So, back to this visual.

Many of our failures in the modern context of complexity comes from the application of linear thinking to complex adaptive challenges.

In the business world, projects of predictable outcomes are best handled with waterfall.

By applying the same method to projects of uncertainty will result in people getting lost, stuck and frustrated.

We need a different way of thinking, and therefore today we are talking about Design Thinking.

The key to making best use of Design Thinking is to understand what we need to “de-learn” in our default thinking patterns.

For sure, linear thinking is our default thinking pattern. The fact that we are very good at planning and making lists, is the proof.

We like linear thinking because it is simple and great at keeping us organized. It’s a systematic and straight-forward way of doing things.

The problem is the opportunity cost associated to linear thinking. Are all options explored? Is that the only way? How do I know what’s missing? When we generate tunnel vision, we can’t see what’s beyond. That’s an opportunity loss. And that’s why we need to de-learn linear thinking.

When we are exploring ideas, linear thinking easily gets us stuck. So, let’s get unstuck with non-linear thinking.

Try lateral thinking. Ask what if questions and shift your perspective. Orient and parallel think of different scenarios.

Try divergent and convergent thinking. This originates from the deductive and inductive logic from ancient Greek times. As you can see that from the same visual I use, this is the thinking basis of Design Thinking.

And finally, a thinking pattern I like to call mosaic thinking. Imagine spilling out everything in your brain onto a table. Then take a step back and look at the table and find patterns and connections. You might start generating a heat map. You might uncover bottlenecks. You might starting see where things can flow. You may be surprised with what you see and possibly there will be some unexpected great discoveries.

Combine these thinking patterns in anyway that you wish. And to make de-learning linear thinking and re-learning non-linear thinking permanent, practice it everyday so that it becomes a habit. Guaranteed, the world will start looking different.

I’d like to conclude this session with one final advice: don’t fall into the methodology trap.

There are many non-linear thinking and production tools out there that address short comings of waterfall project management and linear thinking in general.

The key is to have a toolkit mindset. Learn many mental models. For process tools you have Design Thinking, Agile Scrum, Lean and so on. Learn them all, internalize them as your knowledge and skill, and make use of them where they are best fitting to your activities. Naturally, you will start combining tools; for example, I do a lot of Design Thinking plus Scrum because it makes sense. This is all very fine and encouraged.

Enjoy learning and expanding your mind. I hope Design Thinking will help you in doing more of what really matters to you.

--

This article originally appeared on https://agile-od.com/lean-agile/welcome-to-design-thinking