UCD Process

Thinking about the UCD process today. Here are some good resources:
Giving people what they want: How to involve users in site design (from IBM)[broken 2/2004, get from archive.org]
Task-Centered User Interface Design: A Practical Introduction (shareware book) Gives me a hint as to what UCD is trying not to be. I’ve been wondering for a while what process UCD replaced. It mentions the waterfall method as one process that was/is prevalent in traditional software development shops.

The basic waterfall method assumes that a piece of software is produced through a clearly defined series of steps, or “phases”:
* Requirements analysis
* Specification
* Planning
* Design
* Implementation
* Integration
* Maintenance

They go on to discuss the initial Requirements Analysis.

The waterfall method’s initial “Requirements Analysis” phase describes the activity of defining the precise needs that the software must meet. These needs are defined in terms of the users and the their environment, with intentionally no reference to how the needs will actually be met by the proposed system.

This is exactly the same approach as we suggest for describing representative tasks: define what the user needs to do, not how it will be done. The difference is that the representative tasks in task-centered design are complete, real, detailed examples of things users actually need to do. The requirements produced by traditional software engineering, on the other hand, are abstract descriptions of parts of those representative tasks.

Some more resources:
User-Centered Design Process (NASA’s Usability Team)
Commentary on Addressing Organizational Obstacles (Richard I. Anderson talks about getting buy-in)
UCD for VoiceXML Applications (Mike Farley, Lucent)
Carbon IQ’s UCD process (If 404, get it from archive.org). I actually received this outline of their process when I took one of Carbon IQ’s excellent workshops. Glad to see it online so I can point others to it.