Thursday, November 30, 2006 2:18:19 PM
Today Robert Scoble links to this technology-out view of Web2.0 applications from Don Dodge. Ross Mayfield (my go-to guy for a more nuanced view of how wikis are influencing business (and vice-versa)) also gives Dodge a mention. I like this quick summary and the basic conclusion. But I want to see the "people-" and "work practice-"in view.
Specifically I'd like to see Dodge's "build it and they will come" view replaced by a user oriented, participatory "let's find out what people are really doing before we build anything" approach. The build it first way definitely has it's place. Who knew we could do so much with a photocopier, or a personal sound device, before we had them? No one. However, I want to look a bit more deeply at the user and participatory practices that run through Web 2.0 visions.
As I mentioned the other day, Tim O'Reilly's What is Web 2.0? paper is mostly about the software. But nestled in there are some ideas about participation among people and a core competency that Web 2.0 companies need to have; viz., "trusting users as co-developers". What, exactly, does that look like? Fortunately, this has been done before, and we can look it up.
Co-development with users has been practiced in Scandanavia and Europe under the name "Participatory Design" (PD) since the 1970's and in the US since the late 1980's. (Computer Professionals for Social Responsibility (CPSR) is a good starting point for learning about PD and linking to PD resources.) PD grew out of sociotechnical systems and action research work in the 1950's and 1960's at the Tavistock Institute in London. Bringing social science to bear on business and management problems was a hallmark of this work. In addition, Kristen Nygaard, the inventor of the Simula object-oriented programming language, was also a major proponent to PD approaches to system development. So this key requirement for business has long roots in both technology and the humanities. Maybe, just maybe, these new internet practices will force us to appreciate the social nature of technology development and use. Maybe our adoption of the new will help us remember and bring forward the parts of the past we can use right now. I hope so.
So we're good with co-developing systems and applications with users. What does it take do this well and to be successful? Joan Greenbaum and Morten Kyng (quoted from this Kuhn and Winograd profile on PD) identify four design techniques that are based on PD:
1. The need for designers to take work practice seriously—to see the current ways that work is done as an evolved solution to a complex work situation that the designer [or programmer] only partially understands.
2. The fact that we are dealing with human actors, rather than cut-and-dried human factors—systems need to deal with users' concerns, treating them as people, rather than as performers of functions in a defined work role.
3. The idea that work tasks must be seen within their context and are therefore situated actions, whose meaning and effectiveness cannot be evaluated in isolation from the context.
4. The recognition that work is fundamentally social, involving extensive cooperation and communication.
Putting these techniques into practice requires an entirely new paradigm of software development (cf., Floyd, Reisin, & Schmidt); one that moves engineers and designers out into the workplace of the potential users, so that they can actually understand what the work entails. This knowledge can enable the development and deployment of systems and tools that really augment the work and enable the discovery of new work.
So, how's it going for "trusting users [the people in the 2.0 world] as co-developers"?.
Well, one thing to say is that more and more anthropologists, sociologists, and ethnographers are getting involved with software development companies (cf.; the anthrodesign e-mail list; interaction design; contextual design). In most cases, these people really are looking at work and work practices. They do still need to translate what they know into information that engineers and programmers can use. And this doesn't get the engineers out, but people who know how to look and how to ask can bring in key product requirements.
On the technology side, agile approaches to software development are facilitating concerted efforts to engage customers (not always the end users) directly with engineers to deliver small solutions quickly, and to refine what's needed through use. Not only is there cooperation; there's a neat division of authority and responsibility. Customers get to say what they want; developers get to say how long it will take. When this works there's lot of discussion and communication about needs and costs. However, customers and users are often represented on the engineering team by a single person. This is better than letting engineers imagine how work is done, but the details and context of the user's work practice is often lost -- it's hard for one person to know everything. Not to mention that when you hang around with engineers you eventually see the world as they do.
And, finally, on the consumer side there is a steady drumbeat (start with The Cluetrain Manifesto) to find ways to talk directly with customers; to get unfiltered feedback about how your product or service is working "in the wild". Here wikis and weblogs, etc., look like great tools. But very often I don't want to have a conversation with my vendor; I just want to buy the digital camera and start taking pictures. This participatory customer / vendor relationship seems like a great idea. But I don't know if it can capture enough of the context of my complaint or need. And I don't know if it can scale. Could conversations between every MS Word user and Microsoft even be supported? Are there enough hours in the day for that?
Even with all the questions I think it will get better for people in the 2.0 world. Definitely! And some bloggers continue to re-enforce that the web is all about people, people. That's good. It's all good.
- Bill
