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.
Done? Good.
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.
Figure 2: My daughters and their smiley faces
The schedule is the villain in today's fast-paced software development world. When trying to solve a real-world problem, we're quick to stop brainstorming and start criticizing ideas—even our own. We may know academically that our best ideas are rarely our first, yet we're quick to settle on our first feasible idea. In business, being the first with an idea is usually considered a sign of competence. If we embrace design thinking, being the first with the most ideas is best.
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.
Figure 3: Paper prototyping in progress
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 Studio Recipe Jeff White and Jim Ungar's design studio is a quick way to get a whole team involved in brainstorming multiple product ideas. Use design studio to kick off a product design process.
|
Resources
Design Thinking Concept and Practice Guide
Ideate Collaboratively Using Design Studio
