Welcome back to the deep Dive. If you've ever looked at a
complex problem, you know, whether it's organizational
inertia, customer retention, or even improving public services
and thought, there has to be a more creative way to solve this
than today's deep dive is for you.
We're pulling apart Design Thinking, or DT.
It's a methodology that started with graphic and product
designers, but has since just exploded into this essential
strategy for tacking complexity in, well, every field
imaginable. That's right.
We've synthesized the sources to get you immediately to the core
concepts. Our mission today is to define,
you know, the necessary conditions for using DT, explain
why this approach is so fundamentally different from
traditional problem solving, and then walk through the three
interconnected phases, inspiration, ideation and
implementation that really define the designers mindset.
This is your rapid deep shortcut.
I love that phrase the designers mindset, because while design
thinking feels incredibly modern, sort of Silicon Valley
approved, the sources are quick to point out that the
techniques, things like empathy, maps, rapid prototyping, they
have roots stretching way back to the 1960s, borrowed directly
from architecture and industrial design.
It was an operational shift, really.
For decades, these techniques were used to make sure a new
lamp was functional or a new user interface was intuitive.
Right for physical things. Exactly.
Yeah, The turning point was the realization that these human
centered techniques, they weren't restricted to physical
objects. They could solve organizational
challenges, educational deficits, or even policy issues.
And the company most responsible for taking this mindset
mainstream in the 90s and really formalizing the phrase design
thinking is IDO, the US based design consultancy.
They're famous for helping design Apple's first
commercially successful mice, among many other foundational
products. They really proved that this
human centered, iterative approach could generate genuine
market disrupting innovation. And that innovation is precisely
the goal. But we need to establish a very
important caveat right off the bat, a point our source is
really stress. DT is not a universal panacea.
You don't use it for every business problem.
When do we use it then? If someone is listening and has
a task list, how do they know which items deserve the DT
approach? You should deploy design
thinking specifically for problems where both the problem
and the solution are unclear. Uncertainty is the key
ingredient here. OK, let's use the contrasting
examples from the material to really make that distinction
stick for you. Say a company is hired to build
a robust web-based system for managing online multiple choice
exams. That is a clear cut case.
The problem is defined, we need a testing platform and the
solution is known right? A web application with standard
features like user accounts, database integration, greeting
mechanisms. You use standard, often agile
based practices here. So user stories talking to a
product owner. Exactly.
That's sufficient to identify requirements and execute the
project. You don't need a designer to
question the fundamental premise of multiple choice exams.
Now let's switch gears. A major university wants to
develop an innovative method for teaching software engineering to
the next generation of students. That is a massive conceptual
leap. The demand is totally unclear.
They don't know if the solution involves a new curriculum, A
mandatory internship program, or maybe developing a new
collaborative software suite entirely.
They don't even know if software is required.
Exactly. The university is dealing with a
deeply uncertain future state. Design thinking is essential
here to unpack the true needs of the learners and prototype
potential educational models before committing huge
resources. So if you're staring at
complexity and you don't even know what questions to ask,
that's your trigger for DT. Absolutely, and fundamental to
managing that uncertainty is the team structure itself.
DT processes rely on multidisciplinary teams.
You need professionals from development, marketing,
education, maybe anthropology all working together.
Why is that multidisciplinarity so crucial though?
Can't a smart team of four engineers just solve the
problem? Because if everyone is looking
at the problem through the same lens, say a purely technical 1,
you will always arrive at a technical solution.
You risk developing a faster horse.
A multidisciplinary team breaks that professional bias,
maximizing the chances of generating those truly
out-of-the-box ideas needed for innovative solutions.
That sets the stage perfectly. Now we can get into the process
itself. The sources remind us that DT is
not a checklist, not a strict algorithm.
It's characterized by three core activities, inspiration,
ideation, and implementation. Let's start with the foundation
inspiration. Inspiration is synonymous with
deep, radical empathy. Before proposing anything,
designers have to internalize and genuinely experience the
problem from the perspective of those who are affected.
The users, how far did they go to gather that kind of insight?
I mean, it has to be more than sending out a survey, right?
Miles more, Yeah. The techniques are rooted in
ethnographic studies, intensive interviewing, visiting users in
their workplaces, observing behaviors in their natural
environments. It's about uncovering the
unspoken needs, the subtle, everyday frustrations that users
might not even realize they have.
This is where those great stories that define design
thinking come in. The sources share that powerful
anecdote from Tim Brown, the former IDEO executive.
A designer was tasked with improving customer care at a
hospital. So instead of just relying on
patient interviews or comment cards, the designer simulated
having a broken foot, right? They put themselves in a
wheelchair and tried to navigate the waiting rooms, the check in
process, the appointment scheduling.
They deliberately experienced the service first hand.
That level of dedication is necessary because it reveals
things no survey or interview ever would The subtle
infrastructural failures or, you know, the emotional distance in
the care process. That is next level dedication,
but it sounds incredibly time consuming and quality, so this
raises a challenge. DT gives less emphasis to
traditional instruments like large scale surveys or
quantitative market research. Why sideline what most companies
rely on as reliable data? It's not about ignoring data
entirely. It's about prioritizing insight
over sheer volume. Quantitative data tells you what
happened. Design thinking cease to
understand why it happened and what hasn't happened yet.
We always rely on those legendary quotes to explain the
limitation of just asking users directly.
The faster horse phenomenon. Precisely Henry Ford's reputed
line. If I'd asked customers what they
wanted, they would have told me a faster horse.
Users are constrained by their current reality.
They can describe the pain, but they can't leapfrog into
innovation. And Steve Jobs echoed that
sentiment decades later. He said people don't know what
they want until you show it to them.
Exactly. So the designer's job is to read
between the lines of what the customer says they need and
infer A revolutionary solution they haven't even conceived of
yet. Yes.
Our role is to uncover the latent needs, and to help us do
that, the inspiration phase uses some powerful advanced
techniques. The first is paying attention to
extreme users. This is fascinating.
Why focus on the margins? Why look at the children, the
elderly, the early adopters, or the very best and worst
performers in a system? Because average users tend to
smooth out the data, they hide infrastructure weaknesses.
Extreme users push the system to its breaking point.
If you design a process that successfully accommodates the
most technologically illiterate elderly user or the most
demanding power user early adopter, you create a robust
solution that works seamlessly for everyone in between.
Their needs aren't just magnified, they reveal hidden
constraints and unexpected potential.
And the second technique in this inspiration phase, which is
maybe the most intellectual demanding, is reframing.
This means intentionally changing the fundamental
definition of the problem the client originally brought to
you. It's transformative.
You step back and say the problem isn't what you think it
is. The example from the sources is
brilliant. A publisher struggling to sell
books. The expected path is better
marketing, better distribution, maybe cheaper paper.
The usual stuff, right? But the team reframes the
problem entirely. They redefine the core assets.
What do you mean? They realize the core asset
isn't the physical book, it's the curated intellectual content
within the catalog. By reframing the problem from we
are bad at selling books to we are inefficiently delivering
knowledge, they completely shift the solution space.
And they start offering online courses based on their catalog.
Exactly. It transforms the business model
entirely. Drive from the same core assets.
That is the power of the designer's mindset.
It's not about optimization, it's about transformation.
So we have our inspiration, our deep empathy, our reframed
problem. Now we shift into phase two
ideation. Ideation is where we generate
and rapidly test those possibilities.
It has two main highly active sub processes, divergent and
convergent thinking and then prototyping and testing.
Let's talk about that thinking. Dynamic.
Divergent thinking is the blue sky moment, right?
You go wide quantity over quality, sketching,
brainstorming, no judgement. The necessary chaos.
Generating hundreds of ideas, conventional or unconventional.
Yes, since the goal is innovative solutions, you have
to maximize your volume of raw material.
We rely on the wisdom of the two time Nobel Prize winner Linus
Pauling. To have a good idea, you must
first have lots of ideas. If you only generate 10 ideas,
the best you can hope for is an incremental improvement.
So you fill the whiteboard and then you apply the brakes and
move to convergent thinking. Which is the necessary
discipline? It's narrowing down grouping,
prioritizing and discarding the non feasible or less impactful
ideas. The team collaboratively
determines which limited set of solutions is worth the
investment of prototyping. And once you have those few best
ideas, you jump straight into the second ideation activity,
prototyping and testing. But you mentioned low fidelity
is key. Why not build something polished
right away? You must fail cheaply and
quickly. Prototyping is about making the
abstract tangible without a major investment.
The sources highlight that famous IDO anecdote.
When they built the very first mouse prototype for Apple, they
weren't using high grade plastics or advanced machinery.
They used a roll on deodorant ball and a margarine container.
Exactly. That is the genius of Low
Fidelity. It cost pennies.
You build it in an afternoon and you put it in a user's hand.
The user immediately tells you the shape is wrong or the
placement of the button is awkward.
You learn what's wrong before you spend $100,000 on tooling.
Right, It manages financial risk while maximizing learning.
The prototyping can get tricky if you're not building a
physical object. I mean, if you're designing a
service or a new software interface, how do you manage
that low fidelity test? For services, it sometimes
requires setting up an improvised physical space, maybe
using cheap furniture or Styrofoam to simulate the user
journey, much like the designer simulating the broken foot.
For software interfaces or complex processes, you use
storyboards. Storyboards being simple
drawings or visual narratives that depict the users step by
step journey through the proposed new service or
interface. Exactly.
They serve as effective prototypes because they allow
the team and the user to identify friction points and
logical flaws before a single line of code is written or a
single policy is finalized. They are cheap, fast and easy to
modify. So we've been inspired, we've
ideated and prototyped, and we've selected a viable, tested
solution. This leads us to the final phase
implementation. Now this phase sounds like the
handoff to the rest of the organization, marketing,
production, sales. It's more than a handoff, it's
accompaniment. Once the solution is chosen, the
designer has to help shepherd its execution.
The implementation phase involves assisting with
organizational explanation, communicating why this radical
new solution was chosen, and helping develop the
communication and marketing strategies.
That sounds critical, especially for a radical reframing like the
publisher example changing the business from books to courses.
The design team has to sell that radical shift internally.
Precisely if the idea generated an ideation is truly innovative,
it may not conform to the organization's existing
structure or sales channels. The implementation phase
addresses that organizational inertia.
The designer provides the context and the human centered
narrative that proves this strained new idea is exactly
what the user actually needed. No, you just walked us through
inspiration, ideation, and implementation.
Hearing it laid out that way, it sounds like a perfect linear
assembly line. But our sources are very clear
that this is a common and dangerous misconception.
Absolutely. Design thinking is fundamentally
non sequential. It is always possible and
usually necessary to loop back to a previous stage.
The process is iterative, not linear.
What's the most common reason you would loop backward?
Well, say you're deep in the ideation phase brainstorming
ideas, and you realize that all your best ideas rely on
understanding how a specific minority user group interacts
with technology data you just didn't gather during the initial
research you have. A blind spot.
A huge 1. So you have to stop, loop
immediately back to inspiration, conduct those specific
ethnographic studies, and then return to ideation armed with a
necessary insight. Or conversely, you build the low
fidelity prototype, test it with real users, and it fails
spectacularly. You don't just push it into
implementation anyway. You can jump back to ideation or
potentially even all the way back to inspiration to redefine
the need and generate a new path.
That constant iterative movement, often illustrated by
interconnected loops, is what defines DT.
It's a learning cycle, not a production line.
The solution emerges through continuous refinement and user
feedback, not by following a rigid set of steps.
So what does this entire framework, this ability to
empathize deeply, generate widely, and iterate
relentlessly, require from the individual?
What are the essential traits of a successful design thinker
according to Tim Brown? The traits are rooted in
synthesis and perspective. First, the capacity to identify
patterns hidden within complex, often contradictory information.
Second, the skill of taking those identified fragments and
synthesizing brand new novel ideas.
And perhaps most vital, the ability to genuinely empathize
with people who are fundamentally different from
oneself, moving beyond self reference.
That makes design thinking feel less like a methodology manual
and more like a mastery of perspective And intellectual
agility is a powerful framework for tackling massive complexity
and deep uncertainty by focusing relentlessly on the human
experience and daring to completely reframe the original
problem. Thank you for joining us on this
deep dive.