What you might be getting wrong about design thinking
Most arguments about design thinking are about whether it’s “good” or “bad”, but both sides might be wrong
I was a market researcher for a large global company. I had been working in the research team for a few years, and before that had been a music writer, interviewing bands for magazines, so I was pretty comfortable convincing strangers to tell me their secrets.
My biggest frustration was how slow the product development cycle was, and how abstract our research projects were — huge, six-month endeavours from which a hundred-slide presentation deck would be produced and read aloud over two excruciating hours to the product team, who would smile and probably forget about it.
The moment that will haunt me forever was a product manager saying, “If you don’t get me the report by Friday, we’re not going to read it.”
Design thinking was a miracle: we can take your boring, abstract reports and help your team turn those valuable insights into something which, almost immediately, provides value to customers.
How could I not love it?
The consultants trained one team first — a cross-functional working group of senior managers from every department. That team then trained other cross-functional teams of other members of those departments (one person from product, one from operations, one from research, etc.), and we ran our first pilot.
To be clear, I’m talking about:
1. Empathize: research your users’ needs
2. Define: state your users’ needs and problems
3. Ideate: create ideas of possible solutions
4. Prototype: iteratively build out prototypes, from rough sketches to mockups through to actual working code
5. Test: going back and forth between stages 4 and 5, get users to interact with each prototype and refine it based on their feedback
(In a previous conversation, I split out stages 2 and 3 into sub-stages and jokingly added a final stage of “profit” — you might see different numbers of stages, and differently-shaped diagrams (I’ve even seen a quadruple diamond), but if it’s covering this work, the differences do not matter.)
Obviously, the project was successful, we released a cool learning game, and those teams trained more teams until it was a pretty widespread, normal way to do things.
In the meantime, I became fascinated by the whole development cycle and took Alex Cowan’s product development course, which again taught the five steps above (including providing interview scripts), and every team I have encountered that has done the things taught in Alex Cowan’s course has been pretty pleased with the result. (I don’t know of any that has gone back to its previous way of working.)
After that, I joined a different team and they had been taught design thinking by different consultants, and again it was how they do things. I took Google’s UX Professional Certificate for a sideways move into UX (alongside in-work experience), and again, it’s how they do things at Google. I used these Intuit-Alexander-Cowan-Google techniques at my new company and they liked it so much that after the first workshop I was immediately asked to run another.
So, imagine my surprise when I met a couple of people who told me that design thinking was bad!
Surely … surely you can’t do UX without empathize-design-ideate-prototype-test. According to Google, that’s basically the UX job!
Then, after many lengthy arguments, the penny dropped.
Design thinking worked for me because I had encountered it at a lumbering behemoth of an organisation with a large, well-funded research department of very, very experienced researchers, where the problem was that research wasn’t applied fast enough.
Design thinking hadn’t worked for them because they had encountered it at an early stage startup where there the problem was that there weren’t enough experienced researchers, so that the people doing the research had absolutely no idea how to do it properly.
Design thinking is excellent for making good research more effective, because it is immediately applied.
Design thinking is terrible at making bad research better, because that is impossible.
If you want your team to win, you assemble the best players that you can find, and you give them the equipment and space they need to achieve their best.
You don’t win by throwing random strangers into a pit and asking them to play a game where they don’t understand the rules.
- Assemble a cross-functional dream team including the most experienced researcher you can get your hands on
- Empathize-design-ideate-prototype-test
- Profit.