Interaction08: IxD’s in Savannah; Alan Cooper
Date : 2008 02 09 Category : Tech & Development
AjaxianI’m trying to masquerade as a hip and trendy designer-type today at IxDA’s Interaction08 conference, but I fear my geeky ways will betray my role on the implementation side of the aisle. We know that many Ajaxian readers are designers or interested in created well-designed products. Indeed, Ajax has been about empowering us to create websites that don’t suck. I’ll be blogging various Interaction08 sessions over at my personal blog, and for some sessions I’ll repost them here as well.
In particular, I thought Alan Cooper’s keynote was extremely interesting. It’s a verbose transcript; hope you don’t mind.
===
Robert Reimann kicked off the first (full) day of Interaction08. He started with a charged introduction, telling us that this is the first-ever conference of the IxDA group and represented a major milestone in the emergence of “Interaction Design” as the pre-eminent discipline involved in the creation of digital products.
The energy level in the room is very high–it reminds me of the first Ajax Experience, though enthusiasm is higher here as the IxDA community has been around in various forms for so much longer.
Alan Cooper just took the stage. Alan co-authored “The Inmates are Running the Asylum” (a difficult word to spell, by the way) and has long been an authority in the space. I’ve read much of his work over the years.
Both Robert and now Alan talked about the self-identification of Interaction Designers (Alan: “We’re not prototypers, testers, or eyeball-tracking wonks”); some of the rhetoric sounds like a social movement.
Alan’s first point is that “Best-to-market trumps first-to-market”, offering as examples:
- an ergonomic peeler versus a dinky metal peeler
- some clunky MP3 player versus the iPod
- AltaVista versus Google
Good design–innovative products–creates loyalty and enthusiasm in users that overcomes the advantages of first-movers.
If best-to-market is so important, why is “first-to-market” deemed so important by business people?
I don’t think we ought to be emphasizing innovation; in our industry, it will happen. Innovation means invention, but in the minds of business people, I believe it has come to mean “success”. But innovation doesn’t mean success (holds up that original clunky MP3 player that failed–”this was innovative, but was never successful”).
It’s design that leads to success, not first-to-market. Business people accept the need for design, but don’t understand its importance. Business people who rush to market and then innovative in subsequent versions–that’s hellishly expensive.
Business people don’t often do best-to-market because they don’t know how–we need to show them. Many have industrial age skills. They view software as mass production. Best-to-market only happens through craftsmanship. It’s all about quality–it’s all about getting it right, not to get it fast. It’s measured by quality, not speed. It’s a pure measurement, and a delightful one. Craftsmen do it over and over again until they get it right. In their training, they building things over and over so they get the experience they need to get it right.
Craftsmanship predates the industrial revolution. Only the wealthy could afford such finely crafted good. With the industrial revolution, goods came to the masses. We made the trade-off between quality and economy. We can’t all have a high-end piece of furniture, but we can all have a sofa.
Programming is not an industrial activity. It is a unique activity that has a lot in common with pre-industrial craft, and yet has a lot of unique characteristics that I call “post-industrial craft”. Programs are made one at a time, and each piece is different. It’s not scalable and it’s not formulaic. There’s no magic bullet in pre-industrial craft. We can’t say we’re all going agile and everything will come up roses. It’s incredibly nuanced and takes years of study to get right.
Post-industrial craft is similar but different. It is filled with innovation, unlike pre-industrial craft. Post-industrial craft software has massive interaction between parts and its abstracted notions presented in an abstracted notations. It’s in a perfectly brittle environment–all it takes is one bad instruction and the higher edifice comes crashing down. Software is intangible and inscrutable, as are the people that build it.
Programmers are draftsmen. However, they are different than pre-industrial workers. They are self-directed and know better than managers what to do. They respect intelligence, not authority. You can’t tell them what to do, you can only coerce them. Their satisfaction comes from the quality of their work. Unlike pre-industrial craftsmen, post-industrial craftsmen are smarter and more highly trained, even in the higher levels of management where they work.
This creates a conflict because management is industrial. It’s based on command-and-control. It’s tracked quantitatively through cost accounting, based on the idea that you purchase raw materials and you purchase labor that transforms those materials into offerings, and you scale up with factories, and that’s how you profit. That simply doesn’t exist in the world of software.
The well-tempered executive of the industrial age achieved cost reduction through efficiency, but there’s very little notion of that in craftsmanship when your objective is quality.
Building software is not some little detail of how many companies goods are produced–it is the core of the company.
In the industrial age, behavior was a by-product of functionality; in the post-industrial age functionality is a by-product of behavior.
Quote from a third-party: “Programmers cannot be managed, only facilitated.” But industrial-age management is based on control, not facilitation. Paul Glenn, the source of the quote, talks at length about how emasculating this is to programmers. According to Paul, geeks approach their job as a problem/solution scenario. They break it down into problems that can be solved. But facilitation doesn’t involve problems that can be solved, it’s a process (like, “How can I get along with my wife?”). Industrial age managers have a hard time with facilitation, and so do programmers for that matter.
When you have a clash of cultures, it gives rise to zero-sum tactics–fighting for resources. Time and money are not scare, but we are confronted with the scarcity of time and money. It’s just the apportion and it creates an apparent scarcity.
When you put people under extreme pressure, you get a wasteful culture of fighting and racing to market because of some false scarcity of time. The iPhone took plenty of time and come into a mature marketplace. I think of it as the South American dirt farmer who sets fire to hundreds aces of old-growth forest who clears soil for his crops for a few seasons, makes the soil barren, and then repeats it.
Business people often rush to market with crap, and when it fails, they walk away saying, “Well there wasn’t a market for that.”
With the slash-and-burn business culture, there’s this search for innovation, for some magic bullet. Innovation simply does not get it for you. The question is, “Why can’t business people work with post-industrial craftsmen?” It’s because management science simply lacks post-industrial tools. We have cost accounting for managing factories, and so management starts to wonder how they can reduce the cost of programmers.
But there are no economies of scale is software production, all you can do is reduce the quality that emerges. There are simply no good management tools for software construction. There are no appropriate tools for accounting for the creation of software. There’s no way to track any given feature, functionality, or behavior to the amount of money coming.
You hear all this talk about ROI; when a business person talks to me about ROI, I say, “I’m happy to do an ROI calculation if you tell me how to do it.” No one has ever given me a useful answer; there are no good tools for directing or facilitating programmers from the management side. So management tends to find a product manager or vice president who speaks business but can hang with the programming guys and delegates to them, not realizing by the way that they’ve delegated the heart of the business to someone whose goals are not the same as theirs.
So we have this industrial age managers and this culture of builders that are trying to achieve goals that may not be relevant to the goals of business. It’s time for us to fix this problem. We need to create an insurgency–a bottom-up solution to this problem.
Both of these constituencies need our help. We need to stop asking for permission and resources and show them how to achieve to seek success. We are an insurgent cadre of revolution.
Why us? Because programmers don’t respect authority, they respect competence. We are competent! We are just as rigorous as programmers, and we understand the technology as well as they do. We understand business as well. We are the ones who can faciltiate software engineering and construction as crafts.
We can facilitate programmers to practice the joy of craft. They can try over and over again to get it right.
To assume the facilitation role we need three things:
- a plan
- visibility
- confidence
We produce the plan from our work that we do on a daily basis: a written plan based on real research based on personas. When asked by management, “Why did you make this decision?” We need to track all decisions back to real research. Take it back to some kind of rigorous objective thinking, which is what those programmers will respect.
The thing about the plan is that it provides visibility. It provides a plan of “What Done Is”. The only way to track the progress of a construction progress is to track how the building is going against a plan. A list of features and a deadline simply don’t do that. You can’t take a list of features and call it a product description, just as you can’t take a collection of organs and limbs and create life.
With a complete and rigorous definition of behavior, you have something that can be understood and committed to by programmers. They understand narratives, and they can see your personas and buy into it, saying, “I get it.” Business people can see this and get visibility into the process.
Confidence comes from having done it before. This part of the job of programmers is hopelessly confused and confounded.
Frederick Brooks, the great sage of building high-tech systems, wrote in the Mythical Man-Month about how you build one to throw it away. I think it’s a very important concept; it’s come to be accepted in the programming community that you need to build a first to throw it away.
I’d like to recast that–you should *plan* to throw it away. Instead, you should write smaller pieces that you throw away, but you don’t throw the overall system away. You test your work on smaller pieces of disposable material. This is bringing pre-industrial techniques to our post-industrial technologies.
The dominant paradigm in modern shops is:
- Requirements
- Programming (Do it all)
The emerging two phases of production creation:
- Requirements
- Interaction Design (What?)
- Programming (Do)
This doesn’t work because we throw our pearls before deadline-constrained swine and you can guess what happens.
This is where we need to go:
- Requirements
- Interaction Design (What?)
- Design Engineers (How?)
- Programmers (Build)
[While Cooper uses different terms, he’s really describing the Right role of architects versus developers].
Designers collaborate when they iterate:
- Interaction Design (Goal: correctness; iterate, collaborate)
- Design Engineering (Goal: correctness; iterate, collaborate)
- Production Engineering: (Goal: efficiency; clear plan, skilled execution)
All of these are crafts; they are just different types of crafts. The first two are all about achieving correctness.
Design Engineering looks a lot like agile methods. Agile methods as production design and production are troubled and problematic. But for designers, they are excellent.
Production engineering happens to follow processes like RUP. You want to have everything set out on paper before you go off and do it. The place where agile runs into trouble is where it’s applied to the production side, and RUP runs into trouble when it’s applied to the engineering side.
So, how do we do this? How do we create this insurgency?
The key is to start small. Pick a project that is easy to define, small in scope, and something that you can describe in significant detail before you begin work, so the boundaries of the product are well-known. Something that is not a bet-the-company strategy; someplace where you can work without people constantly pulling the rug out from under you.
Then you enlist programmers: you tell them you will fight for quality if they implement your designs. You can say to them, “I will go to management and fight to get you the resources to determine how much its going to cost and how you are going to accomplish these problems, if when you build it, you will follow my specifications.” I believe programmers have been waiting for someone to make this deal, and I’m convinced management won’t make this deal. You’re giving them what they want: the ability to be great craftsmen.
You need to document your success: failure is an orphan, but success has many fathers. It’s imperative that you describe the status quo so you can demonstrate your success. Management will start coming to you and asking you to repeat your success on other projects.
Managers of course will say, “How much does this cost?” This boggles my mind. I know that this is a question that gets asked a lot, but it just seems absurd to me that someone would think that rushing a bad product to market will somehow be more successful than bringing a quality product to market. I always say, “Well, how much did it cost to build [crap MP3 player] versus the iPod?” I doubt there was a significant difference.
All of the increased cost will come to you from savings in the production stage, even though there’s a different allocation of resources. What you’ll wind up with is a successful product you can build on for the long term, such as the iPod versus the Archos Jukebox. You don’t find yourself with a commitment to an ill-conceived strategy.
The most expensive thing in business is opportunity cost, which is the cost of what you didn’t do while you were busy doing whatever you did do. Thus, it’s double or triple as expensive to rush a crap product to market. There’s no group of consumers waiting for you to ship your bad product to market.
We need to step forward and create this insurgency. Don’t ask for permission; let’s build this insurgency in partnership with the programming community. Let’s tell them that we’ll give them the freedom to create what they want, and they’ll sense the value, and join with us.
We’re the ones who can do this. Business people keep retreating into their industrial-age thinking, of cutting costs and outsourcing. When should we do this? Now.
Q&A
Q: A lot of your examples deal with the commercial marketplace: products sold to consumers. A lot of us are stuck in an IT department building products for internal use. How do you reposition that message so that it works well for IT?
Coop: That is an artificial distinction. The issue here is that there are human beings who are using our products. Some of those human beings pay for the privilege of using our products, and some are paid to use our products. IT has chosen to work in an arena where people are paid to use our products, and its amazing how that covers up a lot of interaction design sin. There’s no doubt in my mind that every single org. out there that is selling IT products–the Oracles and SAPs of the world–if they could, they would be selling into a consumer marketplace.
The other thing is that while real people will use your really bad product because they are paid to use it, if it is a good product with decent behavior, productivity will climb. You can walk into any org and spot the SAP users–they are crying in a corner. You can’t tell me that that’s good for business. I don’t buy that. It’s a classic example of an industrial age retreat away from the acceptance that we are in a post-industrial age.
Q: In your different schema of the current paradigm and the where we need to be paradigm, you talk about the Why and the How. Can you talk more about the “Why?” of a product design?
Coop: “We are not very important because we don’t cut code.” (A boo and hiss from the audience.) In the world of high-technology, if you cut code, you control things. It’s the power to destroy the spice, it’s the power to control the spice. It’s not a fine kind of control: it’s bruce-force kind of things. We’re largely marginalized. We’re constantly asking for permission from the folks who shouldn’t be in a position to grant permission. We should be working with business folks and marshaling the technology to meet the solutions to business problems.
But when it comes time to marshal the solution to the problems, we find ourselves slamming into this kind of Stay-Puff Marshmallow Man of software development. I don’t call it development because programmers never ship things on time! I believe in blueprint-based construction. Developers say you can’t do that because requirements always change. I say if you don’t plan you can’t measure how the requirements are changing!
That’s why I believe in the Design Engineering phase: they go through the iterations to figure out how it’s going to be built. The difference is the in the industrial era, the construction workers were in a different caste that those who figured out how to build the bridge. But in the post-industrial world, programmers are in the same caste. But that doesn’t mean that their goals and responsibilities go out the door.
We don’t need to change interaction design; we need to re-orient organizations to build things right. When we come to programmers and say, “Look at the people I’ve talked to; look at the personas I’ve created” and present them with research, programmers understand that, and that’s how we will influence.
Q: I noticed that your requirements bubble disappeared. What do you think about requirements being replaced by prototypes?
Coop: Bad idea. Prototypes are software. I believe that there’s a role for prototypes in interaction design, but I believe it’s a very small and limited role. It’s primarily done as a narrative, not as software. The risk of doing interaction design in a medium of code is much greater than the benefits yield for you. We as competent craftspeople should be able to communicate with great precision and clarity what we intend the software to do without resorting to code.
Code is a sledgehammer here. Prototypes are code that has not achieved released. Snippets of disposable code are great tools for design engineers, but they don’t play a large role for interaction designers.