Dave Cronin’s new Cooper article, RUP & Goal-Directed Design: Toward a New Development Process is a great look at the intersection of conventional user-centered design practice and systems-focused processes. Although he focuses on the Rational Unified Process, the ideas can be applied to any big software development project, and is helpful in understanding and communicating with developers.
He also hits one of the practices that currently drives me insane, gathering requirements…
One problem in effectively defining high-level requirements up front is that many development organizations understand requirements as something to be “gathered.” This “gathering” activity often manifests itself as customers and users volleying “requirements” emails and phone calls to the help desk, salespeople, and engineers. Often, these are then translated into line items in requirements documents. There is little thought given to reconciling requirements from different sources, and this reconciliation is often done at construction time, which can have all sorts of dire consequences, ranging from confused developers (who rarely have enough information to make educated choices between two apparently reasonable requests) to a confused interface (that is not grounded in a coherent and cohesive product definition) to confused users (who wonder why a function they never use is front-and-center on the screen).
Learning more about RUP recently, I realize I had some of it thrust on me before. Back at Razorfish a friend sneakily introduced aspects of RUP into our usual process while planning Tolerance.org. While activities like rating risks can be done anytime, we broke up the sections of the site into use cases. For many websites this approach wouldn’t work, as sites often need to work as a coherent whole, with changes in one section effecting other sections. In our case the sections differed significantly by subject matter and audience, so it wasn’t too harmful. I’m about to embark on another such situation, we’ll see what happens.