Design Thinking is Not Design
-
Moe Hachem
- April 3, 2021
We’ve all heard about Design Thinking, and it’s been a buzzword catching on like wildfire. Business touted it as the be-all-end-all solution to everything Customer Experience, User Experience, and at times a complete replacement to designers.
Design Thinking evangelists have even marketed as a tool that allows anyone to think and innovate like designers.
That’s nice and all, but is it true?
Short version? No.
Design thinking is a valuable tool when used correctly, but using it does not magically turn someone into a designer, nor can it replace CX/UX or the design process for that matter.
Why am I bringing this up? You’ll find many veteran CX/UX professionals viewing design thinking slightly negatively due to companies attempting to circumvent CX/UX. I’ll admit that I initially thought it was an exaggeration until I encountered it out in the wild one too many times. I’m not a veteran yet, but I can now understand why many UX veterans are concerned about the state of UX. I’m worried about the growing number of companies using design thinking as an alternative to UX, research, and the design process. People are no longer treating Design Thinking as a tool to stimulate conversation but rather as a cheap method to arrive at what resembles a solution without putting in the required effort.
What is Design Thinking?
If you search for design thinking, you’ll find many different frameworks that essentially say the same thing but in different ways.
The Definition
Design Thinking is the strategic and practical process by which designs develop concepts.
You’ll typically find design thinking broken down into five steps:
-
Empathize with the user
-
Define the problem
-
Ideate
-
Prototype
-
Test
The Problem with Design Thinking Replacing UX
The first pain-point that comes to mind with Design Thinking is that it trivializes a designer’s technical knowledge and know-how. CX/UX designers are perhaps the biggest victims of this pain-point where teams that utilize design thinking might begin to genuinely believe that “the entire team can do experience design”.
The next pain point is that your very first step is to “empathize with the user”.
As a designer, at least an experience designer anyway, you shouldn’t need a reminder to tell you to remember - and excuse my French here, to give a shit about the people using your product/design. What happens after when you’ve completed the first step? Do you stop caring about your users?
The issue at hand is that more often than not, Step One tends to be an expression of false sympathy based on false pretenses.
Today, design thinking workshops typically tend to involve coworkers taking a stab at the dark to guess at a user need. You’ll find little to no user research to back up any of these guesses. The result is an unintentional display of arrogance when everyone involved convinces themselves that their guesswork provided meaningful insight into the problems their target audiences are facing. These workshops can generate valuable qualitative insight, except it typically involves everyone but the target audience.
At the end of a design thinking workshop, everyone sits down on the ground in a circle, sings kumbaya, and pat themselves on the back for their hard work.
That’s great, and there was a lot of hard work, but it usually ends up being time wasted. I can have design thinking sessions all day with my product team, the CEO, or any other C-suite executive, but the problems we tackle could be non-representative of real issues our users face. At best, we get lucky, and at worst, we’d have wasted valuable time.
Design thinking is a valuable tool, but if misused, then it amounts to no more than wasted time. It is toolkit designers have, but it’s most definitely not a replacement to a designer.
Where is the Magic?
There is no magic. Design is a comprehensive process that involves a lot of work that very few get to see. We might work for months to arrive at a solution, but it’d take people mere seconds to judge our final product.
The magic comes from the design process, but it’s not magic. It’s a lot of hard work put in to create the end product.
Design involves research. I would even go as far as to say that research should be the most intensive part of a design process because the research is what lays your foundations. Your research should generate valid data and evidence to support your direction, rationale, and ultimately the anchoring point for your design process.
To present a slightly simplified view of the design process:
If you’re working with an existing product or design, you’ll want to start with an audit/analysis. If you’re working on a new product, you’ll want to do a competitive analysis and research existing competitors. You’ll want to research your current or target user/customer base to learn about who, what, where they are, and how they behave. You need to be able to understand what your users are trying to accomplish.
You’ll also want to conduct content analysis and create a strategy to help you understand what message you’re trying to transmit and how you’re trying to do so. Depending on your specific design niche, your message could be a literal message you can read, an intangible message you experience, or both.
Next up would be information architecture, or rather the creation of hierarchies and order that helps users understand how to navigate your design. You’ll want to base your decisions on research findings that show you the steps your users might take to accomplish their tasks. More importantly, you’ll want to consider all possible paths that users might take that could lead to either completing an action or even failing it.
We then have what you could call the interaction/schematic design phase, though that could extend to diagramming, wireframing, or any other different names. This phase involves expressing the work in a rough prototype you use to evaluate if your design works. Your goal in this phase is to create a rough version of your design.
After creating a prototype, it’s then time to begin testing the design. If your coworkers are not your end-users, then they’re not valid candidates. What you think about your work doesn’t matter, what I think about your work doesn’t matter, what your CEO thinks also doesn’t matter - What does matter is what your users think about it. When gathering users to test your designs on, you need to carefully plan the testing phase and be as scientific as possible to collect good data you can interpret.
I’m surprised architects don’t do this often because, unlike product design, when an architect’s end product gets built, there’s no (financially feasible) way to fix critical errors. There’s no excuse to skimp out on testing your designs since the cost of rebuilding a broken product is unforgivably high. If your test phase shows any flaws or needs for adjustment, that’s when you ought to double back and keep adjusting and testing until you get the best possible solution you can.
The last step is the visual design, or the design development phase, where you begin to layer the aesthetics that complement the brand, look-and-feel, and end-goal of the product. It wouldn’t hurt to test again at this phase, though I’d advise against reaching this stage without having done so. If you skip earlier testing, you might find you’ve wasted a lot of time making the prototype at this phase look perfect, only to have to tear it down. There’s also the fact that testing at this phase will generally draw feedback based on aesthetics rather than functionality.
Design thinking doesn’t cover any of the user/human-centered design phases. You can probably see that it might resemble a watered-down version of the process that’s ready for mass consumption.
Who’s Fault is it Anyway?
I find it quite interesting that I’ve met this kind of thought process when I was an architect and met it all over again as a CX/UX designer. I think it all comes back down to the fact that people only ever experience the end-product. Non-designers end up assuming all we do as designers are making things pretty. They don’t necessarily understand the complexities and steps taken to reach the end-product.
As designers, we need to stand up for our profession and talk about what we do. When we overly simplify our process, we promote the idea that our work is stupidly simple and anyone could potentially do it.
By watering down what we do in simple terms, we might be guilty of creating a situation where unqualified people lead the UX/CX and general design process. Those teams might then build up the confidence to delegate design work among team members and pretend they’re doing design. Those same teams might then end up claiming UX/CX and Design is full of hot air because they’ve started to find that they’re somehow losing customers/users left and right.
We provide tremendous value to companies when we’re allowed to do our jobs correctly. If we fail to value ourselves, then how could we possibly expect companies to do so? When we mindlessly hop on the design thinking bandwagon, we’re contributing to companies de-valuing our work and making believe anyone could do what we do.
The other people at fault include the companies that want to put as little investment as possible in research, but I wouldn’t blame them at all. From the outside, I can see why one might think UX and Design Thinking are almost the same thing.
The real culprits are the giants that go around proclaiming Design Thinking is UX. Go ahead and search for “Design Thinking UX”, and you’ll find a plethora of articles that try to paint Design Thinking as the equivalent to UX.
Final Thoughts
I suppose you could say that I’m raising two closely related issues: How companies apply Design Thinking today and how tempting it is for people to think Design Thinking can replace CX/UX.
Design thinking is valuable for community participation. It provides a means to solve both organizational and end-user problems when used correctly. The problems arise when a company solely relies on design thinking for internal sessions between coworkers, neglects its audience, and use it as a replacement for the CX/UX process.
Like with all tools, each tool has a time and place for it. While you can hammer a nail into a wall with a knife, you’re usually well aware you’re using the wrong tool that could harm you if you aren’t careful with how you use it.
I’m an advocate for design thinking methodologies when used correctly. On the other hand, I am also very wary of companies that try to relegate CX/UX as a group activity that the entire team can do. I’d probably respect the company more if they’d say, “we don’t want to invest in UX, so we’re just going to do things this way”, rather than try to convince the world that they’re doing UX.
I might be a CX/UX designer that knows how to code or write, but I’d never work up the audacity to tell a C# Developer or copywriter to step aside and let me do their work. There are complexities to their work I’m not aware of, and I would never be so presumptuous to think I could ever take their place.
