Why Good Design Comes from Bad Design
Scott Berkun
Microsoft Corporation
March/April 2000
Summary: Follow-up to an early column on designing good UI. (3 printed pages)
I've received several requests to complete the missing part two of an earlier column, Making Usable Products: An Informal Process for Good User Interfaces. I read this early column again recently and thought it was awful. So now you're getting part two, which, in my mind, is really a thinly veiled revision of and improvement on part one. Perhaps you won't notice, but of course now that I've told you, you'll probably go back and look at the first one and be really disappointed that I've had a year to write part two and this is the best I could do.
When I was a computer science/philosophy student at CMU, I took a design project course to learn about all of this interface design stuff I'd heard about. The first day of class I arrived at the studio room, and found a young man at a drawing table, sketching out different variations of the Walkman? he was designing. I got close enough to see the large sketchpad and saw 30 or 40 different variations that he had considered and put down on paper. 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 labs. If he's a 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 at Microsoft, 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 developers, managers, or usability engineers, I'd lead with my single best idea. I'd invest time in fleshing out only my best candidate, and hoped I wouldn't be asked about the others. I was always wrong. There are so many variations for designing a Web page, that if you only show one idea, anyone who thinks they can design something (which includes everyone) will point out several alternatives to you, and ask why the idea you're going with isn't the one they just came up with. It can be a frustrating process, especially if the suggestion is one you've already considered, because no one seems to believe you when you tell them that.
After many painful review meetings, and hearing advice from seasoned designers, I learned the right way to present ideas—you have to show the other candidates in order to help support the good ones. I began the habit of presenting three to seven different ideas, culling from my total set of ideas the ones that represented the most distinctive or meaningful choices. When in a meeting I now walk through the different designs, calling out what the key trade-offs are between them. When discussing ideas, I call out important negative qualities that are only answered by the idea I'm recommending, which helps set up my recommendation to be well received. Often someone will make a good suggestion for taking something from design A and adding it to design B. That wouldn't be possible if I had only fleshed out a single idea.
Every so often I'll work on a problem that is insanely hard. The only possibilities, because of technology or schedule limitations, are tragically bad. After a few days of intense but fruitless sketching, I'll feel depressed and try to regroup by asking others for their opinions. The magical thing that happens is once you're convinced you've considered all reasonable possibilities, a deductive process can begin; I'll 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 designer. All creative, talented people recognize the value of process, and have no 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 tomorrow. 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. On most Web schedules, it's critical that design energy is prioritized and focused. 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 great 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 slightly 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.
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
出處：中國UI設(shè)計(jì)網(wǎng)
責(zé)任編輯：藍(lán)色
上一頁 為什么好設(shè)計(jì)是來自于差的設(shè)計(jì) 下一頁
|
第 1 頁 
第 2 頁 Why Good Design Comes from Bad Design
