This curated column is authored by author, professor and speaker, Christina Wodtke
If you like this article, you probably want to sign up to be notified when my new book on Visual Thinking is out (in less than a month, I promise!)
When I first heard about Design Thinking, I thought it was a clever rebranding effort by IDEO to charge twice as much for user-centered design. What can I say, I’m an old fart of a designer, and when I read about design thinking, I didn’t really see the big whup. And I wasn’t alone.
But over time I’ve discovered that the oft-parodied approach to Design Thinking — a lot of post-its and a lot of prototyping — works better than nearly any other approach to product and service innovation.
Do designers truly think in a different way?
The key is the word “thinking.” I want to make an argument that Design Thinking is a kind of thinking based on three key cognition theories:
- Distributed Cognition
- Expertise Thinking
- Iterative World Modeling
Let me break each of these ideas down:
Distributed Cognition (or embodied cognition) is the most current understanding of how cognition works. It states that rather than thinking only with our brains, we think with our environments.
For example, imagine you are playing scrabble.
What if you couldn’t rearrange the tiles? Would this slow you down? Would you make lower scoring words?
Any scrabble player would tell you yes. Any poker or bridge player would tell you they always arrange the cards in their hands to support their strategy. Anyone doing long division would prefer to do it with a pencil and paper than in their head. A designer trying to understand how to organize content would prefer to do it with post-its. (or index cards. As long as it’s modular.)
When you see a workshop teaching Design Thinking, it usually leverages three easy-to-learn distributed cognition tools:
- Making information modular so it can be manipulated (tl;dr put data on post-its so you can rearrange it)
- Modeling existing and proposed systems via sketching. Mindmaps and storyboards are two examples.
- Prototyping potential solutions for understanding and evaluation. This can be as simple as bodystorming or as complex as 3D printing.
All of these Design Thinking techniques are distributed cognition techniques that:
- Move memory out of your head into the world, freeing up processing power.
- Allow you to see connections and relationships you can’t easily visualize in your head.
- Create a shared understanding for teams. Now your team can be part of that distributed world you think with.
Distributed cognition is a very simple idea: Thinking with your brain and objects in the world is not a better way to think; it’s natural. Humans aren’t just tool users. We are tool thinkers.
Distributed cognition helps everyone think better. Agile Practitioners use kanban boards as a combination memory enhancer and strategy accelerator. My financial planner just had me create a mindmap to see where my money is and where it goes. Getting Things Done demands you move your task lists out of your head and onto paper so you can think through harder problems. These are all distributed cognition strategies.
So if everyone uses distributed cognition, what makes Design Thinking Design Thinking?
Design Thinking as Expertise Thinking
We all use the world as an extension of our mind. As we do so, we get better at it. We discover tools and develop techniques, and we get higher and higher returns as we get better at these tools. Different professions use different approaches, and thus develop different ways to think about a given problem.
For example, let’s call the way that chefs work, Chef Thinking(TM). Chefs have a class of problems (preparing food) and a body of skills to combine into a set of solutions. Three of the key ones:
- Knifework. If you take a knife skills class, you begin to understand that knives cut, but they also saw, slice, smash, poke and more. The knife becomes an extension of your body (called a transparent instrument in the literature.)
- Managing Fire. Sure you can put a pan on the fire, but you can also make it into a steamer, a oven, or even offset it to create hot spots and cool.
- Ingredients. A chef knows how to make poor ingredients taste nice, how to show off great ingredients, and how to combine ingredients into flavor profiles that evoke Japan, Mexico or Italy.
Chefs also have standard methodologies, like mise en place or the brigade. Over time, a chef does not have to look up what spice to use, or how to bone a fish. She is only thinking about how to use the salmon before it goes bad, and the techniques to do so are invisible to her conscious mind. After I went to culinary school, knife and fire became extensions of myself. I can open any fridge and cook something. Hunger is a problem I solve with Chef Thinking(TM).
Let’s return to design thinking. Over time designers have built up their own body of approaches to solving classes of problems. While architecture and graphic design are almost as old as cooking, interactive product design is emergent and thus pretty untidy. But here are a few classes of problems and collections of how designers solve them:
- Context analysis: Interviews, empathy, contextual inquiry, listening sessions, diary studies as all tools for getting a fresh understanding of the context in which one will be designing. And there are way more.
- Sensemaking: When you have too many ideas, too much information, how do you find insights? Well, there are always Post-its. See Needfinding for Disruptive Innovation.
- Idea generation. Mature designers know that even if your first idea is brilliant, you’ll never know unless you come up with 20 more. Sprints and Charettes are techniques for finding and refining potential solutions.
- Product definition: Conceptual models, sitemaps, flowcharts, wireflows, use cases, user stories… so many ways to ask engineers to “build this.”
- Idea Validation. Part of thinking with the world is working with the world of users. From participatory design to usability testing, effective designers find ways to evaluate the quality of their thinking with the people who really pay the bills: customers
Look closely at my list and you’ll see it maps to the d.School’s definition of Design Thinking (more or less.) The diagram looks facile, but each hexagon represents huge bodies of experiential learning.
For example, a non-designer “ideates” by thinking up an idea.
A designer thinks up dozens, exploring the good, the bad and the weird, sketches them, combines them, critiques them, refines them, develops them, remixes them and only then moves on to prototyping them. It’s the same for Define or Test. Each one of those hexes represents a dozen techniques and years of practice.
Young designers fresh from school are equipped with a subset of these tools, but it takes time to gain mastery. As you can see by the list above, there are a LOT of ways to solve problems, and part of being an expert is knowing which tools to use when to get the best result.
Sure you can take a weekend workshop on design thinking or knifeskills, and it will help you be better at what you are trying to accomplish. But only practice turns those skills into a habit, then a transparent instrument, and finally give you the mastery you need to solve wicked problems.
Iterative World Modeling
A long time ago, when I was a manager of a team of 80 designers at Yahoo!, I wondered, “what is design’s unique capability?” What did design do for the business that product management, research, marketing and engineer couldn’t? I decided it was
“Design makes ideas tangible so that they can be understood and evaluated before committing them to reality.”
Design work is two kinds of world modeling work:
- Modeling the world as it is.
- Modeling the world as it could be.
Designers create mental models and system models to document the current state of their corner of the world. Designers model both the object of the design challenge and the ecosystem it resides in. Design Thinking is Systems Thinking. Then designers make concept models, site maps, flow diagrams and more to model the future desired state. (I’ve written a lot on working with models.)
Designers don’t necessarily build that new version of the world — engineers, contractors, printers and many others play their parts — but they do show the path forward for change. This is more powerful than most realize. I have seen a executive look at a mock and suddenly see a path forward for his company. I’ve seen an engineer say, “that’s not feasible,” and the exec reply, “But it’s right there.” The exec saw it, and now must have it.
Seeing is really is believing.
Because models work to well for both understanding and planning, senior designers, such as Dave Gray, often use them to design organizations as well as products. Business strategists such as Alex Osterwalder and lean startup coaches such as David Bland create models in order to create understanding and lead change.
A prototype (see the hexes) is just a higher fidelity model. It is still a cheaper-than-making-the-real-thing way to understand and evaluate. A prototype is a way to see the future and judge if it’s worth building.
When designers model the world as it is, they create understanding.
When they model the world as it could be, they create inspiration.
To think like a designer is to see the world as it is, and find a path forward to what it could be.
Design Thinking as a Way
As tech matures, approaches to creating digital product and services are emerging. Agile helps engineers build the right things at the right time. Lean Startup helps business owners build the right things at the right time. These techniques are not only successful, but transferable. People do stand-up with their families, they publish books using lean, even approach Thanksgiving dinner as if it were an engineering project. Agile and Lean Startup aren’t just methodologies; they are a way to work through complex systems toward a desired result.
Design Thinking has recently been adopted by the Lean and Agile communities as another way to build the right thing at the right time. There has been some anxiety from old fart designers (ok, like me) that product managers and business owners will take a design thinking class and think they are designers. I haven’t seen that. What I’ve seen is a greater desire for design literacy — including learning how to use Design Thinking — and that leads to a greater desire to hire designers. (Your mileage may vary. I’m sure there will be plenty of responses to the contrary.)
Design Thinking is not design, no more than Agile is engineering or Lean is business management.
Everyone should learn Agile, but engineers still write the code.
Everyone should learn Lean, but business people and product managers still design the business model (and solve pricing, and do customer acquisition, and sales, and watch metrics, etc etc. I know you’re tired.).
Everyone should learn Design Thinking. But also remember that a mature designer has the mastery — the expertise — to effectively envision the world as it could be, and make a plan for how to get there.
As Design Thinking gains greater acceptance as a powerful tool for innovation, I think we’ll see more people who are design literate. They will understand both Design Thinking and Design Doing: what it takes to design something great. And they’ll realize it’s hard, and takes training and practice.
When companies become design literate, they’ll use design thinking to solve problems such as improving team dynamics or coming up with a product line extension. Design Thinking is a terrific approach for coming up with viable ideas for innovative improvement. But design itself is much more.
Design is the art of the making the complex clear, the disordered ordered, the unusable usable. So when companies run into a truly intractable challenge such as a complex tool menu that needs sorting out, or integrating an algorithm that doesn’t make sense to users, or finding a market application for a crazy bit of new technology… the first they’ll want to do is a hire a good designer.
Disclaimer: This is a curated post. The statements, opinions and data contained in this column are solely those of the individual authors and contributors and not that of iamwire or the editor(s). The article was originally published by the author here.