I'm reading a book recommended by one of my newsletter readers: Emotional Design: Why We Love (Or Hate) Everyday Things. Written by Donald Norman (of The Psychology of Everyday Things fame), the book explores why usability alone isn't enough. Norman argues that we appreciate things on three levels: visceral, behavioral, and reflective.

Visceral attraction is that which we feel for a Ferrari or an iPod. It's beautiful and we want to sit in it (Ferrari) or touch it (iPod). Behavioral attraction is the appreciation for something that works very well. The word we often used to describe it is "intuitive". Finally, reflective attraction is about meaning and self-image.

Norman argues that great design incorporates all three aspects and produces things we love. He even argues that well-designed objects make us work better. I won't try to explain his thinking, but his arguments did get me to think about something I've talked a lot about: prototypes.

In the design world, prototypes are an absolute necessity. When the designer of the original Palm Pilot was working on a design, he carried a block of wood around in his pocket. What was comfortable? What felt too big? Too small? Were the buttons right?

And yet, for some reason, many developers feel that "design" is something best left to graphics artists. But when I talk about the necessity for prototypes, it's not just look and feel that I'm stressing, but rather that the very act of using something reveals what we want from that thing. Until I see the iPod's spin-wheel, I don't know that I want it at all. It's no good asking me for "requirements". If I knew that, I could just hire a 16-year old programmer.

I believe that in almost all cases of business software, working without prototypes entails great (and needless) risk to both developer and client. Requirements documents may be useful for lawyers, but they have limited usefulness to us. Prototypes allow us to try out new ideas and see how users react to them. They give us the freedom to explore the visceral and behavioral aspects of design--and maybe even the reflective.

I've been using prototypes for quite a while. My first explorations with them was constrained to exploring behavioral issues. "Don't worry about the look and feel," I would tell clients. But they would worry about the look and feel. I finally realized that until I took care of this need of the client--no matter how secondary in importance it seemed to me--we simply couldn't move on to the issues that were of great concern to me: how the application needed to behave.

Years ago, Abraham Maslow arrived at his "Hierarchy of Needs" for individuals.

1. Physical survival: water, food, sleep, shelter...
2. Safety and security: physical safety, economic security, comfort...
3. Social needs/belonging: acceptance, group membership, love, affection...
4. Self-esteem: recognition of mastery, prestige, status...
5. Self-actualization: innovation, creativity, deep learning...

Until a lower-level need was satisfied, Maslow argued, people couldn't attain satisfaction of needs higher up the hierarchy. The problem with starting with requirements documents, flowcharts, UML diagrams and the like is that these don't deal with the client's basic concerns: what will this look and feel like? What will it be like to work with?

Prototypes answer those questions and allow us to introduce ideas and get feedback from clients in ways that words simply cannot. They give us a common langugage that has a specificity and concreteness to it that words lack. I believe that great applications--like other great designs--must incorporate visceral, behavioral, and reflective appeal and I can think of no better way to begin the process than with a thorough, comprehensive prototype.