Dave, I'm currently taking a welding class. To learn how to weld, I am making lines of weld-bead on sheets of scrap aluminum. This is a very useful pedagogic device.
After a couple of years of practice and training (assuming I were a young person making a career out of welding), I'd go into the world as a journeyman welder. I would never, ever make lines of weld-bead on sheets of aluminum again, since it has virtually no practical purpose. About two-thirds of the need for prototyping is as an equivalent, pedagogic tool. Young interaction designer trainees need to see how humans react to their designs, and prototypes are an excellent tool for that. Once you've learned how humans react, you no longer really need to actually, physically test your designs. Your experience will tell you just as dependably. The other third of the need for prototyping is for invention, a very rare occurrence. Invention means pure, new, never-before-seen modes of behavior. A couple of years ago, for example, I was working on an email program where individual conversations (threads) were represented by icon-like images. Those images were "orbited" by related messages, images, files, correspondents and other relevant information. Nothing like this had ever been done before, so prototyping was appropriate. But please understand that invention is not the same thing as design. Prototyping is useful in invention, but its role isn't for design as much as it is for raw exploration of the subject matter before design is even necessary. Such a prototype would then be used as a guide for subsequent design (on paper, not in code). Historically, software comes from a world rich in invention, and the enormous egos in the software business still imagine that invention dominates. Most programmers and most interaction designers think that they are inventing when they are creating yet another eCommerce website. The cries for and claims of innovation are evidence of that. But the overwhelming quantity of what I see in the world of software today simply isn't invention but is the basic block-and-tackle, three-yards-and-a-cloud-of-dust form and behavior design like we all learned in school or on the job. Their users are consumers or business people doing simple, business or personal tasks using well established idioms, typically implemented using off-the-shelf components arranged in very conventional ways. Recent "innovations" such as YouTube and even Crowdvine simply don't show any interaction innovation. Good, solid, workmanlike design, yes; prototype worthy innovation, no. Before interaction design gained its contemporary respect, old-school HCI practitioners claimed emphatically to me, "I learned so much when I did user testing!" Of course you did. You never had any design training so it was a complete shock to you when you saw how humans reacted to software. Today, it is unconscionable for a professional interaction designer to NEED to user test anything but the most advanced, obscure, never-before-seen interaction. And prototyping is very time and money intensive, particularly so when compared to what well trained designers can do with a couple of 90-minute interviews and a whiteboard. Please remember that prototype code is subject to the law of fools: they see it and they think you can SHIP IT! And then WE are stuck with a commitment to a non-optimal strategy. Why take that risk? You know, I don't really care anymore whether or not interaction designers prototype or not. I took a clear and bold and absolute stand against prototyping 15 years ago to make a point: that we can do good design without code. This was a necessary decoupling to allow the profession of interaction design to separate, differentiate, and elevate ourselves away from programming. Well, we've accomplished that goal, as Interaction08 proved beyond a doubt. And now that we are indeed separate, different, and elevated, there isn't a big downside to prototyping. Mainly it's like using a sledgehammer to kill a fly. If it floats your boat, go for it! The next big battle we are going to have to fight is the one to stay ahead of the Agile folks. They mean well, and agile makes programmers happy, and managers LOVE to hear that the programmers are happy. But Agile is a terrible tool for software production, even if it's a pretty good tool for software design engineering. We need to communicate this indispensable difference. Let's all stay focused on the big prize. Thanx, Alan __________ cooper | Product Design for a Digital World Alan Cooper [EMAIL PROTECTED] | www.cooper.com All information in this message is proprietary & confidential. "Kipling was right: leaders and talkers and theorists forget how they depend on oily hands and long apprenticeships." -Libby Purves -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Malouf Sent: Wednesday, February 13, 2008 1:20 PM To: IxDA Discuss Subject: [IxDA Discuss] prototypes are software and belong to engineers? I was reading that transcript that Gabriel pointed to earlier today: (link: ) here is the last question's answer: "Coop[er]: Bad idea. Prototypes are software. I believe that there's a role for prototypes in interaction design, but I believe it's a very small and limited role. It's primarily done as a narrative, not as software. The risk of doing interaction design in a medium of code is much greater than the benefits yield for you. We as competent craftspeople should be able to communicate with great precision and clarity what we intend the software to do without resorting to code. Code is a sledgehammer here. Prototypes are code that has not achieved released. Snippets of disposable code are great tools for design engineers, but they don't play a large role for interaction designers." Alan since I know you're here. ;) i wonder if you can expand on this a bit. I trust you have good reasons and experience for this, but it goes counter to my own both in IxD and in ID. Maybe I'm reading to much in certain spots. But I'll posit that doing interaction design w/o creating interactions in some form is akin to doing visual design w/o using color (but expecting color in the final solution, saying that the printer will handle it). Now that I put that out there, I'm curious. What I'm not interested in, is the education component. I'm assuming that tools are or will be easy enough and good at hiding real code that the skills to acquire this craft is not an issue. -- dave -- David Malouf http://synapticburn.com/ http://ixda.org/ http://motorola.com/ ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
