The Inmates are Running the Asylum -...
57
Transcript of The Inmates are Running the Asylum -...
a l a n c o o p e r
A Division of Pearson Education800 East 96th Street, Indianapolis, Indiana 46240
The Inmates Are Running the Asylum
Copyright © 2004 by Sams Publishing
All rights reserved. No part of this book shall be reproduced,stored in a retrieval system, or transmitted by any means, elec-tronic, mechanical, photocopying, recording, or otherwise, with-out written permission from the publisher. No patent liability isassumed with respect to the use of the information containedherein. Although every precaution has been taken in the prepa-ration of this book, the publisher and author assume no respon-sibility for errors or omissions. Nor is any liability assumed fordamages resulting from the use of the information containedherein.
International Standard Book Number: 0-672-32614-0
Library of Congress Catalog Card Number: 2003116997
Printed in the United States of America
First Printing: March 2004
07 06 05 4 3
Trademarks
All terms mentioned in this book that are known to be trade-marks or service marks have been appropriately capitalized.Sams Publishing cannot attest to the accuracy of this informa-tion. Use of a term in this book should not be regarded as affect-ing the validity of any trademark or service mark.
Goal-Directed design is a trademark of Cooper Interaction Design.
Warning and Disclaimer
Every effort has been made to make this book as complete andas accurate as possible, but no warranty or fitness is implied.The information provided is on an “as is” basis. The author andthe publisher shall have neither liability nor responsibility to anyperson or entity with respect to any loss or damages arising fromthe information contained in this book.
Bulk Sales
Sams Publishing offers excellent discounts on this book whenordered in quantity for bulk purchases or special sales. For moreinformation, please contact
U.S. Corporate and Government [email protected]
For sales outside of the U.S., please contact
International [email protected]
PublisherPaul Boger
Executive EditorCandace Hall
Managing EditorCharlotte Clapp
Project EditorDan Knott
Copy EditorEileen Cohen
IndexerKen Johnson
ProofreaderJuli Cook
Publishing CoordinatorCindy Teeters
Interior DesignerKaren Ruggles
Cover DesignerAlan Clements
Page LayoutEric S. Miller
Dedication
For Sue, Scott and Marty, with love.
Acknowledgments
I could not have written this book without the care and help of many wonderfulfriends and colleagues. In particular, several people performed the demandingand difficult job of reading and commenting on the manuscript, sometimesmore than once. Their comments made me answer tough questions, introducemy topics, sum up my points, quench my flames, and corral my wild fits ofindignation. The book is far better because of the contributions of KimGoodwin, Lane Halley, Kelly Bowman, Scott McGregor, David West, MikeNelson, Mark Dziersk, Alan Karp, Terry Swack, Louie Weitzman, WayneGreenwood, Ryan Olshavsky, John Meyer, Lisa Saunders, Winnie Shows, KevinWandryk, Glenn Halstead, Bryan O’Sullivan, Chuck Owen, Mike Swaine, andSkip Walter. I really appreciate your time, care, and wisdom. In particular,Jonathan Korman’s comments and counsel were invaluable in helping me todistill my themes. I must also thank all the talented and hard-working people atCooper Interaction Design who did my job for me while I was busy writing.Deserving of special thanks is Design Director Wayne Greenwood, who did agreat job under pressure keeping our design quality and morale high.
Getting the illustrations done turned out to be one of the more interesting pro-duction challenges. Chad Kubo, the masterful creator of the images, did aremarkable job of interpreting my vague ideas into crisp and memorableimages. They add a lot to the book. The illustrations could not have been doneat all without the tireless art direction work of Penny Bayless and David Hale.Still others helped with the many production tasks. Thanks to Brit Katzen forfact checking and research and Mike Henry for copy editing.
Writing a book is a business, and for making it a successful one I also owe sin-cere thanks to my team of technology-savvy businesspersons, headed by myagent Jim Levine, and including Glenn Halstead, Lynne Bowman, KellyBowman, and Sue Cooper. At Pearson, Brad Jones supported this projectthroughout, but the most credit goes to Chris Webb, whose tenacity, focus, andhard work really made The Inmates happen.
I really appreciate the many people who provided moral support, anecdotes,advice, and time. Thanks very much to Daniel Appleman, Todd Basche, ChrisBauer, Jeff Bezos, Alice Blair, Michel Bourque, Po Bronson, Steve Calde, DavidCarlick, Jeff Carlick, Carol Christie, Clay Collier, Kendall Cosby, Dan Crane,Robert X. Cringely, Troy Daniels, Lisa Powers, Philip Englehardt, Karen Evensen,Ridgely Evers, Royal Farros, Pat Fleck, David Fore, Ed Forman, Ed Fredkin, Jean-Louis Gassee, Jim Gay, Russ Goldin, Vlad Gorelik, Marcia Gregory, GarrettGruener, Chuck Hartledge, Ted Harwood, Will Hearst, Tamra Heathershaw-Hart, J.D. Hildebrand, Laurie Hills, Peter Hirshberg, Larry Keeley, Gary Kratkin,Deborah Kurata, Tom Lafleur, Paul Laughton, Ellen Levy, Steven List, T.C.Mangan, David Maister, Robert May, Don McKinney, Kathryn Meadows, LisaMitchell, Geoffrey Moore, Bruce Mowery, Nate Myers, Ed Niehaus, ConstancePetersen, Keith Pleas, Robert Reimann, John Rivlin, Howard Rheingold, HeidiRoizen, Neil Rubenking, Paul Saffo, Josh Seiden, Russ Siegelman, Donna Slote,Linda Stone, Toni Walker, Kevin Weeks, Kevin Welch, Dan Willis, HeatherWinkle, Stephen Wildstrom, Terry Winograd, John Zicker, and PierluigiZappacosta.
This “year long” project took 20 months, and my family showed great patiencewith me. I owe the greatest debt of love and thanks to my wife, Sue Cooper, andto my handsome young sons, Scott and Marty. I love you with all of my heart.
Table of Contents
Foreword..........................................................................................xvii
Part I Computer Obliteracy
Chapter 1 Riddles for the Information Age ........................................................3
What Do You Get When You Cross a Computer
with an Airplane? ................................................................................3
What Do You Get When You Cross a Computer
with a Camera?....................................................................................4
What Do You Get When You Cross a Computer
with an Alarm Clock?..........................................................................6
What Do You Get When You Cross a Computer with a Car? ..........8
What Do You Get When You Cross a Computer with a Bank? ........8
Computers Make It Easy to Get into Trouble ..................................9
Commercial Software Suffers, Too ..................................................11
What Do You Get When You Cross a Computer
with a Warship? ................................................................................13
Techno-Rage......................................................................................13
An Industry in Denial ......................................................................14
The Origins of This Book..................................................................15
Chapter 2 Cognitive Friction ............................................................................19
Behavior Unconnected to Physical Forces ....................................19
Design Is a Big Word ........................................................................21
The Relationship Between Programmers and Designers..............22
Most Software Is Designed by Accident..........................................22
“Interaction” Versus “Interface” Design ..........................................23
Why Software-Based Products Are Different..................................24
The Dancing Bear ............................................................................26
The Cost of Features ........................................................................27
Apologists and Survivors..................................................................29
How We React to Cognitive Friction................................................33
The Democratization of Consumer Power ....................................34
Blaming the User ..............................................................................34
Software Apartheid ..........................................................................36
Part II It Costs You Big Time
Chapter 3 Wasting Money..................................................................................41
Deadline Management ....................................................................41
What Does “Done” Look Like? ........................................................42
Parkinson’s Law ............................................................................43
The Product That Never Ships ....................................................44
Shipping Late Doesn’t Hurt..............................................................45
Feature-List Bargaining....................................................................46
Programmers Are in Control ......................................................47
Features Are Not Necessarily Good ................................................47
Iteration and the Myth of the Unpredictable Market ....................48
The Hidden Costs of Bad Software..................................................52
The Only Thing More Expensive Than Writing Software
Is Writing Bad Software................................................................53
Opportunity Cost ........................................................................54
The Cost of Prototyping ..................................................................54
Chapter 4 The Dancing Bear ............................................................................59
If It Were a Problem, Wouldn’t It Have Been Solved
by Now?..............................................................................................59
Consumer Electronics Victim ..........................................................59
How Email Programs Fail ................................................................61
How Scheduling Programs Fail........................................................62
How Calendar Software Fails ..........................................................63
Mass Web Hysteria............................................................................64
What’s Wrong with Software? ..........................................................65
Software Forgets ..........................................................................65
Software Is Lazy............................................................................65
Software Is Parsimonious with Information..............................66
Software Is Inflexible....................................................................66
Software Blames Users ................................................................67
Software Won’t Take Responsibility ............................................67
Chapter 5 Customer Disloyalty ........................................................................71
Desirability ........................................................................................71
A Comparison ..................................................................................74
Time to Market..................................................................................77
Table of Contents / vii
Part III Eating Soup with a Fork
Chapter 6 The Inmates Are Running the Asylum ............................................81
Driving from the Backseat ..............................................................81
Hatching a Catastrophe ..................................................................83
Computers Versus Humans ............................................................87
Teaching Dogs to Be Cats ................................................................88
Chapter 7 Homo Logicus ..................................................................................93
The Jetway Test..................................................................................93
The Psychology of Computer Programmers ..................................95
Programmers Trade Simplicity for Control ....................................96
Programmers Exchange Success for Understanding ....................97
Programmers Focus on What Is Possible to the Exclusion
of What Is Probable ..........................................................................99
Programmers Act Like Jocks ..........................................................101
Chapter 8 An Obsolete Culture ......................................................................105
The Culture of Programming ........................................................105
Reusing Code ..................................................................................106
The Common Culture ....................................................................109
Programming Culture at Microsoft ..........................................110
Cultural Isolation ............................................................................115
Skin in the Game ............................................................................116
Scarcity Thinking ......................................................................119
The Process Is Dehumanizing, Not the Technology ....................120
Part IV Interaction Design Is Good Business
Chapter 9 Designing for Pleasure ..................................................................123
Personas ..........................................................................................123
Design for Just One Person ............................................................124
The Roll-Aboard Suitcase and Sticky Notes ............................126
The Elastic User ..............................................................................127
Be Specific ......................................................................................128
Hypothetical....................................................................................129
Precision, Not Accuracy ................................................................129
A Realistic Look at Skill Levels ......................................................131
Personas End Feature Debates ......................................................132
Both Designers and Programmers Need Personas ................134
It’s a User Persona, Not a Buyer Persona ......................................135
The Cast of Characters ..................................................................135
Primary Personas ............................................................................137
viii / Table of Contents
Case Study: Sony Trans Com’s P@ssport ......................................138
The Conventional Solution ......................................................139
Personas......................................................................................142
Designing for Clevis ..................................................................144
Chapter 10 Designing for Power ......................................................................149
Goals Are the Reason Why We Perform Tasks ..............................149
Tasks Are Not Goals ........................................................................150
Programmers Do Task-Directed Design ..................................151
Goal-Directed Design ....................................................................151
Goal-Directed Television News ................................................152
Goal-Directed Classroom Management ..................................153
Personal and Practical Goals ........................................................154
The Principle of Commensurate Effort ....................................155
Personal Goals ................................................................................156
Corporate Goals ..............................................................................156
Practical Goals ................................................................................157
False Goals ......................................................................................158
Computers Are Human, Too ..........................................................159
Designing for Politeness ................................................................160
What Is Polite? ............................................................................161
What Makes Software Polite? ........................................................162
Polite Software Is Interested in Me ..........................................162
Polite Software Is Deferential to Me ........................................163
Polite Software Is Forthcoming ................................................164
Polite Software Has Common Sense ........................................164
Polite Software Anticipates My Needs......................................165
Polite Software Is Responsive....................................................165
Polite Software Is Taciturn About Its Personal Problems ......165
Polite Software Is Well Informed ..............................................166
Polite Software Is Perceptive ....................................................166
Polite Software Is Self-Confident ..............................................167
Polite Software Stays Focused ..................................................167
Polite Software Is Fudgable ......................................................168
Polite Software Gives Instant Gratification..............................170
Polite Software Is Trustworthy ..................................................170
Case Study: Elemental Drumbeat ................................................171
The Investigation ......................................................................172
Who Serves Whom ....................................................................173
Table of Contents / ix
The Design..................................................................................174
Pushback ....................................................................................175
Other Issues ................................................................................176
Chapter 11 Designing for People ......................................................................179
Scenarios ........................................................................................179
Daily-Use Scenarios........................................................................180
Necessary-Use Scenarios ..............................................................180
Edge-Case Scenario ........................................................................181
Inflecting the Interface ..................................................................181
Perpetual Intermediates ................................................................182
“Pretend It’s Magic” ..................................................................185
Vocabulary ......................................................................................185
Breaking Through with Language ............................................186
Reality Bats Last ..............................................................................187
Case Study: Logitech ScanMan ....................................................188
Malcolm, the Web-Warrior........................................................189
Chad Marchetti, Boy ..................................................................189
Magnum, DPI ............................................................................190
Playing “Pretend It’s Magic” ......................................................191
World-Class Cropping ..............................................................193
World-Class Image Resize ........................................................194
World-Class Image Reorient ....................................................195
World-Class Results ..................................................................197
Bridging Hardware and Software ..................................................197
Less Is More ....................................................................................198
Part V Getting Back into the Driver’s Seat
Chapter 12 Desperately Seeking Usability ......................................................203
The Timing ......................................................................................203
User Testing ....................................................................................205
User Testing Before Programming............................................206
Fitting Usability Testing into the Process ................................206
Multidisciplinary Teams ................................................................207
Programmers Designing ................................................................207
How Do You Know? ........................................................................208
Style Guides ....................................................................................209
Conflict of Interest ....................................................................210
x / Table of Contents
Focus Groups ..................................................................................210
Visual Design ..................................................................................211
Industrial Design ............................................................................212
Cool New Technology ....................................................................213
Iteration ..........................................................................................213
Chapter 13 A Managed Process ........................................................................217
Who Really Has the Most Influence? ............................................217
The Customer-Driven Death Spiral..........................................218
Conceptual Integrity Is a Core Competence ..........................219
A Faustian Bargain ....................................................................220
Taking a Longer View ................................................................221
Taking Responsibility ................................................................221
Taking Time ................................................................................222
Taking Control ............................................................................222
Finding Bedrock..............................................................................222
Knowing Where to Cut ..............................................................222
Making Movies ................................................................................223
The Deal ..........................................................................................225
Document Design to Get It Built ..............................................226
Design Affects the Code ............................................................227
Design Documents Benefit Programmers ..............................228
Design Documents Benefit Marketing ....................................229
Design Documents Help Documenters and Tech Support....230
Design Documents Help Managers ........................................230
Design Documents Benefit the Whole Company ..................231
Who Owns Product Quality?..........................................................231
Creating a Design-Friendly Process ..............................................232
Where Interaction Designers Come From ..............................233
Building Design Teams ..............................................................234
Chapter 14 Power and Pleasure ........................................................................235
An Example of a Well-Run Project ................................................236
A Companywide Awareness of Design..........................................238
Benefits of Change..........................................................................239
Let Them Eat Cake..........................................................................240
Changing the Process ................................................................242
Index ..........................................................................................................245
Table of Contents / xi
Introduction
Run for your lives—the computers are invading. Awesomely powerful comput-ers tackling ever more important tasks with awkward, old-fashioned interfaces.As these machines leak into every corner of our lives, they will annoy us, infuri-ate us, and even kill a few of us. In turn, we will be tempted to kill our comput-ers, but we won’t dare because we are already utterly, irreversibly dependent onthese hopeful monsters that make modern life possible.
Fortunately, we have another option. We need to fundamentally rethink howhumans and machines interact. And rethink the relationship in deep and novelways, for the fault for our burgeoning problems lies not with our machines, butwith us. Humans designed the interfaces we hate; humans continue to use dys-functional machines even as the awkward interfaces strain their eyes, achetheir backs, and ruin their wrist tendons. We all are, as the title of this book sug-gests, the inmates running the techno-asylum of our own creation.
This book is a guide to our escape. Or rather, Alan Cooper reveals that the doorto the asylum lies wide open. We are free to leave any time we want, but mad aswe have all become, we never noticed until now. The secret lies in redefiningthe way we interact with our computers in a larger context.
Alan Cooper is not merely a fellow inmate; he is also a heretic whose ideas willlikely infuriate those who would want to keep us locked up. These are the engi-neers who built the systems we hate and who still believe the way out of thismess is to build better interfaces. But the very notion of interface is itself anartifact of an age when computers were scarce and puny, and barely able tointeract with their human masters. Interface made sense when the entire inter-action took place across the glass-thin no-man land of a computer screen. Nowit is an utterly dangerous notion in a world where computers are slipping intoevery corner of our lives. Computers no longer interface with humans—theyinteract, and the interaction will become steadily deeper, more subtle, andmore crucial to our collective sanity and ultimate survival.
Alan Cooper understands the shift from interface to interaction better thananyone I know. His ideas come from years of experience in helping designproducts that slip elegantly and unobtrusively into our lives. He has walked histalk for years, and now he has finally found the time to turn his practice into alucid description of the challenge we face, and a methodology for escaping theasylum we have so lovingly built. Read on and you will find your freedom.
Paul SaffoDirectorInstitute for the Future
Foreword to the Original Edition
The Business-Case Book
I intended to write a very different book from this one: a how-to book about theinteraction-design process. Instead, in May 1997 on a family visit to Tuscany,my friends Don McKinney and Dave Carlick talked me into this one. They con-vinced me that I needed to address a business audience first.
They knew I wanted to write a how-to design book, and—although they wereencouraging—they expressed their doubts about the need for interactiondesign, and they wanted me to write a book to convince them of its value. Theirargument was intriguing, but I was unsure that I could write the book theywanted.
Late one night on the veranda of our shared ochre villa overlooking Firenze, Iwas having an earnest conversation with Dave and Don. Several empty bottlesof Chianti stood on the table, along with the remains of some bread, cheese,and olives. The stars shone brightly, the fireflies danced over the lawn, and thelights on the ancient domes of the Tuscan capital twinkled in the distance.Once again, Dave suggested that I postpone the idea of a how-to book ondesign and instead “make the business case for interaction design.”
I protested vigorously, “But Dave, I don’t know how to write that book.” I tickedoff the reasons on my fingertips. “It means that I’d have to explain things likehow the current development process is messed up, how companies wastemoney on inefficient software construction, how unsatisfied customers arefickle, and how a better design process can solve that.”
Dave interrupted me to say simply, “They’re called chapters, Alan.”
His remark stopped me dead in my tracks. I realized that I was reciting an oldscript, and that Dave was right. A book that made “the business case” wasnecessary—and more timely—than a book that explained “how to.” And bothDave and Don convinced me that I really could write such a book.
Business-Savvy Technologist/Technology-SavvyBusinessperson
The successful professional for the twenty-first century is either a business-savvy technologist or a technology-savvy businessperson, and I am writing forthis person.
The technology-savvy businessperson knows that his success is dependent onthe quality of the information available to him and the sophistication withwhich he uses it. The business-savvy technologist, on the other hand, is anentrepreneurial engineer or scientist trained for technology, but possessing akeen business sense and an awareness of the power of information. Both ofthese new archetypes are coming to dominate contemporary business.
You can divide all businesspeople into two categories: those who will masterhigh technology and those who will soon be going out of business. No longercan an executive delegate information processing to specialists. Business isinformation processing. You differentiate yourself today with the quality of yourinformation-handling systems, not your manufacturing systems. If you manu-facture anything, chances are it has a microchip in it. If you offer a service, oddsare that you offer it with computerized tools. Attempting to identify businessesthat depend on high technology is as futile as trying to identify businesses thatdepend on the telephone. The high-tech revolution has invaded every business,and digital information is the beating heart of your workday.
It’s been said, “To err is human; to really screw up, you need a computer.”Inefficient mechanical systems can waste a couple of cents on every widget youbuild, but you can lose your entire company to bad information processes. Theleverage that software-based products—and the engineers that build them—have on your company is enormous.
Sadly, our digital tools are extremely hard to learn, use, and understand, andthey often cause us to fall short of our goals. This wastes money, time, and
opportunity. As a business-savvy technologist/technology-savvy businessper-son, you produce software-based products or consume them—probably both.Having better, easier-to-learn, easier-to-use high-tech products is in your per-sonal and professional best interest. Better products don’t take longer to create,nor do they cost more to build. The irony is that they don’t have to be difficult,but are so only because our process for making them is old-fashioned andneeds fixing. Only long-standing traditions rooted in misconceptions keep usfrom having better products today. This book will show you how you candemand—and get—the better products that you deserve.
The point of this book is uncomplicated: We can create powerful and pleasura-ble software-based products by the simple expedient of designing our computer-based products before we build them. Contrary to the popular belief, we are notalready doing so. Designing interactive, software-based products is a specialty asdemanding as constructing them.
x
Having made my choice to write the business-case book rather than the how-todesign book, I beg forgiveness from any interaction designers reading thisbook. In deference to the business audience, it has only the briefest treatmentof the actual nuts and bolts of interaction-design methodology (found primari-ly in Part IV, “Interaction Design Is Good Business”). I included only enough toshow that such methodology exists, that it is applicable to any subject matter,and that its benefits are readily apparent to anyone, regardless of their techni-cal expertise.
Alan CooperPalo Alto, Californiahttp://www.cooper.com
Foreword
I recently met with a senior executive at one of the world’s largest technologycompanies. His official title is Vice President for Ease of Use, and he is responsi-ble for a great number of software products, large and small. He is a brilliant andaccomplished fellow with roots in the formal Human-Computer Interactioncommunity. He is steeped in the ways of “usability”—of testing and observingbehind one-way mirrors—as is his company. But he came to talk about design,not testing, and about personas, not users. He said that his company has com-pletely ceased all postdevelopment usability testing and has instead committedto predevelopment design efforts. He further asserted that all of his stafferstrained in the art of in vitro user observation were being retrained to do in situethnographic research.
This executive and his company are emblematic of the sea of change that hasoccurred in the industry in the five short years since The Inmates was first pub-lished. The book has served as both a manifesto for a revolution and a handbookfor a discipline. Countless midlevel product managers have sent me emaildescribing why—after reading The Inmates—they purchased a copy of the bookfor each of their departments’ senior executives. Meanwhile, software buildersand universities alike have used the three chapters in Part IV, “Interaction DesignIs Good Business,” as a rudimentary how-to manual for implementing Goal-Directed® design using personas.
I am deeply grateful to all of the managers, programmers, executives, and usabil-ity practitioners who have used the ideas in this book to help bring usability outof the laboratory and into the field and changed its focus from testing to design.Because of their efforts, the entire landscape of the usability profession haschanged. Today, most of the organizations I have contact with have one or moreinteraction-design professionals on their payrolls, who have an ever-increasinginfluence over the quality and behavior of the software products and servicesbeing created. It’s gratifying to know that this book has contributed to their success.
I recall giving a keynote presentation at a programmer’s conference in 1999,shortly after this book was first published. That talk had the same title as thebook, and I opened by asserting that “inmates are running the asylum, and youare the inmates.” You could hear a pin drop as the more than 2,500 engineers inthe audience grappled with that accusation. In the silence that engulfed theauditorium, I went on to present the basic premise of this book, and an hourlater, that crowd of Homo logicus was so sufficiently convinced that they honoredme with a standing ovation. Surprisingly, most programmers have becomeenthusiastic supporters of design and designers. They know that they need helpon the human side of software construction, and they are very happy to be final-ly receiving some useful guidance. They recognize that any practice thatimproves the quality and acceptance of their programs doesn’t threaten them.
In the past, executives assumed that interaction design was a programmingproblem and delegated it to programmers, who diligently tried to solve the prob-lem even though their skills, training, mindset, and work schedule preventedthem from succeeding. In the spirit of problem diagnosis, this book takes painsto describe this failure, which is necessarily a story of the programmer’s failure.Some of them took offense at my descriptions, imagining that I was maligning orblaming programmers for bad software. They are certainly the agents by whichbad software is created, but they are by no means culpable. I do not blame pro-grammers for hard-to-use software, and I’m very sorry to have given any pro-grammer a contrary impression. With few exceptions, the programmers I knoware diligent and conscientious in their desire to please end users and are unceas-ing in their efforts to improve their programs’ quality. Just like users, program-mers are simply another victim of a flawed process that leaves them too littletime, too many conflicting orders, and utterly insufficient guidance. I am verysorry to have given any programmers the impression that I fault them.
The intractability of the software-construction process—particularly the highcost of programming and the low quality of interaction—is simply not a techni-cal problem. It is the result of business practices imposed on a discipline—software programming—for which they are obsolete. With pure hearts, the bestof intentions, and the blessing of upper management, programmers attempt tofix this problem by engineering even harder. But more or better engineering can-not solve these problems. Programmers sense the growing futility of their efforts,and their frustration mounts.
In my recent travels I have noticed a growing malaise in the community of pro-grammers. Sadly, it is the best and most experienced of them who are afflictedthe worst. They reflect cynicism and ennui about their efforts because they knowthat their skills are being wasted. They may not know exactly how they are mis-applied, but they cannot overlook the evidence. Many of the best programmers
xviii / The Inmates Are Running the Asylum
have actually stopped programming because they find the work frustrating. Theyhave retreated into training, evangelism, writing, and consulting because it does-n’t feel so wasteful and counterproductive. This is a tragic and entirely avoidableloss. (The open-source movement is arguably a haven for these frustrated programmers—a place where they can write code according to their own stan-dards and be judged solely by their peers, without the advice or intervention ofmarketers or managers.)
Programmers are not given sufficient time, clear enough direction, or adequatedesigns to enable them to succeed. These three things are the responsibility ofbusiness executives, and they fail to deliver them for preventable reasons, notbecause they are stupid or evil. They are simply not armed with adequate toolsfor solving the complex and unique problems that confront them in the infor-mation age. Now here I am sounding like I’m slamming people again, only thistime businesspeople are in my sights instead of programmers. Once again, tosolve the problem one must deconstruct it. I’m questing after solutions, notscapegoats.
Management sage Peter Drucker can see the problem from his unique view-point, having both observed and guided executives for the majority of his 92years. In a recent interview in CIO magazine, he commented on the wide-eyedoptimism of executives in the 1950s and 1960s as digital computers first nudgedtheir way into their businesses. Those executives imagined that computers“would have an enormous impact on how the business was run,” but Druckerexclaims, “This isn’t what happened. Very few senior executives have asked thequestion, ‘What information do I need to do my job?’” Although digital comput-ers have given executives unprecedented quantities of data, few have askedwhether this data is appropriate for guiding the corporation. Operations havechanged dramatically, but management has not followed suit. Drucker accusesour obsolete accounting systems, born in mercantilism, come of age in an era ofsteam and iron, and doddering into senility in the dawning twenty-first centuryinformation age. Drucker asserts, “The information you need the most is aboutthe outside world, and there is absolutely none.”
During the last few years of the twentieth century, as the dot-com bubble inflat-ed, truckloads of ink were used to sell the idea that there was a “new economy”on the Internet. The pundits said that selling things on the World Wide Web,where stores were made of clicks instead of bricks, was a fundamentally differentway of doing business, and that the “old economy” was as good as dead. Ofcourse, almost all of those new-economy companies are dead and gone, the ven-ture capitalists who backed them are in shock, and the pundits who pitched thenew economy have now recanted, claiming it was all a hopeless dream. The new,new thinking says we must still be in the old, old economy.
Foreword / xix
Actually, I believe that we really are in a new economy. What’s more, I think thatthe dot-coms never even participated in it. Instead, the dot-coms were the lastgasp of the old economy: the economy of manufacturing.
In the industrial age, before software, products were manufactured from solidmaterial—from atoms. The money it took to mine, smelt, purchase, transport,heat, form, weld, paint, and transport dominated all other expenditures.Accountants call these “variable costs” because that expense varies directly witheach product built. “Fixed costs,” as you might expect, don’t vary directly andinclude things such as corporate administration and the initial cost of the factory.
The classic rules of business management are rooted in the manufacturing tra-ditions of the industrial age. Unfortunately, they have yet to address the new real-ities of the information age, in which products are no longer made from atomsbut are mostly software, made only from the arrangements of bits. And bits don’tfollow the same economic rules that atoms do.
Some fundamental truths hold for both the old and the new economies. The goalof all business is to make a sustainable profit, and there is only one legal way todo so: Sell some goods or services for more money than it costs you to make oracquire them. It follows that there are two ways to increase your profitability:Either reduce your costs or increase your revenues. In the old economy, reducingyour costs worked best. In the new economy, increasing your revenue worksmuch, much better.
Today’s most vital and expensive products are made largely or completely of soft-ware. They consume no raw materials. They have no manufacturing cost. Theyhave no transportation cost. There is no welding, hammering, or painting. Thisis the real difference between the industrial-age economy and the information-age economy: In the information age, there is little or no variable cost, whereasin the late industrial age, variable cost was the dominant factor. Indeed, theabsence of variable cost is what makes this a new economy.
Is the salary you pay the programmers on your staff a fixed cost or a variable cost?One hour of programming is definitely not directly related to one product sale;you can sell that same code over and over again. An investment in programmingcan be leveraged across millions of salable items, just as an investment in a fac-tory is leveraged across all the products built within it.
Writing software is not a variable cost, but it’s not really a fixed cost either.Writing software is an ongoing, revenue-generating operation of the company,and it is not the same as constructing a factory. The expensive craftsmen whobuild the factory leave and go to work on some other job after the building iserected. Programmers are far more expensive than carpenters or ironworkers,and they never go away because their work is apparently never completed. Some
xx / The Inmates Are Running the Asylum
might suggest that programming is research and development, and there aresimilarities. However, R & D is the thinking and experimenting done to establishthe theoretical viability of a product and is not performed the same way thatproducts are built in a production environment. Fittingly, traditional accountingseparates R & D expenditures from the daily operations that generate revenue.Writing software doesn’t work well in any of those old business-accounting cate-gories.
Now, you might discount this little terminology mismatch as a minor quibble forbean-counters with green eyeshades to debate over beers, but it actually has ahuge effect on how software is funded, managed, and—most significantly—regarded by senior executives.
Programmers create software, and business executives create revenue streamsand profit centers. Programmers measure their success by the quality of theproduct, and business executives measure their success by the profitability oftheir investments. They measure this profitability by applying the language ofbusiness mathematics, which recognizes fixed costs, variable costs, corporateoverhead, and research and development, but, unfortunately, it has no modelappropriate for software or programming. Accounting is the basic language ofbusiness, and these categories are so fundamental to all business measurementand communication that contemporary executives have completely internalizedthem. They see programming as simply another corporate expense to be fittedinto an already existing category. In practice, most executives simply treat pro-gramming as a manufacturing effort—a variable cost. (For tax purposes, mostsoftware companies account for programming as R & D, but it is regarded as avariable cost in every other respect.) This is the worst possible choice because ithopelessly prejudices their business decision making.
The key advantage of the industrial age was that products could be mass-pro-duced, which means they could be made available to the masses at affordableprices. The advantage to customers was the availability of functions that werepreviously unavailable or only expensively hand built for the wealthy.Companies competed on the basis of their sales prices, which were directly relat-ed to their variable costs: the cost of manufacturing and shipping. In the infor-mation age, it is taken for granted that products are available at affordable pricesto everyone. After all, software can be downloaded and distributed to any num-ber of customers for essentially no cost and with little or no human effort.
Remember, businesses can grow profits by increasing revenue or reducing costs.That is, a business can increase its fixed-cost investment, improving its product’squality, which increases its pricing strength, or it can reduce its variable cost,which means decreasing the cost of manufacturing. In the old manufacturingeconomy of atoms, reducing costs was simple and effective, and it was the
Foreword / xxi
preferred tactic. When today’s executives regard programming the same as man-ufacturing, they imagine that reducing the cost of programming is similarly sim-ple and effective. Unfortunately, those rules don’t apply anymore.
Because software has relatively insignificant variable costs, there is little businessadvantage to be had in reducing them. Programmers’ salaries appear to be a vari-able cost from an accountant’s point of view, but they are much more like a long-term investment—a fixed cost. Reducing the cost of programming is not thesame as reducing the cost of manufacturing. It’s more like giving cheap tools toyour workers than it is like giving the workers smaller paychecks. The companiesthat are shipping programming jobs overseas in order to pay reduced salaries aremissing the point entirely.
What’s more, the only available economic upside comes from making your prod-uct or service more desirable by improving its quality, and you can’t do that byreducing the money you spend designing or programming it. In fact, you need toinvest more time and money on the research, thinking, planning, and designingphase to make your results better suited to your customers’ needs.
Of course, this requires a mode of thinking that is quite unfamiliar to twenty-firstcentury businesspeople. Instead of reducing what they spend to build each object,they need to increase what they spend to build all objects. This is the essence ofthe real new economy and precisely what Peter Drucker was talking about.
Modern pharmaceutical companies inventing high-tech drugs share some simi-larities to the new software economy. The actual manufacturing cost of a singlepill is miniscule, but the development costs can run to billions of dollars over adecade or more. The upside of shipping a new miracle drug can be boundless,but there is only a catastrophic downside in shipping that drug before it has beendeveloped completely. Pharmaceuticals know that reducing development costsis not a viable business strategy.
Like inventing medicine, building software isn’t the same as building a factory. Thefactory is a physical asset that a company owns, and the factory workers are large-ly interchangeable. The intangible but extremely complicated patterns of thoughtthat is software has value only when accompanied by the programmers who wroteit. No company can treat programmers the same as a factory. Programmersdemand continuous attention and support well above that of any factory.
Architecture—the human design part of programming, in which users are studied,use scenarios are defined, interaction is designed, form is determined, and behav-ior is described—is the part of the software-construction process that is most fre-quently dispensed with as a cost-saving measure. It is certainly possible to do toomuch design, but there is no advantage in reducing it. Every dollar or hour spenton architecture will yield tenfold savings during programming. Additionally, when
xxii / The Inmates Are Running the Asylum
you invest a sufficient amount of competent design, your product becomes verydesirable, which means that it will make more money for you. Its desirability willestablish your brand, increase your ability to raise prices, generate customer loyal-ty, and give your product a longer, stronger lifespan. Although there’s no advantagein cost reduction, there is big advantage in quality enhancement. Ironically, thebest way to increase profitability in the information age is to spend more.
Unfortunately, most executives have an almost irresistible desire to reduce thetime and money invested in programming. They see, incorrectly, the obsoleteadvantage in reducing costs. What they don’t see is that reduction in investmentin programming has strong negative effects on a product’s long-term quality,desirability, and therefore profitability. Of course, simply spending more moneydoesn’t guarantee improvement, and it can often make things worse when addi-tional money is unaccompanied by wisdom, analysis, and guidance. My firstmentor, Dan Joaquin, used to say that the old maxim “You get what you pay for”should properly be inverted to “You don’t get what you don’t pay for.” Proceedingwithout proper planning risks spending way too much. The trick is to spend the correct amount, and that demands significant expertise in software-construction management. It also demands process tools that provide managerswith the insight and information they need to make the correct decisions.Providing those tools is this book’s goal.
The dot-com boom was populated with companies whose entire business modelconsisted of the reduction of variable costs. Although many dot-coms claimedvarious online advantages, their Web sites were sufficiently ponderous andunhelpful to be far less satisfying than simply driving to the mall. Dot-comfounders swooned with ecstasy (as did the press) because they could establish aretail enterprise for a remarkably lower variable cost. Their complete and spec-tacular failure demonstrated beyond doubt that the economic rules of the infor-mation age are different from those of the industrial age.
In the old economy, lower variable costs meant wider distribution and lowerretail costs. Those twin advantages directly benefited the consumer, and they arethe foundation for the economic success of the industrial revolution. In the neweconomy, business success depends on adding something new and better for theconsumer. The actual quality of every part of the transaction, from browsing tocomparison shopping to comprehensiveness, must be noticeably better for theend user. Wading through 11 screens only to have to telephone the companyanyway is far less satisfying than making the purchase conventionally. Enteringyour name, address, and credit card information three or four times, only to findthat the site can’t sell you everything you need and a trip to the atom-based storeis necessary anyway, has the unfortunate effect of making the entire online salecompletely unnecessary and undesirable. Today, simply lowering costs for thevendor doesn’t guarantee success.
Foreword / xxiii
When Pets.com sold dog food over the Internet, it didn’t offer better dog food,and it didn’t offer a customer experience better than you could get at the localbrick-and-mortar pet store; it didn’t offer any better information, intelligence, orconfidence. All it offered was cheaper shipping, stocking, and selling—variablecosts all—for Pets.com. It was a classic industrial-age-economy tactic of costreduction that ignored the fundamental principles of the new economy. Far frombeing the first breath of a new economy, it was the last gasp of the old.
I am absolutely convinced that you can sell anything on the Internet profitablyand successfully. The trick is that your online store must offer a measurablygreater degree of shopper satisfaction than any competing retail medium, andprice is only one small component of satisfaction. There is only one way toaccomplish this: You must architect your system to deliver the highest possibleend-user satisfaction. Treating any aspect of software design and construction asif it were a manufacturing process courts failure. The design and programmingof software is simply not a viable target for conventional cost-reduction meth-ods. It’s certainly possible to spend too much time and money on building soft-ware, but the danger of spending too little is far greater.
Such danger is probably not shocking or unfamiliar to you, but it is nearly incon-ceivable to most senior business executives who are responsible for running bigcompanies. Those execs are still using accounting models popular in the age ofsteam, yet every aspect of their companies is fully dependent on software foroperations, decision making, communications, and finance. The terms and con-cepts those executives use are simply not cognizant of the unique nature ofdoing business in an era when the tools and products of commerce are intangi-ble arrangements of bits instead of railroad carloads of iron. The sock puppetswere cool, though.
Even though corporations are hiring interaction designers and applying goal-directed methods, the quality of our software products hasn’t actually improvedthat much. What’s more, the high cost of programming and the basic intractabil-ity of the software-construction process remain ever-present. Why?
Change is impossible until senior business executives realize that software prob-lems are not technical issues, but are significant business issues. Our problems willremain unsolved until we change our process and our organization.
Not only do companies follow obsolete financial models, but they also follow aninappropriate organizational model. This model is copied directly from acade-mia, where the act of creating software is entangled with the planning and engineering of that software. Such is the nature of research. Tragically, andapparently without notice, this paradigm has been carried over intact into theworld of business, where it does not belong.
xxiv / The Inmates Are Running the Asylum
All modern manufacturing disciplines have roots in preindustry except software,whose unique medium appeared well after industrialization was a fait accompli.Only programming comes directly from academia, where there are no time lim-its on research, student power is dirt cheap, profit is against the rules, and a fail-ing program can be considered a very successful experiment. It’s not acoincidence that Microsoft, IBM, Oracle, and other leading software companiesreside in “campuses.” Universities never have to make money, hit deadlines, orbuild desirable, useful products.
All nonsoftware businesses begin with research and end with mass productionand distribution of their products or services. They plan carefully in between,cognizant of the dangers to both bank account and reputation if they attemptpremature production of an ill-conceived product. They know that time,thought, and money invested in planning will pay big dividends in the smooth-ness and speed of manufacturing and the popularity and profitability of theirend products.
In all other construction disciplines, engineers plan a construction strategy thatcraftsmen execute. Engineers don’t build bridges; ironworkers do. Only in softwareis the engineer tasked with actually building the product. Only in software is the“ironworker” tasked with determining how the product will be constructed. Onlyin software are these two tasks performed concurrently instead of sequentially. Butcompanies that build software seem totally unaware of the anomaly. Engineeringand construction are so crossbred as to be inseparable and apparently indistin-guishable by practitioners or executives. Planning of all sorts is either omitted ordelayed until far too late. Profoundly complex technical engineering problems arehabitually left unsolved until construction of code intended for public release iswell underway, when it is too economically embarrassing to back up.
Architecture must be integrated into early-stage engineering planning. In fact, itshould drive early-stage engineering, but because such engineering is typicallydeferred until construction has begun and is corrupted by intermingling withproduction coding, the architectural design lacks an entry point into the con-struction process. Despite the fact that companies are hiring interaction design-ers and retraining their usability testers to create personas, their work has littleeffect on either the cost of construction or the quality of the finished product.
The solution lies in the hands of corporate presidents and chief executive offi-cers. When these execs delegate the solution to their chief technology officers orvice presidents of engineering they miss the point. Those worthy officers aretechnicians, and the problem is not a technical one. As Drucker pointed out, theaccounting tools CEOs depend on simply do not represent the true state of theirorganizations. It’s like saying that because the speedometer is accurate the car isheaded in the right direction. In a business world dominated by digital technol-ogy, that is simply no longer true.
Foreword / xxv
One of the biggest problems of applying incorrect accounting and organization-al methods to software construction is that executives don’t realize how much oftheir programming dollar is wasted. An accurate system would show that at leastone half of every dollar is misspent and that it takes another two or three dollarsto fix the problems caused by the initial bad investment. In any other business,such statistics would be cause for revolution, but in software we remain in a stateof blissful ignorance.
Over the past 13 years my company, Cooper, has consulted with hundreds ofcompanies. My talented designers have provided most of them with blueprintsfor products that would help them enormously, yet only a handful have beenable to take full advantage of them. Most of them treat interaction design andsoftware architecture as advice, and their programmers and engineers alwayshave the last word. None of those companies’ CEOs has any clue as to what isreally going on in the engineers’ cubicles, so they squeeze the schedule withoutreason. The programmers are always working in an environment of scarcity, pri-marily lacking time to program well, but also lacking the time to determine whatshould be programmed at all. They are forced to protect themselves by rejectingadvice and prevaricating to their managers.
I believe that there are two kinds of executives: those who are engineers, and thosewho are terrified of engineers. The former propagate the familiar problemsbecause their viewpoint is hopelessly blinkered by a conflict of interest. The latterpropagate them because they cannot speak the language of programmers. I don’tmean Java or C#. I mean that business people and programmers lack commontools and common goals. Homo sapiens delegate human problems to Homo logi-cus and are unaware that the solution could be so much better if they applied—atthe executive level—appropriate financial and organizational models instead.
There is a colossal opportunity for companies to break this logjam and organizearound customer satisfaction instead of around software, around personas insteadof around technology, around profit instead of around programmers. I eagerlyawait the enlightened executive who seizes this chance and forever alters the waysoftware is built by providing the industry with a bold and successful example.
xxvi / The Inmates Are Running the Asylum
Alan CooperMenlo Park, CaliforniaOctober 2003http://www.cooper.com
3Wasting Money
It’s harder than you might think to squander millions of dollars, but a flawed software-development process is a tool well suited to the job. That’s because soft-ware development lacks one key element: an understanding of what it means tobe “done.” Lacking this vital knowledge, we blindly bet on an arbitrary deadline.We waste millions to cross the finish line soonest, only to discover that the finishline was a mirage. In this chapter I’ll try to untangle the expensive confusion ofdeadline management.
Deadline Management
There is a lot of obsessive behavior in Silicon Valley about time to market. It is fre-quently asserted that shipping a product right now is far better than shipping itlater. This imperative is used as a justification for setting impossibly ambitiousship dates and for burning out employees, but this is a smoke screen that hidesbigger, deeper fears—a red herring. Shipping a product that angers and frus-trates users in three months is not better than shipping a product that pleasesusers in six months, as any businessperson knows full well.
Managers are haunted by two closely related fears. They worry about when theirprogrammers will be done building, and they doubt whether the product will begood enough to ultimately succeed in the marketplace. Both of these fears stemfrom the typical manager’s lack of a clear vision of what the finished productactually will consist of, aside from mother-and-apple-pie statements such as“runs on the target computer” and “doesn’t crash.” And lacking this vision, theycannot assess a product’s progress towards completion.
The implication of these two fears is that as long as it “doesn’t crash,” there isn’tmuch difference between a program that takes three months to code and onethat takes six months to code, except for the prodigious cost of three months ofunnecessary programming. After the programmers have begun work, moneydrains swiftly. Therefore, logic tells the development manager that the mostimportant thing to do is to get the coding started as soon as possible and to endit as soon as possible.
The conscientious development manager quickly hires programmers and setsthem coding immediately. She boldly establishes a completion date just a fewmonths off, and the team careens madly toward the finish line. But without prod-uct design, our manager’s two fears remain unquelled. She has not establishedwhether the users will like the product, which indeed leaves its success a mys-tery. Nor has she established what a “complete” product looks like, which leavesits completion a mystery. Later in the book, I’ll show how interaction design canease these problems. Right now, I’ll show how thoroughly the deadline subvertsthe development process, turning all the manager’s insecurities into self-fulfilling prophecies.
What Does “Done” Look Like?
After we have a specific description of what the finished software will be, we cancompare our creation with it and really know when the product is done.
There are two types of descriptions. We can create a very complete and detailedphysical description of the actual product, or we can describe the reaction we’dlike the end user to have. In building architecture, for example, blueprints fill thefirst requirement. When planning a movie or creating a new restaurant, however,we focus our description on the feelings we’d like our clients to experience. Forsoftware-based products, we must necessarily use a blend of the two.
Unfortunately, most software products never have a description. Instead, all theyhave is a shopping list of features. A shopping bag filled with flour, sugar, milk,and eggs is not the same thing as a cake. It’s only a cake when all the steps of therecipe have been followed, and the result looks, smells, and tastes substantiallylike the known characteristics of a cake.
Having the proper ingredients but lacking any knowledge of cakes or how tobake, the ersatz cook will putter endlessly in the kitchen with only indeterminateresults. If we demand that the cake be ready by 6 o’clock, the conscientious cookwill certainly bring us a platter at the appointed hour. But will the concoction bea cake? All we know is that it is on time, but its success will be a mystery.
42 / Part II: It Costs You Big Time
In most conventional construction jobs, we know we’re done because we have aclear understanding of what a “done” job looks like. We know that the building iscompleted because it looks and works just like the blueprints say it should lookand work. If the deadline for construction is June 1, the arrival of June doesn’tnecessarily mean that the building is done. The relative completeness of thebuilding can only be measured by examining the actual building in comparisonto the plans.
Without blueprints, software builders don’t really have a firm grasp on whatmakes the product “done,” so they pick a likely date for completion, and whenthat day arrives they declare it done. It is June 1; therefore, the product is com-pleted. “Ship it!” they say, and the deadline becomes the sole definition of proj-ect completion.
The programmers and businesspeople are neither stupid nor foolish, so the prod-uct won’t be in complete denial of reality. It will have a robust set of features, it willrun well, and it won’t crash. The product will work reasonably well when operatedby people who care deeply that it works well. It might even have been subjected tousability testing, in which strangers are asked to operate it under the scrutiny ofusability professionals1. But, although these precautions are only reasonable, theyare insufficient to answer the fundamental question: Will it succeed?
Parkinson’s Law
Managers know that software development follows Parkinson’s Law: Work willexpand to fill the time allotted to it. If you are in the software business, perhapsyou are familiar with a corollary to Parkinson called the Ninety-Ninety Rule,attributed to Tom Cargill of Bell Labs: “The first 90% of the code accounts for thefirst 90% of the development time. The remaining 10% of the code accounts forthe other 90% of the development time.” This self-deprecating rule says that when
Chapter 3: Wasting Money / 43
1 Usability professionals are not interaction designers. I discuss this difference in detail inChapter 12, “Desperately Seeking Usability.”
the engineers have written 90% of the code, they still don’t know where they are!Management knows full well that the programmers won’t hit their stated shipdates, regardless of what dates it specifies. The developers work best under pres-sure, and management uses the delivery date as the pressure-delivery vehicle.
In the 1980s and 1990s, Royal Farros was the vice president of development forT/Maker, a small but influential software company. He says, “A lot of us set dead-lines that we knew were impossible, enough so to qualify for one of thoseParkinson’s Law corollaries. ‘The time it will take to finish a programming projectis twice as long as the time you’ve allotted for it.’ I had a strong belief that if youset a deadline for, say, six months, it would take a year. So, if you had to havesomething in two years, set the deadline for one year. Bonehead sandbagging,but it always worked.”
When software entrepreneur Ridgely Evers was with Intuit, working on the cre-ation of QuickBooks, he experienced the same problem. “The first release ofQuickBooks was supposed to be a nine-month project. We were correct in esti-mating that the development period would be the same as a gestation period,but we picked the wrong species: It took almost two-and-a-half years, the gesta-tion period for the elephant.”
Software architect Scott McGregor points out that Gresham’s Law—that bad cur-rency drives out good—is also relevant here. If there are two currencies, peoplewill hoard the good one and try to spend the bad one. Eventually, only the badcurrency circulates. Similarly, bad schedule estimates drive out good ones. Ifeverybody makes bogus but rosy predictions, the one manager giving realisticbut longer estimates will appear to be a heel-dragger and will be pressured torevise his estimates downward.
Some development projects have deadlines that are unreasonable by virtue oftheir arbitrariness. Most rational managers still choose deadlines that, whilereachable, are only reachable by virtue of extreme sacrifice. Sort of like the pilotsaying, “We’re gonna make Chicago on time, but only if we jettison all our bag-gage!” I’ve seen product managers sacrifice not only design, but testing, func-tion, features, integration, documentation, and reality. Most product managersthat I have worked with would rather ship a failure on time than risk going late.
The Product That Never Ships
This preference is often due to every software development manager’s deepestfear: that after having become late, the product will never ship at all. Stories ofproducts never shipping are not apocryphal. The project goes late, first by oneyear, then two years, then is euthanized in its third year by a vengeful upper man-agement or board of directors. This explains the rabid adherence to deadlines,even at the expense of a viable product.
44 / Part II: It Costs You Big Time
For example, in the late 1990s, at the much-publicized start-up company Worlds,Inc., many intelligent, capable people worked on the creation of a virtual, onlineworld where people’s avatars could wander about and engage other avatars inreal-time conversation. The product was never fully defined or described, andafter tens of millions of investment capital was spent, the directors mercifullypulled the plug.
In the early 1990s, another start-up company, Nomadic Computing, spent about$15 million creating a new product for mobile businesspeople. Unfortunately, noone at the company was quite sure what its product was. They knew their mar-ket, and most of the program’s functions, but weren’t clear on their users’ goals.Like mad sculptors chipping away at a huge block of marble hoping to discovera statue inside, the developers wrote immense quantities of useless code thatwas all eventually thrown away, along with money, time, reputations, andcareers. The saddest waste, though, was the lost opportunity for creating soft-ware that really was wanted.
Even Microsoft isn’t immune from such wild goose chases. Its first attempt at cre-ating a database product in the late 1980s consumed many person-years of effortbefore Bill Gates mercifully shut it down. Its premature death sent a shock wavethrough the development community. Its successor, Access, was a completelynew effort, staffed and managed by all new people.
Shipping Late Doesn’t Hurt
Ironically, shipping late generally isn’t fatal to a product. A third-rate product thatships late often fails, but if your product delivers value to its users, arrivingbehind schedule won’t necessarily have lasting bad effects. If a product is a hit,it’s not a big deal that it ships a month—or even a year—late. Microsoft Accessshipped several years late, yet it has enjoyed formidable success in the market.Conversely, if a product stinks, who cares that it shipped on time?
Certainly, some consumer products that depend on the Christmas season for thebulk of their sales have frighteningly important due dates. But most software-basedproducts, even consumer products, aren’t that sensitive to any particular date.
For example, in 1990 the PenPoint computer from GO was supposed to be theprogenitor of a handheld-computer revolution. In 1992, when the PenPointcrashed and burned, the Apple Newton inherited the promise of the handheldrevolution. When the Newton failed to excite people, General Magic’s Magic Linkcomputer became the new hope for handhelds. That was in 1994. When theMagic Link failed to sell, the handheld market appeared dead. Venture capitalistsdeclared it a dry hole. Then, out of nowhere, in 1996, the PalmPilot arrived to uni-versal acclaim. It seized the handheld no-man’s-land six years late. Markets arealways ready for good products that deliver value and satisfy users.
Chapter 3: Wasting Money / 45
Of course, companies with a long history of making hardware-only products nowmake hybrid versions containing chips and software. They tend to underesti-mate the influence of software and subordinate it to the already-establishedcompletion cycles of hardware. This is wrong because as Chapter 1, “Riddles forthe Information Age,” showed, these companies are now in the software busi-ness, whether or not they know it.
Feature-List Bargaining
One consequence of deadline management is a phenomenon that I call “feature-list bargaining.”
Years ago programmers got burned by the vague product-definition process con-sisting of cocktail-napkin sketches, because they were blamed for the unsuccess-ful software that so often resulted. In self-defense, programmers demanded thatmanagers and marketers be more precise. Computer programs are procedural,and procedures map closely to features, so it was only natural that programmerswould define “precision” as a list of features. These feature lists allowed program-mers to shift the blame to management when the product failed to live up toexpectations. They could say, “It wasn’t my fault. I put in all the features manage-ment wanted.”
Thus, most products begin life with a document variably called a “marketingspecification,” “technical specification,” or “marketing requirements document.”It is really just a list of desired features, like the list of ingredients in the recipe forcake. It is usually the result of several long brainstorming sessions in which man-agers, marketers, and developers imagine what features would be cool and jotthem down. Spreadsheet programs are a favorite tool for creating these lists, anda typical one can be dozens of pages long. (Invariably, at least one of the lineitems will specify a “good user interface.”) Feature suggestions can also comefrom focus groups, market research, and competitive analysis.
The managers then hand the feature list to the programmers and say, “The prod-uct must ship by June 1.” The programmers—of course—agree, but they havesome stipulations. There are far too many features to create in the time allotted,they claim, and many of them will have to be cut to meet the deadline. Thusbegins the time-honored bargaining.
The programmers draw a dividing line midway through the list. Items above itwill be implemented, they declare, while those below the “line of death” arepostponed or eliminated. Management then has two choices: to allow more timeor to cut features. Although the project will inevitably take more time, manage-ment is loath to play that trump so early in the round, so it negotiates over fea-tures. Considerable arguing and histrionics occur. Features are traded for time;time is traded for features. This primitive capitalist negotiation is so human and
46 / Part II: It Costs You Big Time
natural that both parties are instantly comfortable with it. Sophisticated parallelstrategies develop. As T/Maker’s Royal Farros points out, when one “critical-pathfeature was blamed for delaying a deadline, it would let a dozen other tardy fea-tures sneak onto the list without repercussion.” Lost in the battle is the perspec-tive needed for success.
Farros described T/Maker’s flagship product, a word processor named WriteNow,as “a perfect product for the university marketplace. In 1987, we actually shippedmore copies of WriteNow to the university market than Microsoft shipped Word.However, we couldn’t hold our lead because we angered our very loyal, core fansin this market by not delivering the one word-processor feature needed in a uni-versity setting: endnotes. Because of trying to make the deadline, we could neverslip this feature into the specification. We met our deadline but lost an entiremarket segment.”
Programmers Are in Control
Despite appearances, programmers are completely in control of this bottom-updecision-making process. They are the ones who establish how long it will taketo implement each item, so they can force things to the bottom of the list mere-ly by estimating them long. The programmers will—in self-defense—assignlonger duration to the more nebulously defined items, typically those concernedwith substantive user-interface issues. This inevitably causes them to migrate tothe bottom of the list. More familiar idioms and easy-to-code items, such asmenus, wizards, and dialog boxes, bubble to the top of the list. All of the analysisand careful thinking done by high-powered and high-priced executives is mademoot by the unilateral cherry picking of a programmer following his own museor defending his turf.
Like someone only able to set the volume of a speaker that isn’t within hearingdistance, managers find themselves in the unenviable position of only havingtools that control ineffective parameters of the development process. It is cer-tainly true that management needs to control the process of creating and ship-ping successful software, but, unfortunately, our cult of deadline ignores the“successful” part to concentrate only on the “creating” part. We give the creatorsof the product the reins to the process, thus relegating management to the roleof passenger and observer.
Features Are Not Necessarily Good
Appearances to the contrary, users aren’t really compelled by features. Productsuccesses and failures have shown repeatedly that users don’t care that muchabout features. Users only care about achieving their goals. Sometimes featuresare needed to reach goals, but more often than not, they merely confuse users
Chapter 3: Wasting Money / 47
and get in the way of allowing them to get their work done. Ineffective featuresmake users feel stupid. Borrowing from a previous example, the successfulPalmPilot has far fewer features than did General Magic’s failed Magic Link com-puter, Apple’s failed Newton, or the failed PenPoint computer. The PalmPilotowes its success to its designers’ single-minded focus on its target user and theobjectives that user wanted to achieve.
About the only good thing I can say about features is that they are quantifiable.And that quality of being countable imbues them with an aura of value that theysimply don’t have. Features have negative qualities every bit as strong as theirpositive ones. The biggest design problem they cause is that every well-meantfeature that might possibly be useful obfuscates the few features that will proba-bly be useful. Of course, features cost money to implement. They add complexi-ty to the product. They require an increase in the size and complexity of thedocumentation and online help system. Above all, cost-wise, they require addi-tional trained telephone tech-support personnel to answer users’ questionsabout them.
It might be counterintuitive in our feature-conscious world, but you simply can-not achieve your goals by using feature lists as a problem-solving tool. It’s quitepossible to satisfy every feature item on the list and still hatch a catastrophe.Interaction designer Scott McGregor uses a delightful test in his classes to provethis point. He describes a product with a list of its features, asking his class towrite down what the product is as soon as they can guess. He begins with 1)internal combustion engine; 2) four wheels with rubber tires; 3) a transmissionconnecting the engine to the drive wheels; 4) engine and transmission mountedon metal chassis; 5) a steering wheel. By this time, every student will have writ-ten down his or her positive identification of the product as an automobile,whereupon Scott ceases using features to describe the product and instead men-tions a couple of user goals: 6) cuts grass quickly and easily; 7) comfortable to siton. From the five feature clues, not one student will have written down “ridinglawnmower.” You can see how much more descriptive goals are than features.
Iteration and the Myth of the Unpredictable Market
In an industry that is so filled with money and opportunities to earn it, it is oftenjust easier to move right along to another venture and chalk up a previous failureto happenstance, rather than to any real reason.
I was a party to one of these failures in the early 1990s. I helped to start a venture-funded company whose stated goal was to make it absurdly simple to networkPCs together.2 The product worked well and was easy to use, but a tragic series of
48 / Part II: It Costs You Big Time
2 Actually, we said that we wanted to make it “as easy to network Intel/Windows computers as itwas to network Macintosh computers.” At the time, it was ridiculously simple to network Macstogether with AppleTalk. Then, as now, it was quite difficult to network Wintel PCs together.
self-inflicted marketing blunders caused it to fail dismally. I recently attended aconference where I ran into one of the investors who sat on the doomed compa-ny’s board of directors. We hadn’t talked since the failure of the company, and—like veterans of a battlefield defeat meeting years later—we consoled each otheras sadder but wiser men. To my unbridled surprise, however, this otherwiseextremely successful and intelligent man claimed that in hindsight he hadlearned a fundamental lesson: Although the marketing, management, and tech-nical efforts had been flawless, the buying public “just wasn’t interested in easy-to-install local area networks.” I was flabbergasted that he would make such anobviously ridiculous claim and countered that surely it wasn’t lack of desire, butrather our failure to satisfy the desire properly. He restated his position, arguingforcefully that we had demonstrated that easy networking just wasn’t somethingthat people wanted.
Later that evening, as I related this story to my wife, I realized that his rationali-zation of the failure was certainly convenient for all the parties involved in theeffort. By blaming the failure on the random fickleness of the market, my col-league had exonerated the investors, the managers, the marketers, and thedevelopers of any blame. And, in fact, each of the members of that start-up hasgone on to other successful endeavors in Silicon Valley. The venture capitalist hasa robust portfolio of other successful companies.
During development, the company had all the features itemized on the featurelist. It stayed within budget. It shipped on schedule. (Well, actually, we keptextending the schedule, but it shipped on a schedule.) All the quantitativelymeasurable aspects of the product-development effort were within acceptableparameters. The only conclusion this management-savvy investor could makewas the existence of an unexpected discontinuity in the marketplace. How couldwe have failed when all the meters were in the green?
The fact that these measures are objective is reassuring to everyone. Objectiveand quantitative measure is highly respected by both programmers and busi-nesspeople. The fact that these measures are usually ineffective in producingsuccessful products tends to get lost in the shuffle. If the product succeeds, itsprogenitors will take the credit, attributing the victory to their savvy understand-ing of technology and marketing.
On the other hand, if the product fails, nobody will have the slightest motivationto exhume the carcass and analyze the failure. Almost any excuse will do, as longas the players—both management and technical—can move along to the nexthigh-tech opportunity, of which there is an embarrassment of riches. Thus, thereis no reason to weep over the occasional failure. The unfortunate side effect of notunderstanding failure is the silent admission that success is not predictable—thatluck and happenstance rule the high-tech world. In turn, this gives rise to what
Chapter 3: Wasting Money / 49
the venture capitalists call the “spray and pray” method of funding: Put a little bitof money into a lot of investments and then hope that one of them gets lucky.
x
Rapid-development environments such as the World Wide Web—and VisualBasic before it—have also promoted this idea of simply iterating until somethingworks. Because the Web is a new advertising medium, it has attracted a multi-tude of marketing experts who are particularly receptive to the myth of theunpredictable market and its imperative to iterate. Marketers are familiar withthe harsh and arbitrary world of advertising and media. After all, much of adver-tising really is random guesswork. For example, in advertising, “new” is the sin-gle most effective marketing concept, yet when Coca-Cola introduced “NewCoke” in the mid-1980s, it failed utterly. Nobody could have predicted this result.People’s tastes and styles change randomly, and the effectiveness of marketingcan appear to be random.
On the Web, the problem arises when a Web site matures from the online-catalog stage into the online-store stage. It changes from a one-way presentationof data to an interactive software application. The advertising and media peoplewho had such great success with the first-generation site now try their same iter-ation methods on the interactive site and run into trouble, often without realiz-ing it. Marketing results may be random, but interaction is not. The cognitivefriction generated by the software’s interactivity is what gives the impression ofrandomness to those untrained in interaction design.
The remarkably easy-to-change nature of the World Wide Web plays into thisbecause an advertisement or marketing campaign can be aired for a tiny fractionof the cost (and time) of print or TV advertising. The savvy Web marketer can getalmost instantaneous feedback on the effectiveness of an ad, so the speed of theiteration increases dramatically, and things are hacked together overnight. Inpractice, it boils down to “throw it against the wall and see what sticks.” Manymanagers of Web start-ups use this embarrassingly simple doctrine of design byguesswork. They write any old program that can be built in the least time andthen put it before their users. They then listen to the complaints and feedback,measure the patterns of the user’s navigation clicks, change the weak parts, andthen ship it again.
Generally, programmers aren’t thrilled about the iterative method because itmeans extra work for them. Typically, it’s managers new to technology who likethe iterative process because it relieves them of having to perform rigorous plan-ning, thinking, and product due diligence (in other words, interaction design). Ofcourse, it’s the users who pay the dearest price. They have to suffer through onehalfhearted attempt after another before they get a program that isn’t too painful.
50 / Part II: It Costs You Big Time
Just because customer feedback improves your understanding of your productor service, you cannot then deduce that it is efficient, cheap, or even effective totoss random features at your customers and see which ones are liked and whichare disliked. In a world of dancing bears, this can be a marginally viable strategy,but in any market in which there is the least hint of competition, it is suicidal.Even when you are all alone in a market, it is a very wasteful method.
Many otherwise sensitive and skilled managers are unashamedly proud of thismethod. One mature, experienced executive (a former marketing man) askedme, in self-effacing rhetoric, “How could anyone presume to know what theusers want?” This is a staggering question. Every businessperson presumes. Thevalue that most businesspeople bring to their market is precisely their “pre-sumption” of what the customer wants. Yes, that presumption will miss the markwith some users, but not to presume at all means that every user won’t like it. Thisfoolish man believed that his customers didn’t mind plowing through his guess-es to do his design work for him. Today, in Silicon Valley, there might be lots ofenthusiastic Web-surfing apologists who are willing to help this lazy executivefigure out his business, but how many struggling survivors did he alienate withthat haughty attitude? As he posted sketchy version after sketchy version of hissite, reacting only to those people with the stamina to return to it, how many cus-tomers did he lose permanently? What did they want? It has been said that theway Stalin cleared a minefield was to march a regiment through it. Effective? Yes.Efficient, humanitarian, viable, desirable? No.
Chapter 3: Wasting Money / 51
The biggest drawback, of course, is that you immediately scare away all survivors,and your only remaining users will be apologists. This seriously skews the natureand quality of your feedback, condemning you to a clientele of technoid apolo-gists, which is a relatively small segment. This is one reason why so few personal-computer software-product makers have successfully crossed over into massmarkets.
I am not saying that you cannot learn from trial and error, but those trials shouldbe informed by something more than random chance and should begin from awell-thought-out solution, not an overnight hack. Otherwise, it’s just giving lazyor ignorant businesspeople license to abuse consumers.
The Hidden Costs of Bad Software
When software is frustrating and difficult to use, people will avoid using it. That isunremarkable until you realize that many people’s jobs are dependent on usingsoftware. The corporate cost of software avoided is impossible to quantify, but itis real. Generally, the costs are not monetary ones, anyway, but are exacted in farmore expensive currencies, such as time, order, reputation, and customer loyalty.
People who use business software might despise it, but they are paid to tolerateit. This changes the way people think about software. Getting paid for using soft-ware makes users far more tolerant of its shortcomings because they have nochoice, but it doesn’t make it any less expensive. Instead—while the costs remainhigh—they become very difficult to see and account for.
Badly designed business software makes people dislike their jobs. Their produc-tivity suffers, errors creep into their work, they try to cheat the software, and theydon’t stay in the job very long. Losing employees is very expensive, not just inmoney but in disruption to the business, and the time lost can never be made up.Most people who are paid to use a tool feel constrained not to complain aboutthat tool, but it doesn’t stop them from feeling frustrated and unhappy about it.
One of the most expensive items associated with hard-to-use software is techni-cal support. Microsoft spends $800 million annually on technical support. Andthis is a company that spends many hundreds of millions of dollars on usabilitytesting and research, too. Microsoft is apparently convinced that support of thismagnitude is just an unavoidable cost of doing business. I am not. Imagine theadvantage it would give your company if you didn’t make the same assumptionthat Microsoft did. Imagine how much more effective your development effortswould be if you could avoid spending over five percent of your net revenue ontechnical support.
Ask any person who has ever worked at any desktop-software company in tech-nical support, and he will tell you that the one thing he spends most of his timeand effort on is the file system. Just like Jane in Chapter 1, users don’t understandthe recursive hierarchy of the file system—the Finder or Explorer—on Windows,the Mac, or Unix. Surprisingly, very few companies will spend the money todesign and implement a more human-friendly alternative to the file system.Instead, they accept the far more expensive option of answering phone callsabout it in perpetuity.
52 / Part II: It Costs You Big Time
You can blame the “stupid user” all you want, but you still have to staff thosephones with expensive tech-support people if you want to sell or distribute with-in your company software that hasn’t been designed.
The Only Thing More Expensive Than Writing Software IsWriting Bad Software
Programmers cost a lot, and programmers sitting on their hands waiting fordesign to be completed gall managers in the extreme. It seems foolish to haveprogrammers sit and wait, when they could be programming, thinks the manag-er. It is false economy, though, to put programmers to work before the design iscompleted. After the coding process begins, the momentum of programmingbecomes unstoppable, and the design process must now respond to the needs ofprogrammers, instead of vice versa. Indeed, it is foolish to have programmerswait, and by the simple expedient of having interaction designers plan your nextproduct or release concurrently with the construction of this product or release,your programmers will never have to idly wait.
It is more costly in the long run to have programmers write the wrong thing thanto write nothing at all. This truth is so counterintuitive that most managers balkat the very idea. After code is written, it is very difficult to throw it out. Like writ-ers in love with their prose, programmers tend to have emotional attachments totheir algorithms. Altering programs in midstride upsets the development processand wounds the code, too. It’s hard on the manager to discard code because sheis the one who paid dearly for it, and she knows she will have to spend even moreto replace it.
If design isn’t done before programming starts, it will never have much effect.One manager told me, “We’ve already got people writing code and I’m not gonnastop.” The attitude of these cowboys is, “By the time you are ready to hit theground, I’ll have stitched together a parachute.” It’s a bold sentiment, but I’venever seen it work.
Lacking a solid design, programmers continually experiment with their pro-grams to find the best solutions. Like a carpenter cutting boards by eye until hegets one that fits the gap in the wall, this method causes abundant waste.
The immeasurability and intangibility of software conspires to make it nearlyimpossible to estimate its size and assess its state of completion. Add in the pro-grammer’s joy in her craft, and you can see that software development alwaysgrows in scope and time and never shrinks. We will always be surprised during itsconstruction, unless we can accurately establish milestones and reliably meas-ure our progress against them.
Chapter 3: Wasting Money / 53
Opportunity Cost
In the information age, the most expensive commodity is not the cost of buildingsomething, but the lost opportunity of what you are not building. Building a failuremeans that you didn’t build a success. Taking three annual releases to get a goodproduct means that you didn’t create three good products in one release each.
Novell’s core business is networking, but it attempted to fight Microsoft toe-to-toe in the office-applications arena. Although its failed efforts in the new marketwere expensive, the true cost was its loss of leadership in the networking market.The money is nothing compared to the singular potential of the moment.Netscape lost its leadership in the browser market in the same way when itdecided to compete against Microsoft in the operating-system business.
Any developer of silicon-based products has to evaluate what the most impor-tant goals of its users are and steadfastly focus on achieving them. It is far tooeasy to be beguiled by the myriad of opportunities in high tech and to gambleaway the main chance. Programmers—regardless of their intelligence, businessacumen, loyalty, and good intentions—march to a slightly different drummerand can easily drag a business away from its proper area of focus.
The Cost of Prototyping
Prototyping is programming, and it has the momentum and cost of program-ming, but the result lacks the resiliency of real code. Software prototypes arescaffolds and have little relation to permanent, maintainable, expandablecode—the equivalent of stone walls. Managers, in particular, are loath to discardcode that works, even if it is just a prototype. They can’t tell the differencebetween scaffolding and stone walls.
You can write a prototype much faster than a real program. This makes it attrac-tive because it seems so inexpensive, but real programming gives you a reliableprogram, and prototyping gives you a shaky foundation. Prototypes are experi-ments made to be thrown out, but few of them ever are. Managers look at the run-ning prototype and ask, “Why can’t we just use this?” The answer is too technicallycomplex and too fraught with uncertainty to have sufficient force to dissuade themanager who sees what looks like a way to avoid months of expensive effort.
The essence of good programming is deferred gratification. You put in all of thework up front, and then you reap the rewards later. There are very few tasks thataren’t cheaper to do manually. Once written, however, programs can be run amillion times with no extra cost. The most expensive program is one that runsonce. The cheapest program is the one that runs ten billion times. However, anyinappropriate behavior will also be magnified ten billion times. Once out of therealm of little programs, such as the ones you wrote in school, the economics of
54 / Part II: It Costs You Big Time
software take on a strange reversal in which the cheapest programs to own arethe ones that are most expensive to write, and the most expensive programs toown are the cheapest to write.
Writing a big program is like making a pile of bricks. The pile is one brick wideand 1,000 bricks tall, with each brick laid right on top of the one preceding it. Thetower can reach its full height only if the bricks are placed with great precision ontop of one another. Any deviation will cause the bricks above to wobble, topple,and fall. If the 998th brick deviates by a quarter of an inch, the tower can stillprobably achieve 1,000 bricks, but if the deviation is in the fifth brick, the towerwill never get above a couple dozen.
This is very characteristic of software, whose foundations are more sensitive tohacking than the upper levels of code. As any program is constructed, the pro-grammer makes false starts and changes as she goes. Consequently, the programis filled with the scar tissue of changed code. Every program has vestigial func-tions and stubbed-out facilities. Every program has features and tools whoseneed was discovered sometime after construction began grafted onto it as after-thoughts. Each one of these scars is like a small deviation in the stack of bricks.Moving a button from one side of a dialog box to the other is like joggling the998th brick, but changing the code that draws all button-like objects is like jog-gling the 5th brick. Object-oriented programming and the principles of encap-sulation are defensive techniques whose sole purpose is to immunize theprogram from the effects of scar tissue. In essence, object orientation divides the1,000-brick tower into 10 100-brick towers.
Chapter 3: Wasting Money / 55
Good programmers spend enormous amounts of time and energy setting up towrite a big program. It can take days just to set up the programming environ-ment, before a line of product code is written. The proper libraries must beselected. The data must be defined. The storage and retrieval subsystems mustbe analyzed, defined, coded, and tested.
As the programmers proceed into the meat of the construction, they invariablydiscover mistakes in their planning and flaws in their assumptions. They are thenfaced with Hobson’s choice of whether to spend the time and effort to back upand fix things from the start, or to patch over the problem wherever they are andaccept the burden of the new scar tissue—the deviation. Backing up is alwaysvery expensive, but that scar tissue ultimately limits the size of the program—theheight of the bricks.
Each time a program is modified for a new revision to fix bugs or to add features,scar tissue is added. This is why software must be thrown out and completelyrewritten every couple of decades. After a while, the scar tissue becomes toothick to work well anymore.
Prototypes—by their very nature—are programs that are slapped together in ahurry so that the results can be assayed. What the programmer exchanges inorder to build the prototype so speedily is the perfect squaring of the bricks.Instead of using the “right” data structures, information is thrown in helter-skelter. Instead of using the “right” algorithms, whatever code fragments happento be lying around are drafted for service. Prototypes begin life as masses of scartissue. They can never grow very large.
Some software developers have arrived at the unfortunate conclusion that mod-ern rapid-prototyping tools—such as Visual Basic—are effective design tools.Rather than designing the product, they just whip out an extremely anemic ver-sion of it with a visual programming tool. This prototype typically becomes thefoundation for the product. This trades away the robustness and life span of theproduct for an illusory benefit. You can get a better design with pencil and paperand a good methodology than you can with any amount of prototyping.
For those who are not designers, visualizing the form and behavior of softwarethat doesn’t yet exist is difficult, if not impossible. Prototypes have been draftedinto the role of a visualization tool for these businesspeople. Because a prototypeis a rough model created with whatever prebuilt facilities are most readily avail-able, prototypes are by nature filled with expedient compromises. But softwarethat actually works—regardless of how badly—exerts a powerful pull on thosewho must pay for its development. A running—limping—prototype has anuncanny momentum out of proportion to its real value.
56 / Part II: It Costs You Big Time
It is all too compelling for the manager to say, “Don’t throw out the prototype. Let’suse it as the foundation for the real product.” This decision can often lead to a sit-uation in which the product never ships. The programmers are condemned to arole of perpetually resuscitating the program from life-threatening failures as itgrows. Like the stack in which the first 25 bricks were placed haphazardly, no mat-ter how precisely the bricks above them are placed, no matter how diligently themason works, no matter how sticky and smooth the mortar, the force of gravityinevitably pulls it down somewhere around the 50th level of bricks.
The value of a prototype is in the education it gives you, not in the code itself.Developer sage Frederick Brooks says, “Plan to throw one away.” You will anyway,so you might as well do it under controlled circumstances.
In 1988, I sold a program called Ruby to Bill Gates. Ruby was a visual program-ming language that, when combined with Bill’s QuickBasic product, becameVisual Basic. What Gates saw was just a prototype, but it demonstrated some sig-nificant advances both in design and technology. (When he first saw it, he asked,“How did you do that?”) The Microsoft executive in charge of then-under-construction Windows 3.0, Russ Werner, was also assigned to Ruby. The subsequent deal we struck included having me write the actual program to com-pletion. The first thing I did was to throw Ruby-the-prototype away and start overfrom scratch with nothing but the wisdom and experience. When Russ foundout, he was astonished, angry, and indignant. He had never heard of such an out-rageous thing, and was convinced that discarding the prototype would delay theproduct’s release. It was a fait accompli, though, and despite Russ’s fears wedelivered the completed program on schedule. After Basic was grafted on, VB wasone of Microsoft’s more successful initial releases. In contrast, Windows 3.0shipped more than a year late, and ever since it has been notoriously handi-capped by its profuse quantities of vestigial prototype code.
In general, nontechnical managers erroneously value completed code—regardless of its robustness—much higher than design, or even the advice ofthose who wrote the code. A colleague, Clay Collier, who creates software for in-car navigation systems, told me this story about one system that he worked onfor a large Japanese automotive electronics company. Clay developed—at hisclient’s behest—a prototype of a consumer navigation system. As a good proto-type should, it proved that the system would work, but beyond that the programbarely functioned. One day the president of the Japanese electronics companycame to the United States and wanted to see the program demonstrated. Clay’scolleague—we’ll call him Ralph—knew that he could not deny the Japanese pres-ident; he would have to put on a demo. So Ralph picked the president up at LAXin a car specially equipped with the prototype navigation system. Ralph knewthat the prototype would give them directions to their offices in Los Angeles, but
Chapter 3: Wasting Money / 57
nothing else had been tested. To Ralph’s chagrin, the president asked instead togo to a specific restaurant for lunch. Ralph was unfamiliar with the restaurantand wasn’t at all confident that the prototype could get them there. He crossedhis fingers and entered the restaurant’s name, and to his surprise, the computerbegan to issue driving instructions: “Turn right on Lincoln,” “Move into the leftlane,” and so on. Ralph dutifully followed as the president ruminated silently, butRalph began to grow more uneasy as the instructions took them into increasing-ly unsavory parts of town. Ralph’s anxiety peaked when he stopped the car on thecomputer’s command and the passenger door was yanked open. To Ralph’s eter-nal relief, the valet at the desired restaurant had opened it. A smile broke acrossthe president’s face.
However, the very success of this prototype demonstration backfired on Ralph.The president was so impressed by the system’s functioning that he commandedthat Ralph turn it into a product. Ralph protested that it was just a feasibilityproof and not robust enough to use as the foundation for millions of consumerproducts. The president wouldn’t hear of it. He had seen it work. Ralph did as hewas told, and eight long years later his company finally shipped the first workingversion of the product. It was slow and buggy, and it fell short of newer, youngercompetitors. The New York Times called it “clearly inferior.”
The expertise and knowledge that Ralph and his team gained by building theprototype incorrectly was far more valuable than the code itself. The presidentmisunderstood that and, by putting greater value on the code, made the entirecompany suffer for it.
x
If you define the boundaries of a development project only in terms of deadlinesand feature lists, the product might be delivered on time, but it won’t be desired.If, instead, you define the project in terms of quality and user satisfaction, youwill get a product that users want, and it won’t take any longer. There’s an oldSilicon Valley joke that asks, “How do you make a small fortune in software?” Theanswer, of course, is, “Start with a large fortune!” The hidden costs of even well-managed software-development projects are large enough to give Donald Trumppause. Yacht racing and drug habits are cheaper in the long run than writing soft-ware without the proper controls.
58 / Part II: It Costs You Big Time
Numbers1-Click interface (Amazon.com),
108-1093Com’s PalmPilot, 1983M Post-It Notes, 126
AAbout Face, 199, 211Access, 45Accidental Empires, 161Action Request System project, 135Adobe Photoshop, 65aesthetics versus functionality, 212airplanes
IFEs, 11-13navigation computers, 3-4programmers as pilots, 96
alarm clocks, design problems, 6-7aliasing, 195Amazon.com 1-Click interface, 108-109American Airlines flight 965, 3-4anticipation of needs, 165apologists, 30-33, 36Apple, 75-77, 210Apple Newton, 45Atkinson, Bill, 89ATMs
confirmation messages, 68design problems, 8-9
attrition strategy, 214-215audience, narrowing, 124-126automated systems, 168automobile market, 241
Bbad design. See also cognitive friction
acceptance of, 59ATMs, confirmation messages, 68blaming users, 34-36calendar software, 63causes, 14-16confirmation dialog boxes, 67-68
costs, 17, 27-29business software, 52-53loss of market share, 82-83narratives about, 83-87opportunity cost, 54prototyping, 54-55
effectsalarm clock, 6-7ATMs, 8-9digital cameras, 4-6employability, 11IFEs, 11-13navigational computers (air-
planes), 3-4Porsche Boxster, 8productivity loss, 9-11techno-rage, 13-14USS Yorktown, 13
email, 61-62file systems, 9-11reaction to, 33-34scheduling programs, 62-63technology as solution for, 213VCRs, 60-61
bargaining. See feature list bargainingbehavioral design, 23bell curve of skill levels, 182-185“Betsy” (Elemental Drumbeat persona),
172Bezos, Jeff, 108-109Bjerke, Carolyn, 114Blair, Alice, 115“blaming the user”, 34-36, 67bloatware, 29blueprints
as product descriptions, 42-43design documentation as, 226, 235-
236Borland International, 72-73Borque, Michel, 236boundary conditions, 100“brains” versus “gray hair” (consulting),
220brick towers, programs as, 55-56Bronson, Po, 95-96, 100-101, 208
Index
Brooks, Frederick, 57, 219browser-based software, 64-65building design teams, 234business people, role of, 71-72business software, 52-53buyer personas, 135
Ccalendar software, usability problems,
63cancellation of products, 44-45capability, 71, 78case studies
Elemental Drumbeat, 171competition, 173design, 174-176floating palettes, 176-177goals, 173-174personas, 172-173product success, 177
Logitech ScanMancropping tools, 193-194personas, 188-191“pretend it’s magic” exercise,
191-192reorienting images, 195-197resizing images, 194results, 197
Sony Trans Com’s P@ssport, 138designing interface, 144-147original interface, 139, 142personas, 142-144
cast of characters, 135-138. See also per-sonas
CD-ROM player, cognitive friction of, 28“Chad Marchetti, Boy” (Logitech
ScanMan persona), 189choices, presenting, 167-168classroom management system, 153“Clevis McCloud” (P@ssport persona),
142-147“clinical vortex”, 236cognitive friction, 19. See also bad
designapologists, 30-33, 36CD-ROM player, 28computers, 20costs of, 27-29engineering skills and, 92microwaves, 20picture-in-picture television, 33
246 / Brooks, Frederick
reaction to, 33-34remote keyless entry, 24-26source of, 27survivors, 31-33Swiss Army knife, 24typewriters, 20versus industrial design problems,
212-213violins, 20WWW, 20
common sense in software, 164common vocabulary, specifying, 185-186competing against attrition strategies,
215completion, determining, 42-43“computer literacy”, 11, 35-38, 242Computer Tourette’s, 14computerized devices versus manual
devices, 7computerized systems, 168computers
ATMs, 8-9cognitive friction of, 20democratization of, 34emotional response to, 159-160employee training, 11handheld, 45IFEs, 11-13in alarm clocks, 6-7in cameras, 4-6navigational (airplanes), 3-4Porsche Boxster, 8problems, displaying to user,
165-166technological advances, 119versus humans, 87-88
conceptual design, 23conceptual integrity, 219-220confirmation dialog boxes, 67-68conflicts of interest
interface style guides, 210programmers 16, 108users, 108
consultants, 220-221consumer electronics as dancing bear-
ware, 60-61control, programmers’ need for, 96-97core competence, design as, 238-239corner cases, 100corporate goals, 156-157Cosby, Kendall, 115CPUs, sparing, 119
design / 247
Cringely, Robert X., 95, 161cropping tools, Logitech ScanMan,
193-194Crossing the Chasm, 77culture of programming, 105. See also
psychology of programmersauthority figures and, 118isolation, 115-116Microsoft, 110-114military culture comparison, 109propagation of, 110reusing code, 106-109reverence for technical skill,
109-110“scarcity thinking”, 119-120sense of responsibility, 116-118sense of superiority, 117
customer demands, personas and, 222customer loyalty
advantages, 76-77Apple, 75-77generating, 73
by narrowing user audience,124-126
through interaction design,240-241
Microsoft, 75Novell, 74-75
customer-driven companies, 218as service companies, 220-221conceptual integrity, 219-220
cutting features, 222-223
Ddaily use scenarios, 180dancing bears, 26-27
calendar software as, 63email as, 61-62Explorapedia as, 111NetWare, 74satisfaction with, 59scheduling programs as, 62-63VCRs as, 60-61WWW as, 32
de Bono, Edward, 187deadline management, 41
determining completion, 42-43fear of cancellation, 44-45“feature list bargaining”, 46-47Gresham’s Law, 44late shipment, 45-46
Ninety-Ninety Rule, 43Parkinson’s Law, 43Product Managers, 44
debugging, 242-243deferential role of software, 163-164dehumanizing processes, 120design
advantages versus time to marketadvantages, 77, 84-85
after programming, 53, 110as core competence, 238-239as “pre-production” phase, 223-225before programming, 204behavioral, 23company-wide awareness, 238-239conceptual, 23conceptual integrity, 219-220disrespect for, 117documenting, 226-227, 235-236
benefit to companies, 231benefit to managers, 230-231benefit to marketing, 229-230benefit to programmers,
228-229benefit to tech support, 230benefit to technical writers,
230effect on code, 227-228evaluating, 149, 208-209for narrow audiences, 124-126free features, 28generating customer loyalty with
(Apple), 75-77Goal-Directed
classroom management sys-tem example, 153
defined, 151-152television news show exam-
ple, 152-153implementation model, 27industrial, 212-213interaction design, 21, 87interface
disadvantages, 23versus interaction design,
227-228iteration in, 213-214politeness, 160
“polite” software characteris-tics, 162-171
politeness versus humanness,161-162
processes, 21program design, 21scheduling time for, 222self-referential, 87task-directed, 151timing, 203-205versus iteration, 50-52versus product specifications, 81versus prototyping, 56visual, 211-212
design personas. See personasdesign teams, 207, 234design-dominated markets, 78design-friendly processes, 232-233designers
building teams, 234disrespect for, 117hiring, 233programmers as, 22-23, 207-208
conflicts of interest, 108General Magic, 81shortcomings, 82-83, 87-92training, 88
responsibility for quality, 231-232role of, 72
desirability versus need, 72-74development processes
changing, 242-243dehumanizing effects of, 120sequence of events, 203-205usability testing, 206-207
“devil’s advocate”, 188digital cameras, design problems, 4-6discrimination, 37Doblin Group, 71documenting design, 226-227, 235-236
benefit to companies, 231benefit to managers, 230-231benefit to marketing, 229-230benefit to programmers, 228-229benefit to tech support, 230benefit to technical writers, 230
“dog’s breakfast”, 219Drumbeat. See Elemental Drumbeat
case study
Eedge case scenarios, 181edge cases, 100Einstein, Albert, 123“elastic users”, 127-128
248 / design
Elemental Drumbeat case study, 171competition, 173design, 174-176floating palettes, 176-177goals, 173-174personas, 172-173product success, 177
Elemental Software, 107email
threads, 61usability problems, 61-62
emotional response to computers, 159-160
employability, 11encapsulation, 55end-user design. See interaction designenterprise resource planning (ERP) com-
panies, 218“Ernie” (Elemental Drumbeat persona),
172ERP (enterprise resource planning) com-
panies, 218“euphemism pyramid”, 35. See also skill
levelsevaluating design, 149, 208-209Evenson, Shelley, 209Evers, Ridgely, 44excise, 176“expect what you inspect”, 85experience versus expertise (consulting),
220expertise versus experience (consulting),
220Explorapedia, 110
as dancing bear, 111development of, 111programmers’ views on, 112success of, 111weaknesses of, 112
Ffacts versus information, 4false goals, 158-159Farros, Royal, 44, 47“feature list bargaining”. See also product
descriptions“line of death”, 46personas as solution for, 132-134programmer’s role in, 47
feature-dominated markets, 78
inflexibility of software / 249
featuresadvantages/disadvantages, 47cost of, 27-29customer demands, personas and,
222cutting, 222-223influence on marketplace, 77“less is more” philosophy, 198-200list of, versus product description,
42lists, 46usage/interaction relationship, 33versus goals, 48
feedback loopsnegative, 27software design, 28-29
file systemshierarchical, 9-11technical support costs, 52
filmmaking (compared to softwaredevelopment), 223-225
focus groups, 210-211forgetfulness of software, 65Forman, Ed, 107Fox, Sara, 112free features, 28Fry, Art, 126“fudgability” of software, 168-170functionality versus aesthetics, 212
GGammill, Kevin, 112-114Gates, Bill, 45Gay, Jim, 91-92Gellerman, Saul, 157General Magic, 81, 89Glen, Paul, 119Goal-Directed design. See also interac-
tion designdefined, 151-152examples, 152-153
goals, 124, 149. See also personascorporate, 156-157Elemental Drumbeat case study,
173-174false, 158-159hygienic, 157personal, 154-156practical, 154, 157versus features, 48versus tasks, 150-151
Gorelik, Vlad, 115graphical user interfaces (GUIs), 211“gray hair” versus “brains” (consulting),
220Gresham’s Law, 44GUIs (graphical user interfaces), 211
Hhandheld computers, 45hardware, bridging software to, 197-198haves and have-nots, 37Heathershaw-Hart, Tamra, 118Hertzfeld, Andy, 89Hewlett-Packard, 197hierarchical file systems, 9-11high-technology businesses
capability, 71desirability, 72viability, 71
hiring designers, 233“Homo logicus”, 93-101How the Mind Works, 160humanness in software, 161-162. See
also “polite” softwarehumans versus computers, 87-88hybrid products, 197-198hygienic factors, 157hygienic goals, 157hypothetical archetypes. See personas
II Sing the Body Electronic, 110-114IBM as customer-driven company, 218IFEs (in-flight entertainment systems),
11-13. See also Sony Trans Com’sP@ssport case study
images (Logitech ScanMan)reorientation, 195-197resizing, 194
implementation model, 27in-car navigation system prototype,
57-58in-flight entertainment systems (IFEs),
11-13. See also Sony Trans Com’sP@ssport case study
industrial age, 19industrial design, 212-213“inflecting the interface”, 181-182inflexibility of software, 66-67
informationsoftware’s providing of, 164versus facts, 4
information age, 19installation, 64-65instant gratification in software, 170interaction design
as Goal-Directed, 151-152assumptions of limitations, 187benefits, 239-240cast of characters, 135-137commitment to, 225-226defined, 21documenting, 226-227, 235-236
benefit to companies, 231benefit to managers, 230-231benefit to marketing, 229-230benefit to programmers,
228-229benefit to tech support, 230benefit to technical writers,
230effect on code, 227-228frustrations of, 200generating customer loyalty with,
240-241goals, 149
corporate, 156-157false, 158-159hygienic, 157personal, 154-156practical, 154, 157versus tasks, 150-151
hiring designers, 233“inflecting the interface”, 181-182interaction implementation and,
117“less is more” philosophy, 198-200perpetual intermediates, 182-185personas, 123-124
as communications tools,132-134
buyer personas, 135customer demands and, 222designers’ need for, 134Logitech ScanMan case study,
188-191naming, 128negative personas, 136precision versus accuracy,
129-131
250 / information
primary personas, 137-138skill levels, 131-132Sony Trans Com’s P@ssport
case study, 142-147specifying, 128-129stereotyping, 128versus users, 127-129
politeness, 160“polite” software characteris-
tics, 162-171politeness versus humanness,
161-162“pretend it’s magic” exercise, 185,
191-192priority of, 22scenarios, 179-181separating from program design, 22versus industrial design, 212-213versus interface design, 23, 227-228versus new technology, 213versus self-referential design, 87vocabulary, 185-186
interaction designers, responsibility forquality, 231-232
interaction implementation, interactiondesign and, 117
interactive design versus product speci-fications, 81
interface designdisadvantages, 23versus interaction design, 227-228
interface style guides, 209-210Internet. See WWWiteration
in design, 213-214personas, 124reducing, 240versus design, 50-52
J - K“jaggies”, 195“Jetway Test”, 93-94“jocks,” programmers as, 101-104
Karp, Alan, 200Keeley, Larry, 211
tripod model, 71-73Apple, 75-77Microsoft, 75Novell, 74-75
Novell / 251
Korman, Jonathan, 98Krause, Kai, 199
Llate product shipment, 45-46lateral thinking, 187Lateral Thinking, 187laziness of software, 65Leading Geeks, 119“less is more” philosophy, 198-200limitations, assumptions of, 187“line of death” (“feature list bargain-
ing”), 46Logitech ScanMan case study
cropping tools, 193-194personas, 188
Chad Marchetti, Boy, 189Magnum, DPI, 190-191Malcom, the Web-warrior,
189“pretend it’s magic” exercise,
191-192reorienting images, 195-197resizing images, 194results, 197
long-term versus short-term thinking(managers), 221-222
MMagic Link computer, 45“Magnum, DPI” (Logitech ScanMan
persona), 190-191Maister, David, 220-221making movies (compared to software
development), 223-225“Malcom, the Web-Warrior” (Logitech
ScanMan persona), 189managers
commitment to design, 225-226cutting features, 222-223design documents and, 230-231influences on, 217moviemaker comparison, 223-225short-term versus long-term think-
ing, 221-222taking control, 222
Managing the Professional Service Firm,220-221
manual devices versus computerizeddevices, 7
manual systems, 168market unpredictability, myth of, 48-49marketing, design documents and,
229-230marketing personas, 134marketing requirements documents, 46marketing specifications, 46McGregor, Scott, 44, 83-86measures
importance of, 85objective, 49quantitative, 49
memory, human versus computer, 87Merrin, Seymour, 240metafunctions, 20-21method acting, scenarios as, 179Microsoft, 45, 75
attrition strategy, 214-215competing against, 215, 241interface style guides, 210programming culture, 110-114technical support costs, 52Windows, design interaction, 214
microwaves, cognitive friction of, 20monocline groupings, 145Moody, Fred, 110-114Moore, Geoffrey, 77Motivation and Productivity, 157moviemaker, manager comparison,
223-225mud-hut design, 22-23multidisciplinary design teams, 207
Nnaive users, 35naming personas, 128narrowing user audience, 124-126Nass, Clifford, 159navigational computers (airplanes), 3-4necessary use scenarios, 180need versus desirability, 73-74negative feedback loops, 27-29negative personas, 136NetWare, 74new technology versus interaction
design, 213Newton computer, 45Ninety-Ninety Rule, 43Nomadic Computing, 45Novell, 74-75
O - Pobject-oriented programming, 55objective measures, 49opportunity cost, 54options, presenting, 167-168Oracle, as customer-driven company,
218
“painting the corpse”, 142, 212PalmPilot, 45, 48, 198Parkinson’s Law, 43Peacock. See Logitech ScanMan case
studyPenPoint computer, 45perceptiveness in software, 166performance measures, 85perpetual intermediates, 182-185personal goals, 154-156personalization of software, 162-163personas, 123. See also goals
as communications tools, 132-134buyer personas, 135cast of characters, 135-137customer demands and, 222defining, 124designers’ need for, 134Elemental Drumbeat case study,
172-173Logitech ScanMan case study,
188-191marketing personas, 134naming, 128negative personas, 136precision versus accuracy, 129-131primary personas, 137-138Shared Healthcare Systems project,
236skill levels, 131-132Sony Trans Com’s P@ssport case
study, 142-147specifying, 128-129stereotyping, 128versus users, 127-129
picture-in-picture television, cognitivefriction of, 33
pilots, programmers as, 96Pinker, Steven, 160planning
financial/operational, 222product, 222
252 / object-oriented programming
“playing devil’s advocate”, 188Pleas, Keith, 161“polite” design, 161“polite” software, 160
characteristics ofanticipation of needs, 165common sense, 164deferential role, 163-164“fudgability”, 168-170instant gratification, 170perceptiveness, 166personalization, 162-163presentation of choices,
167-168providers of information, 164responsiveness, 165self-confidence, 167taciturn about problems,
165-166trustworthiness, 170well-informed, 166
politeness versus humanness, 161-162
Porsche Boxster, design problems, 8Post-It Notes, 126power user. See apologistpractical goals, 154, 157“pre-production” phase, design as,
223-225precision versus accuracy (in personas),
129-131presentation of choices, 167-168“pretend it’s magic” exercise, 185,
191-192primary personas, 137-138“Principle of Commensurate Effort”, 155problems (of computer), displaying to
users, 165-166processes
changing, 242-243dehumanizing effects of, 120design-friendly, 232-233
product completion, determining, 42-43product descriptions. See also “feature
list bargaining”blueprints as, 42-43versus feature lists, 42
product developmentcustomer-driven, 218
as service provider, 220-221conceptual integrity, 219-220
Ruby / 253
filmmaking comparisons, 223-225influences on, 217
product development managers. Seemanagers
Product Managersdeadline creation, 44fear of product cancellation, 44-45
productivity loss, 9-11, 52products
cancellations, 44-45late shipment, 45-46quality, responsibility for, 231-232specifications versus design, 81
program designdefined, 21priority of, 22traditional practices, 22-23
programmers”feature list bargaining”, 47as “Homo logicus”, 93-98as apologists, 30as designers, 22-23, 207-208
conflicts of interest, 108General Magic, 81shortcomings, 82-83, 87-92training, 88
conflict of interest, 16control over products, 82-83, 228cost of, 53design documents and, 228-229psychology of, 95
desire for control, 96-97desire for understanding,
97-99focus on possibilities, 99-101programmers as “jocks”,
101-104programmers as pilots, 96
role of, 71-72shortcomings, 14-16willingness to change, 242-243
programmingbefore design, 53, 110complexity of, 205culture of, 105
authority figures and, 118isolation, 115-116Microsoft, 110-114military culture comparison,
109
propagation of, 110reusing code, 106-109reverence for technical skill,
109-110“scarcity thinking”, 119-120sense of responsibility,
116-118sense of superiority, 117
designing before, 204usability testing and, 206
prototypes, 54-55as product foundations, 57in-car navigation system example,
57-58Ruby, 57value, 57-58versus design, 56
psychology of programmers, 95. See alsoculture of programming
desire for control, 96-97desire for understanding, 97-99focus on possibilities, 99-101programmers as “jocks”, 101-104
Q - Rquality, responsibility for, 231-232quality measures, 85quantitative measures, 49QuickBooks, development time, 44
Raymond, Eric, 106recognizing good design, 208-209“redlining”, 38Reeves, Byron, 159Remedy Inc, 135remote keyless entry, cognitive friction
of, 24-26reorienting images, Logitech ScanMan,
195-197resizing images, Logitech ScanMan, 194response to computers, 159-160responsibility of software, 67-69responsiveness in software, 165reusing code, 106-109Rheinfrank, John, 209“riding the tiger”, 217Rivlin, John, 86-87roll-aboard suitcases, 126, 130Ruby (programming language), 57
SSagent Technology, 115SAP, as customer-driven company, 218ScanMan. See Logitech ScanMan case
study“scar tissue” in programs, 55-56“scarcity thinking”, 119-120scenarios, 179
breadth versus depth, 180constructing, 180daily use, 180necessary use, 180-181
scheduling programs, usability prob-lems, 62-63
“seat at the table” design teams, 207self-confidence in software, 167self-referential design versus interaction
design, 87service companies, 220-221“Seven Habits of Highly Engineered
People”, 95-96Shared Healthcare Systems project
“clinical vortex”, 236-237personas, 236programmers, 237unification of system, 237
shipping products late, 45-46“shopping lists” of features, 42short-term versus long-term thinking
(managers), 221-222Silicon Valley, California, 240skill levels, 131-132, 182-185. See also
euphemism pyramid“skin in the game”, 116-118, 225software
bridging hardware to, 197-198browser-based, 64-65forgetfulness, 65inflexibility, 66-67installation, 64-65lack of responsibility, 67-69laziness, 65user blame, 67witholding information, 66
“software apartheid”, 11, 36-38software design, usability problems. See
also designalarm clock, 6-7ATMs, 8-9causes, 14-16
254 / Sagent Technology
costs, 17digital cameras, 4-6file systems, 9-11IFEs, 11-13navigational computers (airlines),
3-4Porsche Boxster, 8Windows NT (USS Yorktown), 13
software development process, chang-ing, 242-243
software engineers. See programmersSony Trans Com’s P@ssport case study,
138original interface, 139, 142personas, 142-147
source code versus vocabulary, 186special cases, 100specifying personas, 128-129stereotyping personas, 128sticky notes, 126“stinking gods among men”, 95style guides, 209-210survivors, 31-33Swiss Army knife, cognitive friction of,
24
TT/Maker software company, 44, 47task-directed design, 151tasks versus goals, 150-151“teaching dogs to be cats”, 88teams, 207tech support, design documents and,
230technical managers. See managerstechnical specifications, 46technical support, 52technical writers, design documents
and, 230techno-rage, 13-14technology
democratization of, 34versus interaction design, 213
television news show application, 152-153
testing code, 242-243testing. See usability testingThe First $20 Million Is Always the
Hardest, 96The Media Equation, 159
Zicker, John / 255
The Secrets of Consulting “A Guide toGiving & Getting Advice Successfully”,88
They’re Mad as Hell Out There, 244threads (email), 61time to market advantage versus design
advantage, 77, 84-85timing of design, 203-205training, 11TransPhone, 91-92trustworthiness of software, 170typewriters, cognitive friction of, 20
UU.S. Navy warships, 13understanding, programmers’ need for,
97-99“uninformed consent”, 140unpredictable markets, myth of, 48-49usability problems
acceptance of, 59alarm clock, 6-7ATMs, 8-9, 68blaming users, 34-36calendar software, 63causes, 14-16costs, 17, 27-29
business software, 52-53loss of market share, 82-83narratives about, 83-87
digital cameras, 4-6email, 61-62engineering skills and, 92file systems, 9-11IFEs, 11-13navigational computers (airlines),
3-4Porsche Boxster, 8reaction to, 33-34scheduling programs, 62-63technology as solution for, 213VCRs, 60-61Windows NT (USS Yorktown), 13
usability testing, 205before programming, 206evaluating design, 208-209focus groups, 210-211iteration, 213-214timing, 206-207
“user friendly”, 60users versus personas, 127-129USS Yorktown, 13
V - WVCRs, as dancing bearware, 60-61viability, 71, 78violins, cognitive friction of, 20visual design, 211-212“visual design language” (Xerox), 209vocabulary
specifying, 185-186versus source code, 186
warships, 13Web. See WWWWeinberg, Jerry, 88well-informed software, 166West, David, 237“wet dogs”, 31Wildstrom, Stephen, 244Windows, design iteration, 214Windows 95 file system, 9-11Windows NT, USS Yorktown problems,
13Worlds, Inc., 45WriteNow, 47WWW (World Wide Web)
as dancing bear, 32cognitive friction of, 20ease of use, 241
X - Y - ZXerox, “visual design language”, 209
Zicker, John, 219
Alan Cooper
As a software inventor in the mid-70s, Alan got it into his head that there must bea better approach to software construction. This new approach would free usersfrom annoying, difficult, and inappropriate software behavior by applying adesign and engineering process that focuses on the user first, and silicon second.Using this process, engineering teams could build better products faster by doingit right the first time.
His determination paid off. In 1990 he founded Cooper, a technology productdesign firm. Today, Cooper’s innovative approach to software design is recognizedas an industry standard. Over a decade after Cooper opened its doors for busi-ness, the San Francisco firm has provided innovative, user-focused solutions forcompanies such as Abbott Laboratories, Align Technologies, Discover FinancialServices, Dolby, Ericsson, Fujitsu, Fujitsu Softek, Hewlett Packard, Informatica,IBM, Logitech, Merck-Medco, Microsoft, Overture, SAP, SHS Healthcare, Sony,Sun Microsystems, the Toro Company, Varian, and VISA. The Cooper team offerstraining courses for the Goal-Directed® interaction design tools they have invent-ed and perfected over the years, including the revolutionary technique for mod-eling and simulating users called personas, first introduced to the public in 1999via the first edition of The Inmates.
In 1994, Bill Gates presented Alan with a Windows Pioneer Award for his inven-tion of the visual programming concept behind Visual Basic, and in 1998 Alanreceived the prestigious Software Visionary Award from the Software Developer’sForum. Alan introduced a taxonomy for software design in 1995 with his best-selling first book, About Face: The Essentials of User Interface Design. Alan and co-author Robert Reimann published a significantly revised edition, About Face: TheEssentials of Interaction Design, in 2003.
Alan’s wife, Susan Cooper, is President and CEO of Cooper. They have two teenagesons, Scott and Marty, neither of whom is a nerd. In addition to software design,Alan is passionate about general aviation, urban planning, architecture, motorscooters, cooking, model trains, and disc golf, among other things. Please sendhim email at [email protected] or visit Cooper’s Web site at www.cooper.com.
