Design thinking points out several missed steps in software development. And, while some may believe ideation and iteration to be wasteful, they're easy to add to the development process at low cost and, in the end, result in substantially more valuable software. In this article, Jeff Patton describes the four basic steps of design thinking.
I hear the term "design thinking" more and more in conversation lately. Design thinking describes a problem-solving approach that seems like common sense, but, like many commonsense ideas, it isn't commonly used. Knowing the basics of design thinking can point out several missed steps in your software design and development approach—steps that, when added, can substantially increase the value you get from your software.
Design thinking has become a fashionable, "new" concept supported by an increasing number of books and articles, but it's not really new–just the name and the way we talk about it.
When I say "design," the person I'm talking to usually interprets the word to mean one of a variety of things. Some think I mean the design of code or the design of the user interface. Non-software people often think of cool products like Apple mobile devices or IKEA furniture. Those are examples of pretty good intentional design, but we're talking about the thinking that leads to those things.
My friend Alistair Cockburn says, "If it's your decision to make, it's design. If it's not, it's a requirement." By design thinking, we mean approaching decisions and solving problems—from fixing a bad business process to solving a complicated software issue—the way a designer does.
Figure 1: How design thinking solves problems
If we're using design thinking to solve problems, we'll work together in small, cross-functional groups and follow these basic steps:
- Understand the problem you intend to solve.
- Ideate: Consider lots of alternative solutions.
- Iterate: Combine, test, and refine your best ideas.
- Plan and execute your solution, continuing validation as you go.
Understand the Problem You Intend to Solve
This may mean backing up from a proposed solution and asking why it's a good solution. Understanding the problem might take a little research—ideally, observing the problem as it happens. In software development, this may mean watching users work with their current bad software or process. For programming problems, it may mean diving deep into code that’s not working well or studying the environment where code will eventually be deployed.
Hidden in this problem space we've taken time to understand are the reasons why you've chosen to invent a new solution. Focus your solution design activities by stating clearly the problem you're trying to solve.
Ideate: Consider Lots of Alternative Solutions
"Ideate" means brainstorm multiple, diverse ideas. While brainstorming, all ideas are good. Defer judgment until you get lots of ideas on the table.
Try this quick exercise: Pull out a piece of paper and a pen. In the upper left corner, draw a smiley face. Now, draw twenty additional, unique faces. Try to come up with the most fun, simple face you can. If you're having trouble coming up with faces, think of professions like doctor or pirate or animals like tigers or pigs.
You probably went through a difficult phase around face five or six, when it was harder to come up with new ideas. But, then it got a bit easier. Likely, some of your most interesting drawings came after that time.
I do this exercise with large groups. After they finish, I ask each participant to pass the paper to the person on his left, so the neighbor can select her favorite face. Everyone learns two things: Your first ideas are rarely your best, and everyone has a different idea of what "best" ideas really are.