I read some of the Scott Ambler entries Ambrose listed above. This confirmed rather than contradicted my assertion that the need for specifications is inversely proportional to the degree to which the people writing the code are separated from decisions about design, in a physical distance, process, or organizational sense.
Scott says that when you are "specifying work for another group..." that this is a situation "...where AM likely isn't appropriate." I can't think of a web project that I've worked on since my first web design job in 1995 in Barcelona that there haven't been multiple parties focused on design. There can easily be 3 or 4 large companies involved, perhaps a half dozen smaller companies each with some role in the design. The complete team can be over 100 people, perhaps on multiple continents. I'm not trying to say this scenario is superior or more valuable than the one Scott describes. I'm just saying that this list includes people from different worlds, but the arguments are passionately pretending that there is one right answer and the other people are idiots. No, it's simply that the conditions in which interaction designers find themselves are extremely different and there are multiple right answers. Elsewhere Scott says: "I ask the individual(s) requesting the documents if they also want to be seen as responsible for the project's failure because the development team was too busy focusing on needless documentation and not on building software." This clearly describes a situation where a small team of 10 or 20 people are sitting in a room "doin' software." It doesn't remotely describe the situations I typically find myself in, where developers rarely have any channel of communication back to people who make decisions on the client side. The communications with the client are handled by people who have that as their sole job responsibility. These people, typically client partners or program managers, would certainly throw Scott's backside into the street the next day if he talked that way to a client. But since they are "people people," they would probably be aware that Scott is very talented at what he does, and simply keep him many layers removed from the "design decision dance" that large agencies do with clients. In large web projects, that dance is done primarily on one platform: design documentation. Often long before there is a prototype, depending on the complexity of the architecture and the skills of the team. There will be changes during development, but those changes will be extremely expensive and will have to escalate up through multiple chains of command. Recently I was in a meeting where the whole internal web team was assembled to discuss the progress of an e-commerce project. There were about 60 people in the room from the client side alone. This didn't include business strategy consultants or offshore development resources. We went through the design documentation page by page to be sure everyone knew what they had to produce. That was the first and only "all hands" meeting to my knowledge. It probably cost in the neighborhood of $50,000 to conduct that one set of meetings. The team members didn't later decide on the fly how they were going to shape the product as they went along. They followed the blueprint. Inefficient? Perhaps. But the reason for this separation of labor is that each interactive element in the final product has a direct impact on what millions of people will do when they get to that page. The people informing the decision on that element have a lot of data, quantitative and qualitative, that tells them which element will have the most positive impact, or they know what they need to do to get that data. It's their full-time job. Again, I'm not saying this is in any way superior to small teams doing great things using Agile methodology or creating breakthrough product designs. Being a developer or engineer and having that kind of control over a product is probably very satisfying and efficient. But that is only one of many work contexts populated by interaction designers. About all the Agile references that eschew documentation: I don't have any doubt that top-tier agencies like Sapient, Razorfish, Critical Mass, LBi, Macquarium, or Resource Interactive can make Agile work for the user experience design of large web sites. I'm all for the focus on efficiency, particularly where data gathering and design rationale can occur a cycle or two ahead. But I also think the wholesale adoption of Agile in 2008 and 2009 simply for cost considerations without thinking through the details of user experience impact will lead to many, many exploding cigars in 2010 and 2011, after a few quarters of analytics have a chance to tell the full story. /pb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Posted from the new ixda.org http://www.ixda.org/discuss?post=46833 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... disc...@ixda.org Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
