Foreword
I recently met with a senior executive at one of the world's largest technology companies. His official title is Vice President for Ease of Use, and he is responsible for a great number of software products, large and small. He is a brilliant and accomplished fellow with roots in the formal Human-Computer Interaction community. He is steeped in the ways of "usability" of testing and observing behind 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 completely ceased all postdevelopment usability testing and has instead committed to predevelopment design efforts. He further asserted that all of his staffers trained in the art of in vitro user observation were being retrained to do in situ ethnographic research. This executive and his company are emblematic of the sea of change that has occurred in the industry in the five short years since The Inmates was first published. The book has served as both a manifesto for a revolution and a handbook for a discipline. Countless midlevel product managers have sent me email describing why after reading The Inmates they purchased a copy of the book for each of their departments' senior executives. Meanwhile, software builders and universities alike have used the three chapters in Part IV, "Interaction Design Is 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 usability practitioners who have used the ideas in this book to help bring usability out of 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 has changed. Today, most of the organizations I have contact with have one or more interaction-design professionals on their payrolls, who have an ever-increasing influence over the quality and behavior of the software products and services being 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 the book, and I opened by asserting that "inmates are running the asylum, and you are the inmates." You could hear a pin drop as the more than 2,500 engineers in the audience grappled with that accusation. In the silence that engulfed the auditorium, I went on to present the basic premise of this book, and an hour later, that crowd of Homo logicus was so sufficiently convinced that they honored me with a standing ovation. Surprisingly, most programmers have become enthusiastic supporters of design and designers. They know that they need help on the human side of software construction, and they are very happy to be finally receiving some useful guidance. They recognize that any practice that improves the quality and acceptance of their programs doesn't threaten them. In the past, executives assumed that interaction design was a programming problem and delegated it to programmers, who diligently tried to solve the problem even though their skills, training, mindset, and work schedule prevented them from succeeding. In the spirit of problem diagnosis, this book takes pains to 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 or blaming programmers for bad software. They are certainly the agents by which bad software is created, but they are by no means culpable. I do not blame programmers for hard-to-use software, and I'm very sorry to have given any programmer a contrary impression. With few exceptions, the programmers I know are diligent and conscientious in their desire to please end users and are unceasing in their efforts to improve their programs' quality. Just like users, programmers are simply another victim of a flawed process that leaves them too little time, too many conflicting orders, and utterly insufficient guidance. I am very sorry to have given any programmers the impression that I fault them. The intractability of the software-construction process particularly the high cost of programming and the low quality of interaction is simply not a technical problem. It is the result of business practices imposed on a discipline software programming for which they are obsolete. With pure hearts, the best of intentions, and the blessing of upper management, programmers attempt to fix this problem by engineering even harder. But more or better engineering cannot 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 programmers. Sadly, it is the best and most experienced of them who are afflicted the worst. They reflect cynicism and ennui about their efforts because they know that their skills are being wasted. They may not know exactly how they are misapplied, but they cannot overlook the evidence. Many of the best programmers have actually stopped programming because they find the work frustrating. They have retreated into training, evangelism, writing, and consulting because it doesn't feel so wasteful and counterproductive. This is a tragic and entirely avoidable loss. (The open-source movement is arguably a haven for these frustrated programmers a place where they can write code according to their own standards and be judged solely by their peers, without the advice or intervention of marketers or managers.) Programmers are not given sufficient time, clear enough direction, or adequate designs to enable them to succeed. These three things are the responsibility of business executives, and they fail to deliver them for preventable reasons, not because they are stupid or evil. They are simply not armed with adequate tools for solving the complex and unique problems that confront them in the information age. Now here I am sounding like I'm slamming people again, only this time businesspeople are in my sights instead of programmers. Once again, to solve the problem one must deconstruct it. I'm questing after solutions, not scapegoats. Management sage Peter Drucker can see the problem from his unique viewpoint, having both observed and guided executives for the majority of his 92 years. In a recent interview in CIO magazine, he commented on the wide-eyed optimism of executives in the 1950s and 1960s as digital computers first nudged their way into their businesses. Those executives imagined that computers "would have an enormous impact on how the business was run," but Drucker exclaims, "This isn't what happened. Very few senior executives have asked the question, 'What information do I need to do my job?'" Although digital computers have given executives unprecedented quantities of data, few have asked whether this data is appropriate for guiding the corporation. Operations have changed dramatically, but management has not followed suit. Drucker accuses our obsolete accounting systems, born in mercantilism, come of age in an era of steam and iron, and doddering into senility in the dawning twenty-first century information age. Drucker asserts, "The information you need the most is about the outside world, and there is absolutely none." During the last few years of the twentieth century, as the dot-com bubble inflated, 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 different way of doing business, and that the "old economy" was as good as dead. Of course, almost all of those new-economy companies are dead and gone, the venture capitalists who backed them are in shock, and the pundits who pitched the new 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. Actually, I believe that we really are in a new economy. What's more, I think that the dot-coms never even participated in it. Instead, the dot-coms were the last gasp of the old economy: the economy of manufacturing. In the industrial age, before software, products were manufactured from solid material 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 with each product built. "Fixed costs," as you might expect, don't vary directly and include things such as corporate administration and the initial cost of the factory. The classic rules of business management are rooted in the manufacturing traditions of the industrial age. Unfortunately, they have yet to address the new realities of the information age, in which products are no longer made from atoms but are mostly software, made only from the arrangements of bits. And bits don't follow the same economic rules that atoms do. Some fundamental truths hold for both the old and the new economies. The goal of all business is to make a sustainable profit, and there is only one legal way to do so: Sell some goods or services for more money than it costs you to make or acquire them. It follows that there are two ways to increase your profitability: Either reduce your costs or increase your revenues. In the old economy, reducing your costs worked best. In the new economy, increasing your revenue works much, much better. Today's most vital and expensive products are made largely or completely of software. They consume no raw materials. They have no manufacturing cost. They have no transportation cost. There is no welding, hammering, or painting. This is the real difference between the industrial-age economy and the information-age economy: In the information age, there is little or no variable cost, whereas in the late industrial age, variable cost was the dominant factor. Indeed, the absence 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 programming can be leveraged across millions of salable items, just as an investment in a factory 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 who build the factory leave and go to work on some other job after the building is erected. Programmers are far more expensive than carpenters or ironworkers, and they never go away because their work is apparently never completed. Some might suggest that programming is research and development, and there are similarities. However, R & D is the thinking and experimenting done to establish the theoretical viability of a product and is not performed the same way that products are built in a production environment. Fittingly, traditional accounting separates R & D expenditures from the daily operations that generate revenue. Writing software doesn't work well in any of those old business-accounting categories. Now, you might discount this little terminology mismatch as a minor quibble for bean-counters with green eyeshades to debate over beers, but it actually has a huge effect on how software is funded, managed, and most significantly regarded by senior executives. Programmers create software, and business executives create revenue streams and profit centers. Programmers measure their success by the quality of the product, and business executives measure their success by the profitability of their investments. They measure this profitability by applying the language of business mathematics, which recognizes fixed costs, variable costs, corporate overhead, and research and development, but, unfortunately, it has no model appropriate for software or programming. Accounting is the basic language of business, and these categories are so fundamental to all business measurement and communication that contemporary executives have completely internalized them. They see programming as simply another corporate expense to be fitted into an already existing category. In practice, most executives simply treat programming as a manufacturing effort a variable cost. (For tax purposes, most software companies account for programming as R & D, but it is regarded as a variable cost in every other respect.) This is the worst possible choice because it hopelessly prejudices their business decision making. The key advantage of the industrial age was that products could be mass-produced, which means they could be made available to the masses at affordable prices. The advantage to customers was the availability of functions that were previously unavailable or only expensively hand built for the wealthy. Companies competed on the basis of their sales prices, which were directly related to their variable costs: the cost of manufacturing and shipping. In the information age, it is taken for granted that products are available at affordable prices to everyone. After all, software can be downloaded and distributed to any number 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's quality, which increases its pricing strength, or it can reduce its variable cost, which means decreasing the cost of manufacturing. In the old manufacturing economy of atoms, reducing costs was simple and effective, and it was the preferred tactic. When today's executives regard programming the same as manufacturing, they imagine that reducing the cost of programming is similarly simple and effective. Unfortunately, those rules don't apply anymore. Because software has relatively insignificant variable costs, there is little business advantage to be had in reducing them. Programmers' salaries appear to be a variable 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 the same as reducing the cost of manufacturing. It's more like giving cheap tools to your workers than it is like giving the workers smaller paychecks. The companies that are shipping programming jobs overseas in order to pay reduced salaries are missing the point entirely. What's more, the only available economic upside comes from making your product or service more desirable by improving its quality, and you can't do that by reducing the money you spend designing or programming it. In fact, you need to invest more time and money on the research, thinking, planning, and designing phase to make your results better suited to your customers' needs. Of course, this requires a mode of thinking that is quite unfamiliar to twenty-first century 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 of the real new economy and precisely what Peter Drucker was talking about. Modern pharmaceutical companies inventing high-tech drugs share some similarities to the new software economy. The actual manufacturing cost of a single pill is miniscule, but the development costs can run to billions of dollars over a decade 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 been developed completely. Pharmaceuticals know that reducing development costs is not a viable business strategy. Like inventing medicine, building software isn't the same as building a factory. The factory is a physical asset that a company owns, and the factory workers are largely interchangeable. The intangible but extremely complicated patterns of thought that is software has value only when accompanied by the programmers who wrote it. No company can treat programmers the same as a factory. Programmers demand 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 behavior is described is the part of the software-construction process that is most frequently dispensed with as a cost-saving measure. It is certainly possible to do too much design, but there is no advantage in reducing it. Every dollar or hour spent on architecture will yield tenfold savings during programming. Additionally, when you invest a sufficient amount of competent design, your product becomes very desirable, which means that it will make more money for you. Its desirability will establish your brand, increase your ability to raise prices, generate customer loyalty, and give your product a longer, stronger lifespan. Although there's no advantage in cost reduction, there is big advantage in quality enhancement. Ironically, the best way to increase profitability in the information age is to spend more. Unfortunately, most executives have an almost irresistible desire to reduce the time and money invested in programming. They see, incorrectly, the obsolete advantage in reducing costs. What they don't see is that reduction in investment in programming has strong negative effects on a product's long-term quality, desirability, and therefore profitability. Of course, simply spending more money doesn't guarantee improvement, and it can often make things worse when additional money is unaccompanied by wisdom, analysis, and guidance. My first mentor, 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." Proceeding without 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 managers with 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 model consisted of the reduction of variable costs. Although many dot-coms claimed various online advantages, their Web sites were sufficiently ponderous and unhelpful to be far less satisfying than simply driving to the mall. Dot-com founders swooned with ecstasy (as did the press) because they could establish a retail enterprise for a remarkably lower variable cost. Their complete and spectacular failure demonstrated beyond doubt that the economic rules of the information age are different from those of the industrial age. In the old economy, lower variable costs meant wider distribution and lower retail costs. Those twin advantages directly benefited the consumer, and they are the foundation for the economic success of the industrial revolution. In the new economy, business success depends on adding something new and better for the consumer. The actual quality of every part of the transaction, from browsing to comparison shopping to comprehensiveness, must be noticeably better for the end user. Wading through 11 screens only to have to telephone the company anyway is far less satisfying than making the purchase conventionally. Entering your name, address, and credit card information three or four times, only to find that the site can't sell you everything you need and a trip to the atom-based store is necessary anyway, has the unfortunate effect of making the entire online sale completely unnecessary and undesirable. Today, simply lowering costs for the vendor doesn't guarantee success. 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 local brick-and-mortar pet store; it didn't offer any better information, intelligence, or confidence. All it offered was cheaper shipping, stocking, and selling variable costs all for Pets.com. It was a classic industrial-age-economy tactic of cost reduction that ignored the fundamental principles of the new economy. Far from being 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 profitably and successfully. The trick is that your online store must offer a measurably greater degree of shopper satisfaction than any competing retail medium, and price is only one small component of satisfaction. There is only one way to accomplish this: You must architect your system to deliver the highest possible end-user satisfaction. Treating any aspect of software design and construction as if it were a manufacturing process courts failure. The design and programming of software is simply not a viable target for conventional cost-reduction methods. It's certainly possible to spend too much time and money on building software, but the danger of spending too little is far greater. Such danger is probably not shocking or unfamiliar to you, but it is nearly inconceivable to most senior business executives who are responsible for running big companies. Those execs are still using accounting models popular in the age of steam, yet every aspect of their companies is fully dependent on software for operations, decision making, communications, and finance. The terms and concepts those executives use are simply not cognizant of the unique nature of doing business in an era when the tools and products of commerce are intangible arrangements of bits instead of railroad carloads of iron. The sock puppets were cool, though. Even though corporations are hiring interaction designers and applying goal-directed methods, the quality of our software products hasn't actually improved that much. What's more, the high cost of programming and the basic intractability of the software-construction process remain ever-present. Why? Change is impossible until senior business executives realize that software problems are not technical issues, but are significant business issues. Our problems will remain unsolved until we change our process and our organization. Not only do companies follow obsolete financial models, but they also follow an inappropriate organizational model. This model is copied directly from academia, where the act of creating software is entangled with the planning and engineering of that software. Such is the nature of research. Tragically, and apparently without notice, this paradigm has been carried over intact into the world of business, where it does not belong. 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 limits on research, student power is dirt cheap, profit is against the rules, and a failing program can be considered a very successful experiment. It's not a coincidence that Microsoft, IBM, Oracle, and other leading software companies reside in "campuses." Universities never have to make money, hit deadlines, or build desirable, useful products. All nonsoftware businesses begin with research and end with mass production and distribution of their products or services. They plan carefully in between, cognizant of the dangers to both bank account and reputation if they attempt premature production of an ill-conceived product. They know that time, thought, and money invested in planning will pay big dividends in the smoothness and speed of manufacturing and the popularity and profitability of their end products. In all other construction disciplines, engineers plan a construction strategy that craftsmen execute. Engineers don't build bridges; ironworkers do. Only in software is the engineer tasked with actually building the product. Only in software is the "ironworker" tasked with determining how the product will be constructed. Only in software are these two tasks performed concurrently instead of sequentially. But companies that build software seem totally unaware of the anomaly. Engineering and construction are so crossbred as to be inseparable and apparently indistinguishable by practitioners or executives. Planning of all sorts is either omitted or delayed until far too late. Profoundly complex technical engineering problems are habitually left unsolved until construction of code intended for public release is well underway, when it is too economically embarrassing to back up. Architecture must be integrated into early-stage engineering planning. In fact, it should drive early-stage engineering, but because such engineering is typically deferred until construction has begun and is corrupted by intermingling with production coding, the architectural design lacks an entry point into the construction process. Despite the fact that companies are hiring interaction designers and retraining their usability testers to create personas, their work has little effect 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 officers. When these execs delegate the solution to their chief technology officers or vice presidents of engineering they miss the point. Those worthy officers are technicians, and the problem is not a technical one. As Drucker pointed out, the accounting tools CEOs depend on simply do not represent the true state of their organizations. It's like saying that because the speedometer is accurate the car is headed in the right direction. In a business world dominated by digital technology, that is simply no longer true. One of the biggest problems of applying incorrect accounting and organizational methods to software construction is that executives don't realize how much of their programming dollar is wasted. An accurate system would show that at least one half of every dollar is misspent and that it takes another two or three dollars to 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 state of blissful ignorance. Over the past 13 years my company, Cooper, has consulted with hundreds of companies. My talented designers have provided most of them with blueprints for products that would help them enormously, yet only a handful have been able to take full advantage of them. Most of them treat interaction design and software architecture as advice, and their programmers and engineers always have the last word. None of those companies' CEOs has any clue as to what is really going on in the engineers' cubicles, so they squeeze the schedule without reason. The programmers are always working in an environment of scarcity, primarily lacking time to program well, but also lacking the time to determine what should be programmed at all. They are forced to protect themselves by rejecting advice and prevaricating to their managers. I believe that there are two kinds of executives: those who are engineers, and those who are terrified of engineers. The former propagate the familiar problems because their viewpoint is hopelessly blinkered by a conflict of interest. The latter propagate them because they cannot speak the language of programmers. I don't mean Java or C#. I mean that business people and programmers lack common tools and common goals. Homo sapiens delegate human problems to Homo logicus and are unaware that the solution could be so much better if they applied at the executive level appropriate financial and organizational models instead. There is a colossal opportunity for companies to break this logjam and organize around customer satisfaction instead of around software, around personas instead of around technology, around profit instead of around programmers. I eagerly await the enlightened executive who seizes this chance and forever alters the way software is built by providing the industry with a bold and successful example.
Alan Cooper |
EAN: N/A
Pages: 170