Overrating ‘Design’ or ‘Thinking’ in Design Thinking
Design thinking is all the rage now. It’s the new way to do things. It’s orientated towards solving real problems. It’s the best thing since sliced bread.
I do believe in design thinking. As a UX professional, I am a natural advocate of it. But, underneath all the hype, how many enthusiasts understand what design thinking really means? And how many understand how it’s actually practiced?
In my work, I’ve encountered two glaringly mistaken approaches to it. And the mistake can be boiled down to this: Overemphasising either the ‘design’ or the ‘thinking’ aspect, typically to fulfill a side agenda.
Design with too little thinking
This approach stems from placing too much faith in design as a spontaneous act of creative genius. It assumes designers are innate experts who can immediately solve problems through design, that this is what we’re being paid for. Well, that’s wrong.
In my experience, this approach is often accompanied by a desire to have the work done quickly, sometimes also cheaply. The timelines permit little preparation, let alone user research. And the requester may expect to choose from a few options or to give feedback on the designs to get closer to what they think they want, probably based purely on assumptions.
This typically means skipping the ‘Discover’ and ‘Define’ stages of the design thinking process, maybe even the ‘Ideate’ stage. At times, it does work — more or less. There is a functioning product at the end of the process. It may look visually appealing. It could even turn out to be a success. But, basically, this approach is just gambling on the latter. With little effort expended to get supporting evidence for design decisions, the likely outcome is a product that hardly stands out from the competition at best.
The modern cult of design has not helped here. I have heard people dismiss the importance of user research using the example of Apple. Users didn’t know they wanted an iPhone, goes the argument. If you asked them what they wanted, they would have asked for something far less revolutionary.
This, of course, belies a misunderstanding about user research. It’s meant to help designers understand user behaviour and needs, not solicit solutions. And “I want an iPhone” or “I need a better mobile phone” are not needs in this sense. In doing user research, a designer wants to understand more fundamental needs that users might not be able to think of solutions for, that they might not even be able to articulate well. In other words, user research seeks to find underlying problems that can then be solved through the designer’s expertise.
Too much thinking and ignoring the design process
So, having said that, how can there be too much thinking?
It’s not necessarily the amount of thinking done that can be a problem, but how much thinking dominates the process, or how much the Ideate stage is emphasised over the other stages.
The worst example of this I’ve come across is the practice of design by committee. Design often becomes a victim of politics in such situations. The Ideate stage becomes bloated due to the need to have a group of people come up with solutions that satisfy everyone, with the Discover and Define stages nearly or completely forgotten in the quest to please every member. The practice of soliciting users for solutions can also fall into this trap. And the likely result is mediocre or downright bad design.
Overemphasising ideation is also bad because it can lead to the validation of design decisions (i.e., the Evaluate stage) becoming deprioritised. Even designers can make this mistake. Design needs continued iteration and refinement to reach perfection, and to delay this evolution and try coming up with perfection up front is unrealistic. With finite timelines, you’d only be setting yourself up to have less time to refine later.
To avoid this, move as soon as possible to prototyping and testing. With design, it’s difficult to know what works or what will really solve the problems without letting its intended users try it. As a designer, you may have the expertise to create solutions based on the research done, but the solutions have to work for the users or they won’t be adopted.
Test early and test often. The prototypes, especially early ones, don’t need to be high-fidelity. The important thing to work out first is whether users are able to do what they need to do easily. Based on existing scholarship on usability testing, you don’t need to recruit many users for each test either.
But, after a point, testing with prototypes would yield diminishing returns, since real-life situations may be different from what happens during testing. Then it’s time to go into development and get the MVP launched. That would be the real test of the design, and real-life feedback from users can be used to further improve on it.
Not only does this align with the Agile methodology, which maximises the efficiency of the design process, your users also stand to benefit since having a working product to use beats not having one.
Getting the right idea about design thinking
It’s tragic to see “user experience” and “design thinking” cited even as the mistaken approaches above are being taken. And there’s no excuse for this today. There’s plenty of literature online that explains design thinking well. Those who would be involved in design in any way should take the time to digest them.
Even better, attending a UX workshop can provide you with a hands-on learning experience. A good workshop would bring you through every step of the design process, even letting you try out activities in the Define and Ideate stages such as affinity mapping and crazy 8’s to build a comprehensive understanding of the process. After all, learning by doing tends to be more effective.
If everyone can do this and refresh their knowledge once in a while, the world will be a better place. Or at least things will be better designed, as the full potential of the design process to do good work will be unlocked. Well, for many users, that will undoubtedly make for a better world.
