Design Thinking

Design Thinking - from ideo.com.

I went to a presentation at CCA Thursday by Tim Brown, CEO of Ideo. The presentation was structured as a conversation between Tim Brown and Mark Breitenberg, CCA's Provost, who himself has a record of leadership in design. In the talk, Tim Brown plugged his new book, Change by Design, which I haven't yet read.

During the talk, Tim Brown and Mark Breitenberg frequently used the term Design Thinking. It is a fairly new term to me and I didn't really understand what they meant by design thinking - at least in a way that distinguished it in my mind from thinking on the one hand or design on the other. I did hear lots of descriptive words - prototype, experiment, build, iterate, change, collaborate, reflect, observe, or analyze. In the end, though, I realized design thinking is a misnomer. What emerged (consistent with here and here) is that design thinking is not a type of thinking, like, say, analytic thinking or creative thinking, but rather it is a label for a methodology or process model, like the waterfall or spiral methodology. Design thinking is a shortcut for referring to the process that designers typically follow.

My first response was to wonder: in these days of interdisciplinary teams, how is it helpful to adopt a label for a team process which privileges one discipline over others? Design thinking hints at hubris. It is liable to lead to turf wars. I imagine non-designers seeing this as a branding tactic that positions the designers as the source of cool.

Next, I thought: it is a clever label. Designers are cool, after all. So this methodology must be cool too. And because it involves thinking it must also be smart, in the same way Adidas shoes are intelligent. What could be better? If I had to pick between, say, "human centered design methodology" and "design thinking" I know what I would swing for.

Clever labels are not necessarily good ones. I'm reminded of George Orwell's great essay on Politics in the English Language. Orwell notes that language is full of tired metaphors that people use automatically and without thought. He argues that we should always seek out fresh metaphors that evoke clear images and assist thought. As a metaphor, design thinking is fresh and appealing. However it is far from a clear image that assists thought. Quite the opposite, design thinking is so vague and sounds so good that people (myself included) immediately want to use it regardless of what it actually means. The result is a cacophony of claims. We learn that design thinking is "what all the creative people do", or it is "about innovation and creativity." It is "a human centered systems thinking that enriches life." "Design thinking converts need into demand" writes Tim Brown. Design thinking is the change agent that will lead us to a better world, where complex problems are addressed in a transparent, inspiring, transformational, participatory, contextual, sustainable way.

Design thinking has grown to become far more than a label for a process. It is a movement, a group of people sharing a vision for how to make better things. Coming from the software industry, I've seen similar movements there, all aiming to overlay some kind of roadmap over the chaotic moshpit of innovation. Scrum, extreme programming (xp), test driven development, agile, ... I could go on. Coders are a vanguard of process innovation. They are also in the unique position of being able to build software tools to assist in and instrument these methodologies. You could argue (eager as I am to use the term) that coders have been applying design thinking to the problem of software design for 25 years.

What have we learnt? That we haven't finished yet. The core of the problem is that innovation involves building things that haven't been built before and thinking things that haven't been thought before. To innovate you have to leave the map. Methodologies, on the other hand, always produce a map, structuring what innovations are possible. Methodologies only help innovation to the extent that the map they produce doesn't get in the way. In other words, the team using the methodology must realize that it is not the methodology that innovates. Design thinking does not think in exactly the same way that Microsoft Word does not write. Thought takes place in the complexity of dissensus, where we leave behind labels like "designer", "coder", "user" and "product".

Ultimately, it is about what works. In software, I've seen teams that adopted rigorous methodologies only to crash and burn, and teams who followed almost no methodology who then thrived and excelled. In my experience the methodologies that work best are those which start with modest claims and a lightweight infrastructure, provide a barebones of management scaffolding, and then slip into the background. The more sophisticated, complex, ambiguous, ambitious or vague the methodology, the more steps there are, the more room there is for debate about the methodology itself - all of which is time taken away from getting it done.

Will design thinking stick? It is probably too early to say. But, even if we question the label, or wonder at the efficacy of the methodology, we should agree with the intent of design thinking: our goal is to expand human-centered approaches across our organizations and companies. Meanwhile, back to the moshpit.