Printable Version: Use the print command from the menu above to print this item.
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.
If we're using design thinking to solve problems, we'll work together in small, cross-functional groups and follow these basic steps:
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.
As an interesting side note, I'm told that children do this best. They haven't yet had the creativity beaten out of them. I tried this with my six-year-old and nine-year-old, and it held true for them. I saw more interesting ideas faster than I usually see with adults, who seem to be more concerned about wasting time than anything else. Ironically, that concern about wasting time seems to result in their moving more slowly.
The ideation stage is often considered a "widening" stage, in that we're increasing our field of possible solutions. A practice for ideating software UI design that's growing in popularity is design studio. First written about by Jeff White and Jim Ungar, the basic idea is to describe the problem we're trying to solve in the next product release and ask everyone to individually sketch his product ideas. It's a fast, collaborative way to involve the whole team in ideation.
Iterate: Combine, Test, and Refine Your Best Ideas
In software development, the word "iterate" may mean one of two things: repeat the same process, or make changes to software to improve it.
In agile development, an "iteration" (or "sprint" in Scrum) is the basic cycle of planning a small amount of work, doing the work, and then stopping to evaluate the work before restarting the cycle.
In design-speak, "iteration" means improving our idea by evaluating and changing it. Ideally, we'll evaluate the idea by testing a prototype of it and then change the idea to address issues found during testing.
In traditional software development, building and evaluating a prototype usually doesn't fit into the schedule. Remember, we often latch onto our first feasible idea. Why prototype and test it if we believe it's likely to work? Maybe I'm the only one with this problem, but once I begin implementing or using a software solution, I usually figure out I've got it wrong. In traditional software development, changing our design in response to what we learn usually carries the negative label "rework."
If we embrace design thinking, we'll combine and iterate the best ideas that came from ideation. We'll build simple prototypes that allow us to quickly evaluate and iteratively improve our design.
Over the years, I've relied more on simple, paper prototypes to validate software functional decisions. I'm not talking about the drawings of the user interface you describe to others to get feedback. While those can be valuable, what I'm really interested in is simulating the use of the software. That simulation is the difference between a prototype and a sketch or specification.
Using cut-out, cardstock components stuck to cardstock screens, I can ask someone to assume the role of a user of my product and to attempt to accomplish something. Since it's not real, working software, I'll move the paper in the prototype in response to the user's using a pen to write text and his finger to "click" buttons.
This style of testing is often called Wizard of Oz testing, after the scene in The Wizard of Oz in which we're asked to “pay no attention to that man behind the curtain." You'll be surprised how quickly users tune out the person moving paper around to simulate the software behavior and instead focus on achieving their goal with the software.
For more on paper prototyping to test and iterate software design, see my StickyMinds.com article "Test Software Before You Code." I've also written a handy reference on building and testing paper prototypes called "Paper Prototyping and Lightweight Usability Testing."
Plan and Execute Your Solution, Continuing Validation as You Go
Once we've iteratively tested a prototype of your solution, we'll reach a point where we've learned as much as we can without actually implementing the solution. It's important to recognize that, even if we do implement it, it's not guaranteed to work. Our execution plan needs to have time built in to continue validating the solution as it's built and to respond to what we learn when we do.
Those are the four basic characteristics of design thinking. It seems dead obvious to not try to solve a problem you don't understand. It makes sense to consider multiple solutions and then iteratively test solution candidates to refine them. But, in software development, we often jump right to building our first idea and then grumble that great products never seem to emerge.
Try injecting a little bit of design thinking into your next project. Be prepared for a bit of pushback from folks who say that there's not enough time to ideate and iterate. It will require a small leap of faith, but you'll quickly become addicted to the better results you get.
Design Thinking Concept and Practice Guide
Ideate Collaboratively Using Design Studio
About the Author
Jeff Patton leads Agile Product Design, a small consultancy that focuses on creating healthy processes that result in products that customers love. Articles, essays, and blog can be found at www.AgileProductDesign.com. Information about public classes, including Certified Scrum Training, can be found at www.AgileProductDesign.com/training.
StickyMinds.com Weekly Column From 12/6/2010