Design Thinking and its Perils
I believe in Design Thinking.
And I can prove it: I designed and regularly teach a named course in Design Thinking at Southern Oregon University. I lead student tours of companies that rely on the User-Centered design methodologies (including XPLANE, Citizen and Emerge Interactive). I advocate for Design Thinking principles on our campus and beyond.
Most recently, my perspectives on strategy and pedagogy have earned me national visibility with a Tow-Knight Fellowship in Disruptive Journalism.
But my advocacy for iterative collaboration methods such as Design Thinking (and Lean Startup and Agile and Visual Thinking/Gamestorming) is also tempered by a few practical realities. Anyone embarking into the world of Design Thinking and its peers is well-advised to acknowledge the real perils and pitfalls of iterative design.
Design Thinking is good at what it’s good at. But it’s not good at everything. Listening to some converts speak in a quasi-religious tone, you might think that Design Thinking can solve all the world’s ills. But that utopian view does not hold up to close inspection. Design Thinking works very well when framed around concrete solutions to individual and organizational problems, usually aligned with product development and commercial outcomes. It often does well at breaking up institutional gridlock and opening up communication in a siloed organization. But its most avid followers often filter from their consideration problems that can’t be framed in simplistic, capitalistic terms of “needs” and “fulfillment.” This is especially the case when solving the “problem” entails a confrontation with entrenched political forces that are inexorably aligned against the interests of individual stakeholders.
Even on its own terms, Design Thinking doesn’t always work. Sometimes projects fail. In life and in Design Thinking, if every project succeeds, then your team isn’t thinking big enough. A strength of Design Thinking is that its iterative quality provides a pretty robust and flexible framework for responding to failure. But sometimes you run out of money. Sometimes you run out of time. Sometimes the thing you thought you wanted from a Design Thinking process gets overtaken by events.
Practitioners sometimes say “Design Thinking” when they mean “Improvised.” They launch a crappy product or service, patch it in response to waves of crisis that follow, and tell people that they are being “Lean” or “Agile” or “User-Centered.” Don’t sell that methodology short (I call it Agilish), because sometimes it actually works. But it is a different methodology from Design Thinking, Lean or Agile.
Some stakeholders will NEVER buy into your Design Thinking process or outcomes. In the case of my teaching, for example, some students conclude that Design Thinking, with all of those Post-It Notes and Sharpie pens, is just busywork. I know this because they say so on their formal evaluations. I can tell them that Design Thinking is a powerful way to become a better collaborator and team member, and I do. I can tell them what I’ve witnessed in real-world workplaces, and I do. I can tell them that they can get better jobs, and I do. But they don’t believe any of that, either. My design does not answer their User Story.
These are not arguments that should cancel out the benefits of Design Thinking. But they are reminders that a nuanced take on iterative design is essential, and probably what will separate Design Thinking as a buzzword from Design Thinking as a methodology.
