[First Published at MSDN, March 2000]

When I was a Computer Science student at Carnegie Mellon University, I discovered I was a mediocre programmer. Late in my sophomore year I realized I needed a new career, provoking a a desperate search through the course catalog. I discovered there were classes in something called design and I signed up for one. It was a project based class with design majors where they collaborated with engineering students like me, and I eagerly looked forward to what this new world of thinking would be like.

The first day of class I arrived at the studio room and found a young man at a drawing table, sketching out variations for the Walkman he was designing. I got close enough to see the large sketchpad and saw at least 30 different variations that he had put down. I watched as he patiently started each new one, surprised by how he never seemed satisfied.

I introduced myself, pleaded ignorance about design, and asked him why he needed to make so many sketches. He thought for a second, and then said, “I don’t know what a good idea looks like until I’ve seen the bad ones.” I smiled, but was puzzled. I felt like going back across campus to the computer science lab. If he’s a senior designer, shouldn’t he make fewer sketches instead of more? I didn’t really understand what he was talking about until many years later.

When I started working at Microsoft after college, I was embarrassed to document bad ideas. I kept a notebook with me at all times to write down ideas when I was in meetings, or traveling on the bus to work, but I never let anyone see it. Many of these ideas were awful, just plain unworkable. But with each idea I came up with, no matter how bad, it revealed some other way of thinking about the problem. Each new idea I sketched out was more informed than the last. Each bad idea illustrated some important aspect of the problem that I hadn’t thought about before. Out of every five or six ideas, I’d have one or two that might be feasible. The sketching helped me, but it was something I didn’t want others to know I did. I thought folks would think I wasn’t a good designer if they saw how many sketches I made.

When it came time to present ideas to others, I’d lead with my single best idea. I hoped I wouldn’t be asked about the others. I was always wrong. There are so many viable alternatives for everything that to only show one idea invites people with their own opinions (which is just about everyone) to point out their favorite alternative. They ask how you know yours is better. It’s a frustrating process that I was not prepared for and hated.

Over many painful design meetings, I learned the right way to present ideas is to tell the story of how you arrive at your conclusion. It doesn’t have to be long, but it has to be clear. The challenge isn’t to present one single idea as good, few will believe this. Instead it’s to frame ideas in way that informs everyone in how to evaluate all the ideas. If I did the homework of exploring alternatives, which I should, then it shouldn’t be hard to lead people in following my thinking.

This means establishing clear goals. It means exploring tradeoffs. It may include showing how one alternative is better in one way, but worse in another. It provides a rationale and that’s often what people need to accept something. Showing multiple ideas this way also invites people to make improvements I didn’t consider, like taking something from design A and adding it to design B. That wouldn’t be possible if I only offered one single possibility.

Sometimes I encounter a problem that is insanely hard. The only possibilities, because of technology or schedule limitations, are really just terrible. By any other standard they’d be rejected, but real projects in the real world can be a different universe than the mythical design process that’s often taught in school.

Facing this challenge, and after days of intense but fruitless sketching, I’ll feel depressed and regroup by asking others for their opinions. The magical thing that happens is if you’re convinced you’ve considered all reasonable possibilities, from yourself or from others, a deductive process can begin.  I can write all possible choices on the whiteboard and sit down with a smile. I know that somewhere on that board is the right answer. When people come by my office and ask me what we’re going to do, at least I can point and say it’s up there somewhere.

There is a psychological advantage to containing the space of choices in this way. To decide, I’ll make a pro and con list for each choice, and rely on my designer, developer, or other key people to help make the call. Choosing the best among bad ideas isn’t a highlight of design work, but it happens. The right process combined with a dedication to pursuing several ideas makes an impossible situation bearable, and gives you the confidence to make a decision.

When the design student showed me his sketches, he was showing me that he was a confident designer. All creative, talented people recognize the value of process. The ones who trust their craft have few concerns about revealing to others that it takes many bad ideas to obtain good ones. You want the bad ideas to come out on sketch paper or in prototypes, not in the product, and you can only do that by expending the energy to explore lots of ideas. If quality design work is important, you have to make sure managers set their schedules to allow it to happen, and pace the range of your thinking to match the schedule.

A common trap for design thinking is searching for perfect designs the belief that there is a single right answer to a given problem, and a designer should be able to realize it given enough time. In many cases, the best possible design (if there is such a thing) isn’t worth more than a good one, especially if it takes twice as much time to find it. General George S. Patton once wrote, “A good plan executed now is better than the perfect plan next week.” You have to know the realities of the competitive and financial plan your team is working from, and adjust the goals of your design work to match them. Make the top three or five user tasks rock solid, and keep the rest simple but adequate until the next release.

The more I read about masters in different fields, the more I see how there is a common thread in their work process. Every great writer, painter, architect, or director attributes the quality of their work to tireless discipline. When asked about their artistry, they don’t point to magic or divine inspiration, but describe how many attempts they must make to create things of the quality they desire.

I’ll close this column with comments from various well-known figures. I seem to be making a habit of quoting people, but these folks have more credibility than I do:

“The two most important tools an architect has are the eraser in the drawing room and the sledge hammer on the construction site.” Frank Lloyd Wright

Hemingway rewrote the ending to A Farewell to Arms 39 times. When asked about how he achieved his great works, he said, “I write 99 pages of crap for every one page of masterpiece.” He has also been quoted as saying “the first draft of anything is shit.”

“The physicist’s greatest tool is his wastebasket.” Albert Einstein

“Rewrite and revise. Do not be afraid to seize what you have and cut it to ribbons” – Good writing means good revising.” Strunk and White, Elements of Style

[This essay was a sequel to a prior MSDN essay, Making Usable Products: An Informal Process for Good User Interfaces.]