Loading ...
Sorry, an error occurred while loading the content.

99Role of Interaction Designer in Agile Teams, was: usability expert credentials

Expand Messages
  • Arlen Bankston
    Jul 18, 2004
      What is the role of the Interaction Designer (ID) in agile teams? To
      build on the many insightful observations that have come before, I'll
      unload the following opinions:

      THE INTERACTION DESIGNER SHOULD REPRESENT THE USERS
      As several have noted previously [16, 56], there are major differences
      between the XP Customer and an application's Users. Keeping this in
      mind, one can examine the XP system of Developers and Customers and
      see that there is a productive tension between the two; this can be
      multiplied by introducing Users as a third party. Since the full
      continuum of Users rarely enjoy direct representation in a project
      team (even by proxy), someone must advocate for their needs, as does
      the Customer for the business's needs (or their own), and the
      Developers for the system's quality and their own bandwidth. This
      responsibility should lay with the Interaction Designer.

      IDs SHOULD BE GENERALIZING SPECIALISTS
      Jeff earlier divided usability folks into three groups:
      up-front/requirements people, design/implementation people and testing
      people. I would contend that, especially in an agile team, these are
      skills that are applied at various stages of a project, but ones that
      should all be held to some degree by a single person. (A partial
      exception is testing, which is multifaceted and deserves attention
      from several parties, and a separate discussion.) Agile teams need
      the eponymous "generalizing specialist" [Ambler], with core
      proficiencies in interaction and UI design, and strong capabilities in:
      - Business analysis
      - GUI development
      - User observation & analysis
      - Usability testing
      - Graphic design

      I have seen few agile projects that would readily fund more than a
      single individual in this general line of practice, so this is to some
      degree a matter of practicality. However, it is more about the single
      point of responsibility noted above; in order to have a consistent
      shared vision and quality execution throughout an incremental process,
      someone must be singularly focused on the none-too-simple task of
      smoothly integrating all of those changing requirements into the
      broader navigation structure, as well as into the individual screens.
      The mental context switch between interaction/UI design and OO
      development is significant, and asking Developers to manage both will
      inevitably lead to sacrifices on one side or the other.

      THE CUSTOMER NEEDS HELP UNDERSTANDING BUSINESS VALUE
      I believe that the ID provides a vital service to the Customer by
      providing a more objective picture of their User's needs than they
      might otherwise enjoy. This perspective is both an addendum and a
      counterbalance to internal business objectives, as Brian noted
      eloquently in message 16. For example, a Customer might feel that
      they need certain features, but have little true idea of the relative
      value of each; this information can be provided by the application of
      Usage-Centered Design, by ethnographic observation and other means.
      The Customer still has the final word on what they want to do, but now
      they're getting strong opinions from both Developers and Users (via
      the ID) to inform their decisions.

      Some other quickies addressing previous posts:

      * Usability should be cultural, but not solely distributed. Its value
      should be clear to the entire team, and they should collaboratively
      practice and learn it as much as possible. However, diluting the
      responsibility among the team (even with a pinch-hitting UI/usability
      expert) is risky, because the practices are different and complex
      enough that a single owner is generally warranted (IMO). I really
      like Kent's approach in message 30.

      * ID practices generally move to a very different beat than the rest
      of development. This means that they can be done in parallel, yet
      another argument for a dedicated resource (see Mark's message 18).

      * The ID's skills can be useful even in projects with little or no UI,
      as noted in the thread regarding API development. I have been
      involved in several business process redesign efforts, for instance;
      the principles and practices are much the same, and similar to those
      of business analysts.

      OK, I think that's long-winded enough. 'Til next time... ;)

      Arlen Bankston
      Interaction Design Manager | CC Pace | www.ccpace.com
    • Show all 11 messages in this topic