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

RE: [agile-usability] Re: Role of UCD in agile processes

Expand Messages
  • Hugh Beyer
    _____ From: Jeff Patton [mailto:jpatton@acm.org] Sent: Thursday, January 27, 2005 2:57 PM To: agile-usability@yahoogroups.com Subject: [agile-usability] Re:
    Message 1 of 17 , Jan 30, 2005
    • 0 Attachment

       

       


      From: Jeff Patton [mailto:jpatton@...]
      Sent: Thursday, January 27, 2005 2:57 PM
      To: agile-usability@yahoogroups.com
      Subject: [agile-usability] Re: Role of UCD in agile processes

       

      ·        
      --- In agile-usability@yahoogroups.com, "Hugh Beyer" <beyer@i...>
      wrote:
      > Hey guys -- I was reading old notes to this list and had a sudden
      news flash
      > which is maybe obvious to everyone else, but maybe not -- what I
      realized is
      > that being a usability person on an agile product is going to
      require a
      > total change in your thinking.
      ...
      > Now it's out
      > front--you aren't a usability person anymore, you're something else.
      >
      > Or am I out to lunch?

      I regret creating this list with the name agile-usability... I'd just
      came back from the UPA conference last year, and it seemed like most
      folks there were comfortable referring to themselves as usability
      people.  I'm now seeing design - specifically user centered design,
      interaction design, and user interface design as the big hole to be
      plugged, and the activity that the usability people[?] are busy doing
      on agile projects.

      A few weeks ago I put out links to the stuff I'm working on.  One big
      point I'm trying to make is the /when/ you do things on agile
      projects matters alot.  Early discussions about UCD stuff on agile
      projects dealt with the concern that doing design work took too much
      time.  That sort of thinking is wrong IMHO.  I believe it operates
      under the assumption that /all or most of/ the work is done up front -
      so therefore our biggest challenge is figuring out how to do it
      faster.  [I kinda bristled at the title "Rapid Contextual Design" for
      that reason.] 

      It's my experience that UCD /stuff/ by stuff I mean researching,
      modeling, prototyping, testing, doesn't generally take too much
      time.  The agile projects I've been on really do have the time...
      it's the _timing_ that's an issue.  Some research and modeling needs
      to be done ahead of release planning.  Some decisions about workflow
      and navigation structure should be made ahead of iteration planning. 
      UI prototyping should be ahead of storywriting.  UI prototyping
      doesn't need to be all completed before any code is written. 
      Navigation and workflow can change a bit at each iteration as we
      learn more and functionality is added or changed.  Models and
      features can change periodically during and after releases as we get
      feedback from using and testing the software we're building. 

      Basically, do all the same UCD stuff - just synchronize it with your
      agile lifecycle.

      And, Hugh - to where your original comments were going, I see UCD
      people as designers working in step with development, coaching
      customers, developers, and business people.  The usability thing is a
      part of that that usually comes a bit later.  And as to your change
      in thinking comment - I find that whole projects become user
      centered.  This sort of thinking permeates every activity.  Does that
      square with your observations on your current projects?

      My favorite story about this... on a project some years ago, we were working with a customer/UI design/user experience design team that interfaced with a development team in a very XP-ish kind of way, though it was not an XP project. After some time—enough time for everyone to get comfortable with the new roles—one of the developers on the user team came to us and said he was planning to go back to development. We were all worried and asked what was wrong and why he wasn’t happy. His response was, “I’m very happy but I like developing. Now that I’ve seen what you’re doing I know I can trust your process. So if you come and tell me to paint it purple, I’ll paint it purple because I’ll know you have a good reason for it.”

      Moral being that the whole team may become user-centered in attitude—but part of that is knowing when to listen to the parts of the team that are more in contact with the user than you are. This is being duplicated in teams we’re working with now—the developers are getting to the point where they prefer to come to our folks rather than make off-the-cuff design decisions because they know we’ve got the closer user contact. Which—to bring the conversation back to XP—is as it should be.

                  Hugh

    • Jeff Patton
      ... were working ... interfaced with a ... XP ... comfortable with ... said he ... asked what ... happy but I ... trust ... paint it ... attitude-but ... that
      Message 2 of 17 , Feb 1, 2005
      • 0 Attachment
        --- In agile-usability@yahoogroups.com, "Hugh Beyer" <beyer@i...>
        wrote:
        > My favorite story about this... on a project some years ago, we
        were working
        > with a customer/UI design/user experience design team that
        interfaced with a
        > development team in a very XP-ish kind of way, though it was not an
        XP
        > project. After some time-enough time for everyone to get
        comfortable with
        > the new roles-one of the developers on the user team came to us and
        said he
        > was planning to go back to development. We were all worried and
        asked what
        > was wrong and why he wasn't happy. His response was, "I'm very
        happy but I
        > like developing. Now that I've seen what you're doing I know I can
        trust
        > your process. So if you come and tell me to paint it purple, I'll
        paint it
        > purple because I'll know you have a good reason for it."
        >
        > Moral being that the whole team may become user-centered in
        attitude-but
        > part of that is knowing when to listen to the parts of the team
        that are
        > more in contact with the user than you are. This is being
        duplicated in
        > teams we're working with now-the developers are getting to the
        point where
        > they prefer to come to our folks rather than make off-the-cuff
        design
        > decisions because they know we've got the closer user contact.
        Which-to
        > bring the conversation back to XP-is as it should be.
        >

        I've seen that play out as well - sort of. By injecting teams with
        user profiles and task models - UCD artifacts and thinking, and
        publicly using those to make design decisions developers [and
        analysts and users] learn that design decisions aren't really made
        off the cuff. They're informed decisions. I observe two resulting
        behaviors: as you describe, developers and others trust the design
        process more and seek out designers for specific advice; or,
        alternatively, developers and others use the models to start making
        some informed decisions on their own.

        I've always been pushing for developers and others to gain that
        understanding so they can make day to day decisions on their own -
        and indeed some do. But more of them choose to defer to designers.
        Possibly my hopes at everyone becoming a designer to some degree are
        unrealistic.

        Have you observed others learning UCD thinking and successfully
        making decisions on their own? Has this helped or hindered things?

        thanks,

        -Jeff
      Your message has been successfully submitted and would be delivered to recipients shortly.