Sprint:The Usual Process Meets the Extreme

From ssc.aspirationtech.org

Contrast the ideal User Centered Design (UCD) Process with eXtreme Usability

User Centered Design ideally follows an ordered process

This list assumes that the output is a website or web application.

1. Needs assessment <li>Who are the users <li>Personas and Scenarios <li>Task Analysis <li>Comparison of competitive products or tools <li>Business requirements documents <li>Reconcile with engineering documents, including functional spec and visual design brief <li>Paper prototyping or other low fidelity version <li>Testing on engineers with paper or other low fidelity version <li>Testing on users with paper or other low fidelity version <li>Review test findings and revise prototype <li>Wireframe or other schematic for front end <li>Code backend </ol> (Steps 8-11 should be repeated as often as possible given the time and budget limits, with increasingly higher fidelity prototypes)
   Evangelizing to developers may have more success with the use (and by implication for FLOSS, development) of specialized tools. E.g. wireframing for drupal.
   The whole process takes several months.
   N.B. It's often the case that in commercial software production many of the steps are completed, but there's some relaxation of the ordering. All agree however that the iteration on design, build, evaluate (with users), reconsider leads to positive outcomes: the software functionality and usability both benefit.
   
   eXtreme Usability might diverge from the ideal in any of several ways
   <li>Skip steps or collapse steps <li>The usability person and the developer might sit side by side for several weeks, and may downplay the writing of documents in favor of building things together <li>The programmer may also be a usability specialist, though these 2 skillsets are not often found together. There is also an argument for 2 perspectives being more likely to create both the usability and the functionality in the product. <li>One or more target users are involved early in the process. How this differs from the practice called "participatory design" is likely in the speed of cycles of review. <li>To what extent does the early adopter represent the prototypical user? They are indeed "real users" and yet they may not represent the full range of user types. Using only their feedback is dangerous if you want your product to be used beyond this tech-savvy audience.
   Lots of questions remain: When is the ideal time in the development cycle to pair a usability professional and a developer? How long is enough to make progress? How can we sustain the eXtreme progress? How can we validate the eXtreme progress?