If you’re a product manager or working on a product team, you’ve probably heard of Design Thinking. But have you used it? Do you know what it is, apart from a buzzword everybody likes to use? And, more to the point, how can you start to use it to build better products?
Product managers are, by definition, faced with problems to solve. Design Thinking is a way of approaching a design problem, a mindset that comes with highly practical tools and frameworks. Design Thinking helps you solve problems from the user or client perspective; in other words, giving them what they want and need.
This article (Part 1 of a trilogy) is all about laying a foundation for product managers, UX designers, or anyone interested in successful, user-centred innovation and creativity.
So, why is Design Thinking important?
Design Thinking is about a design process that keeps the user at its heart throughout; it’s based on really understanding the users’ wants and needs, using research into how they access and use products and services.
Within organisations, Design Thinking is a practical mindset which fuels innovation to create solutions that meet both user and business requirements.
Previously, designers would take an existing idea and try to make it more appealing to users. Design Thinking shifts the emphasis: find out what users need and want and then build it, letting the ‘appeal’ take care of itself.
OK, I get it. But where did Design Thinking come from?
The phrase ‘design thinking’ is first found at the end of the 50s and into the 60s (a great decade for adventurous designs, by the way) in books like “Creative Engineering” (1959) by John E. Arnold, and “Systematic Method for Designers” (1965) by L. Bruce Archer.
In Arnold’s view, design thinking could be used to add new features to a product, improve performance, reduce costs, or to boost sales. These are still pretty much the four main business drivers for innovation in the 21st century. It was further popularised by Design Thinking champions within Stanford University in the 80s, and adapted for business purposes by David M. Kelley and co. at IDEO in the early 90s.
Whatever the history and definition (and they do vary) of Design Thinking, the core feature is the focus on the product user. This enables product managers to home in on the sweet spot that makes a product practical, desirable, and viable.
What Design Thinking is NOT
What Design Thinking is not is a finger-in-the-air “way of thinking” which everyone talks about but no one really knows how exactly to deploy.
Think of it as a set of goals, practices, and priorities that lead to particular outcomes and, if done well and consistently, it can then generate “a way of thinking” that will help you design and build better, more relevant products today.
The classic Design Thinking framework
There is no one formula for Design Thinking (DT) – it’s more of a philosophy or mindset rather than a specific set of tools. That said, each school of thought tends to create its own DT framework or process.
A classic version comes from Stanford’s d.school:
- Empathy – get to know the users; what’s their context? How do they think and feel about the problem?
- Definition – analyse the data to understand what users need, create insights into the issues underlying the problem; define the problem in people-centred terms.
- Ideation – challenge assumptions, storm ideas, give free rein to innovation; challenge yourself to go beyond mere product tweaks.
- Prototyping – create a lo-fi version of the solution that addresses at least part of the problem.
- Testing – test the prototype with users and gather feedback.
This looks like a nice, simple 5-step linear sequence; it can be, but it’s usually not. The reality of people-centred product development is that new information and ideas are emerging all the time;
- some of these stages may be happening in tandem,
- you may have ‘mini-loops’ within the process ,
- ideation may push you back to further define the problem which then prompts better ideation,
- … and so on
And you’ll probably go through all the stages more than once as you spiral upward towards the best possible solution!
Be prepared to be flexible!
The many benefits of design thinking
I know what you’re thinking… Design Thinking is starting to sound a bit complicated! Surely you can design a product without all this fuss? Why bother with Design Thinking? What are the benefits anyway?
Well, it’s important to remember each team will be different, and will feel the benefits in different ways and at different points in the Design Thinking process. This will wholly depend on where they experience the most friction and churn in their efforts.
But stick with me here.
Let’s break down some of the benefits:
- It helps you to understand your users – The focus on getting inside the end user’s attitude and experience means advocates of Design Thinking tend to be more in touch with their target market.
- It fuels better collaboration – No successful product design is a solo effort. DT is an approach that encourages people to break free of roles and silos and work together on a specific problem.
- It encourages flexibility – Design Thinking’s non-linear nature allows you to manage and coordinate multiple processes and prototypes, finding the best solution as you go.
- It’s fast – Or at least it can be. In reality, the speed of the process is up to you, and depends on exactly how you apply the DT mindset (see Design Sprints in the next article).
- It’s practical – DT isn’t theoretical. The approach works with real data and information, takes real-world problems, and tests tangible solutions with the people intended to benefit the most.
In fact, Forrester-IBM research found that design and development time can be reduced by up to 75% with Design Thinking in the mix, and ROI can increase by 85+%.
Hmmm, maybe we’re onto something here after all!
The importance of Design Doing
So let’s pick up on one of those key benefits listed above: “Practical”. Don’t be misled by the name: successful Design Thinking is really Design Doing.
I know, right. Mind = Blown.
What I mean by that is that the common pitfall with DT is getting attached to the more ‘theoretical’ elements. Either constantly researching (there’s always more to find out!) or refining (and re-refining) ideas and possible solutions, putting off the inevitable testing and feedback stages.
Here at Pack, we’re big fans of using Design Sprints as a practical, structured Design Thinking process that produces tangible results. Think of the Design Sprint as the ultimate Design Thinking playlist.
A Design Sprint is a series of collaborative exercises and activities, suitable for large and complex challenges (including validating new ideas), that can result in a tested prototype in under a week. A Design Sprint typically gets you and all your key stakeholders in the same room (probably a virtual ‘room’, these days…) to go through the process.
As an example, here’s the Sprint process we use at Pack:
- Day 0 – (empathy) – pre-Sprint planning, research, and preparation; data-gathering and problem / challenge framing. Note: this is usually more than a day in reality!
- Days 1 & 2 – (definition & ideation) – workshops and activities with the client, collaboratively defining the challenge, ideating, and voting on ideas to create the basis of a shared solution we can move forward with.
- Day 3 – (prototyping) – a tangible manifestation of that solution.
- Day 4 – (testing and validating) – inviting potential users to feedback, defining the next step, and also validating the chosen idea.
This is all very hands-on: Design Thinking that includes doing.
After all, you and your team may be responsible for some truly great thinking, but if it’s isolated from the real world, it’s in quarantine – unable to connect or have an impact on users. Far better to do just enough research to point the way towards a likely prototype, build it, and then test it.
Remember some of those 5 Design Thinking benefits we talked about above?
Let’s measure those up against the Design Sprint:
✅ Helps you to understand your users.
✅ Fuels better collaboration.
✅ Encourages flexibility (as you never really know what the sprint outcome will be till you get there!)
✅ It’s fast (all done in a week).
✅ It’s practical (you have a prototype to test in mere days).
How do you introduce Design Thinking to your team?
If you’re not fully utilising Design Thinking right now but you want to go all-in, you’re likely looking at a significant culture shift. This is not an overnight thing.
Like learning to swim, throwing your team in at the clichéd deep end (such as starting with a Design Sprint) might be dramatic and exciting, but it could be too much, too soon.Better to learn to paddle first, and look for ways to introduce elements of DT and practices that support a DT mindset (i.e. prepare the foundation for a full-blown Design Thinking pool party and team-wide adoption down the line.)
Practical ways to gradually introduce Design Thinking:
- Position your project and product goals to be user-focused – Yes, your business goals (sales, profits, etc.) are important, but they depend on you producing something that people want and will use.Wording is important, and when your product vision and objectives place the user front and centre, so will your team’s creative processes as a result.
- Look for ways to engage with users – Starting with empathy and definition, engage with your users from the beginning.Think about how you can gather data in a way that provokes user interest in what you’re developing. Can you make your focus group more interactive or fun? Can you incentivize user participation?When it comes to ideation and prototyping, functionality is critical, but also consider how you can make the product positively appealing.
- Establish Design Thinking-friendly ground rules for ideas – You probably already have some guidance for ideation – defer judgment, the more ideas the better, build on each other’s thoughts, nothing is too radical in the moment, etc. But consider also explicitly tying your creative thinking ‘rules’ to DT: keep the user at the heart of every idea, ideas to be linked to user data, and so on.
It’s all in the principles:
Let’s face facts: you’re essentially looking for ways to change your team’s basic mindset or attitude to their work to make it more Design Thinking-centric.
The best way to do that is to keep some essential principles in mind:
- Challenge your existing systems – If you hear someone say, “We’ve always done it that way,” it’s a sign you should at least explore a different way.
- From inside the box to outside – Look for the self-imposed limitations on your thinking. What boxes are you thinking inside? What’s the worst (and the best) that could happen if you think ‘outside’?
- Stretch the team’s comfort zone – Don’t destroy their comfort zone, but do look for opportunities for a little sustainable expansion.
- Jump over barriers – Where are the limits? Roles, organisational structure, established relationships… where are you limiting yourselves without realising?
- Look for early adopters – You’re looking to engage better and more creatively with your users. There are always enthusiasts for anything new; their opinion may be no more valuable than their more cynical counterparts (you need both!), but their enthusiasm may be.
The Design Thinking mic drop:
Let’s recap then. We know that adopting a DT mindset pushes you and your team to focus on creativity, innovation, and practical design from the perspective of the people you want to use your product. Makes sense, right?
However, if Design Thinking is new to you and your team, you’re unlikely to leap this particular barrier in a single bound.
So then, ease the team into this change of attitude and culture by introducing the fundamental elements of DT in small ways – user focus and data as the main course, ideation, and experimentation as dessert. Your goal is to create the foundation for a true Design Thinking operation and a recipe for product success, one course at a time.
Enjoy this article?
If you’re hungry for more, be sure to check out parts 2 and 3:
- Practical Design Thinking Part 2: How To Embed Design Sprints Into Your Teams
- Practical Design Thinking Part 3: A Better Way To Run Remote Workshops?