Sign up to get our featured articles delivered straight to your inbox every month or two.
RSS feed of all articles
Alan Cooper
Why I read my speech at Agile08
Some attendees at the recent Agile08 conference were put off when it appeared that I was reading my speech rather than delivering it offhand. (If you're interested, you can find my slides and speakers notes here.)
It’s true; I was reading my speech.
When I speak to groups of interaction designers or business people I often address them extemporaneously. It’s a style I enjoy very much and feel that I can do well.
However, the Agile08 audience demanded special treatment. Not only was it large, but it consisted primarily of programmers, agile coaches, and product managers. These professionals are bright, knowledgeable, critical, and opinionated. They do not suffer fools lightly. I was coming to them as something of an outsider; not having programmed for a living for years, and never having programmed in a canonically agile shop.
Alan's keynote at Agile 2008
I was asked by the leadership of the Agile 2008 Conference to give the closing keynote address at their annual conference in Toronto. The audience at Agile08 consisted of about 1500 programmers, engineers, product managers, and others involved in the creation and deployment of software primarily using Agile methods.
My belief in the value of detailed written design has often led enthusiasts of Agile to assume that I am an adherent of the obsolete, and justly maligned, waterfall method of software construction. I was pleased to have this opportunity to state my position with clarity and precision, not to mention making the case for effective collaboration between interaction designers and Agile programmers.
Here are the slides and accompanying speaker's notes for my talk. Some in the audience noticed that I was reading from my notes during the presentation. If you're interested in why I chose to do this, read this Journal entry.
If you would like to discuss this presentation with me, either post a comment to the Cooper Journal blog or email me directly at alan@cooper.com.
Whither interaction design consulting firms?
Is interaction design done by consultants or employees?
When Cooper was launched as an interaction design consulting firm in 1992, the answer to this question wasn't at all clear. However, as the 90s drew to a close, I confidently predicted that the bulk of the interaction design done in the world would be done by consultants. I based this conclusion on the proliferation and success of interaction design consulting firms. I assumed that the industry would follow the model of building architecture, where major design projects are typically performed by outside consultants. Architects on corporate staff would act primarily as liaison and project management. And for the first few years of the 21st century my prediction appeared correct. Today, I wonder if I called it wrong.
More and more I see corporations both large and small with their own in-house interaction design staffers. In fact, in a broad sense, my company competes with our own clients for qualified designers. There are still many successful interaction design consulting firms, but I see an ever increasing number of design projects handled completely by internal design talent, and successfully at that.
This, of course, brings up the thoughtful question of "Whither interaction design consulting firms?" What will their role be in the next decade? Will the pendulum swing the other way, and clients find that it is less expensive to hire designers on a project-only basis instead of keeping them on staff full time? Or will the consultants find themselves working only on fringe projects that are too large, too small, too complex, or too unique?
I don't yet know the answer to these questions, but I'm leaning towards the idea of an ever-more specialized role for interaction design consultancies. What do you think?
Design engineering: the next step
Software construction is slow, costly, and unpredictable.
Slow is a big problem because markets and technologies are always in rapid flux and our ability to maintain pace is critical to our competitiveness.
Costly haunts business people because every precious dollar spent on software design and construction is typically a dollar that is difficult—if not impossible—to directly attribute to a measurable benefit.
Unpredictable is by far the nastiest of these three horsemen of the software apocalypse. Unpredictable means 1) you don't know what you are going to get; and 2) you won't get what you want. In badness, slow and costly pale in comparison to unpredictable. While well-tempered business people are loath to part with either time or money unnecessarily, exchanging time and money for an asset that generates an offsetting future flow of revenue is the essence of business, and "slow" and "costly" are relative terms. If something costs millions and takes years it can still be considered excellent business if the return is tens of millions annually over dozens of years. However, exchanging time and money for something that doesn't generate an appropriate flow of revenue is bad. Very bad.
About Face 3: Foreword
The industrial age is over. Manufacturing, the primary economic driver of the past 175 years, no longer dominates. While manufacturing is bigger than ever, it has lost its leadership to digital technology, and software now dominates our economy. We have moved from atoms to bits. We are now in the postindustrial age.
More and more products have software in them. My stove has a microchip in it to manage the lights, fan, and oven temperature. When the deliveryman has me sign for a package, it's on a computer, not a pad of paper. When I shop for a car, I am really shopping for a navigation system.
More and more businesses are utterly dependent on software, and not just the obvious ones like Amazon.com and Microsoft. Thousands of companies of all sizes that provide products and services across the spectrum of commerce use software in every facet of their operations, management, planning, and sales. The back-office systems that run big companies are all software systems. Hiring and human resource management, investment and arbitrage, purchasing and supply chain management, point-of-sale, operations, and decision support are all pure software systems these days. And the Web dominates all sales and marketing. Live humans are no longer the front line of businesses. Software plays that role instead. Vendors, customers, colleagues, and employees all communicate with companies via software or software-mediated paths.
2nd Edition Foreword Excerpt: The Inmates are Running the Asylum
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.
The Origin of Personas
The Inmates Are Running the Asylum, published in 1998, introduced the use of personas as a practical interaction design tool. Based on the single-chapter discussion in that book, personas rapidly gained popularity in the software industry due to their unusual power and effectiveness. Had personas been developed in the laboratory, the full story of how they came to be would have been published long ago, but since their use developed over many years in both my practice as a software inventor and architectural consultant and the consulting work of Cooper designers, that is not the case. Since Inmates was published, many people have asked for the history of Cooper personas, and here it is.
In their book, Fire in the Valley, authors Paul Freiberger and Mike Swaine, credit me with writing the “first serious business software for microcomputers” as far back as 1975. Like so much software of the time, it was terribly hard to use, and its real power was in demonstrating that making software easy to use was harder than everyone thought. Despite my commitment to making software more user-friendly, it wasn’t until 1983 and about 15 major business and personal applications later that I began to develop a more effective approach.
A Breath of Fresh Air
When all you have is a hammer, everything looks like a nail. If you have never seen a wrench or a screwdriver you will have a hard time seeing what you need, even once you discover that your hammer does not work very well on bolts or screws. This makes it hard to break away from tools that do not serve you. Under pressure, companies tend to fall back upon what they know, so they often end up trying to solve problems with the same tools that got them into trouble in the first place. When this tactic threatens to choke an organization, we call it "breathing your own exhaust."
Right now, many companies see an opportunity to approach product creation from a fresh perspective. With the frenzied dot-com "business model" no longer a distraction, and the recession apparently easing, these companies are looking for ways to benefit from their painful experiences and create a better crop of products and services. They want to nurture customer loyalty by building products that please their customers, rather than following fads or stacking up long lists of features that no one really wants. Everyone knows pleasing customers is the right thing to do, but how do you really do it?
Navigating isn't fun
The artless Websites created during the Web's infancy were of necessity built only with simple HTML tags, and were forced to divide up their functionality and content into a maze (a web?) of separate pages. This made a navigation scheme an unavoidable component of any Website design, and of course, a clear, visually arresting navigation scheme was better than an obscure or hidden one. But many Web designers have incorrectly deduced from this that users want navigation schemes. Actually, they'd be happy if there were no navigation at all.
Today More Than Ever: The Lost Chapter of The Inmates Are Running the Asylum
Computers and their software participate in every aspect of the precious and delicate relationship between the company and the customer. The typical customer first learns about your product from an email advertisement or a computerized mailing. He visits your website to find out more about it. He buys it from your online store, and you ship it to him by FedEx, where he uses software to track it on his PC. Once delivered, even if your product isn't 100% software, it very likely has some silicon intelligence inside it. When your customer can't figure out how to work it, he calls your company on the telephone (which is itself a computer). The first thing he hears is the stilted and artificial voice of your automated call distribution system, instructing him "for technical assistance, press one now." Finally, the software puts him in contact with a real human, only for him to find that this person-trained by software-is merely echoing instructions from a problem report database software program running on his computer!
The Second-Order Effects of Wireless
Even though "wireless" is the hot buzzword on the lips of every high-technologist, the effects of the technology hold far more interest than does the technology itself.
Wireless freedom is intriguing: It isn't hard to imagine a world of perpetually perambulating people with cell phones clamped to their ears and styli firmly gripped in their fingers doing at the cinema or the next table over at Il Fornaio what they could formerly do only at their desks.
But this flexibility to work where you want is just the first order of change wrought by these new tools. Far more interesting are the second-order effects - those unintended consequences of a new technology which often have a more powerful impact on society than the more obvious first-order changes.
The Iteration Trap
High-tech companies are in a hurry—as well they should be—but many hurt themselves by trying to move products out the door too quickly. I often hear executives repeat homilies like "Ship early, ship often," and "Launch and learn." They assume that there is no penalty for simply slapping something together, shipping it, and then upgrading their product or site in a rapid iteration cycle. Unfortunately, there is a big, hidden cost associated with this tactic.
Rapid development environments like the World Wide Web have promoted the idea of simply iterating many versions of a product or service until something works. Arguably, the Web is in its nascent stage and companies are still experimenting to see what works and what doesn't, yet this should not be an excuse for iteration without planning, nor should "speed to market."
The Perils of Prototyping
Which is harder to change: a program with 1000 lines of code or a 1000 square foot slab of concrete? The concrete is ten inches thick and has steel reinforcing rods criss-crossing within it. Every cubic foot of it weighs almost 100 pounds. The software has almost no physical existence at all. It weighs nothing. It consumes no space. A few microamps and those bits flip from zero to one without a second glance. The answer to my question seems a simple one, doesn't it?
Which is the best medium for designing software: Visual Basic or a sharp pencil and a couple of sheets of paper? Visual Basic is a powerful, flexible integrated development environment. It is on its way to becoming the most widely used language ever. It has won every industry award there is. Paper is not interactive. Paper offers no palette of pre-made controls. It just lays there and you have to do all of the work. The answer to my question seems a simple one, doesn't it?
Email it to us and we may answer it in an upcoming article.