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

Re: Role of UCD in agile processes

Expand Messages
  • Ron Vutpakdi
    ... horror stories that get all the ... I disgree. The goals may be in alignment, but, there are often enough times ( which aren t edge case horror stories)
    Message 1 of 17 , Jan 27, 2005
    • 0 Attachment
      --- In agile-usability@yahoogroups.com, Gary F <gfyho@y...> wrote:
      > > The customer and the user aren't the same thing. The
      > > customer is the fellow buying the system, but the user is the poor
      > > sucker who has to use it, and the two often aren't the same person.
      >
      > What you're saying it perfectly true, but not withstanding the
      horror stories that get all the
      > attention, in reality the goals are in alignment.

      I disgree. The goals may be in alignment, but, there are often enough
      times ( which aren't edge case horror stories) when the two groups'
      goals aren't in alignment that there are benefits to being precise
      about the terms (if only internally within the team).

      For example, one of our "customers" at one of our biggest clients is
      an expert user who has a marked tendency to demand lots of knobs to
      tweak algorithmic parameters and the inclusion of his
      algorithms/models in spite of the fact that those knobs and algorithms
      would only be of likely interest to him and the other 2-5% of the
      eventual users. The remaining 95-97% would be quite happy without the
      knobs if it meant a simpler, cleaner interface (since they wouldn't
      use the knobs anyway).

      Yes, there are times when the terms can be interchangeable, but also
      often enough times when doing so without consideration is unwise.

      >
      > The important points here are that one needs to be alert to the
      different usages of the terms when
      > communicating with people outside your group, and in particular, one
      needs to examine specific
      > skills when hiring a usability person. "Interaction designer"
      usually isn't ambiguous, but
      > "usability person" usually is.

      I agree that term usage has to take into consideration the audience
      (language usability? ;-). Tell a group of developers or typical
      management that you're bringing in a usability specialist and a
      usability person, no problem and quite appropriate. Address a meeting
      of visual designers or interaction designers as "usability
      specialists," and you've just started on the wrong foot.

      Part of the reason that I bring up this point is that I'm on an
      interaction design list where threads concerning usability folks come
      up every few months which quickly degenerate into "usability folks
      don't know design and shouldn't be allowed to do design" at best and
      "usability folks are completely useless idiots" at worst.

      Ron
    • Gary Macomber
      Hi, Was just reflecting on this after the past week. For the first time in my career I had to convince folks to let me do more than just design. It took me 2
      Message 2 of 17 , Jan 29, 2005
      • 0 Attachment
        Hi,

        Was just reflecting on this after the past week. For
        the first time in my career I had to convince folks to
        let me do more than just design. It took me 2 days to
        get everyone to agree that usability testing was
        important! My prior experience is more like what Hugh
        describes though...

        gary

        --- Hugh Beyer <beyer@...> 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. Presumably, you're
        there to help implement
        the customer role--be the customer voice on the team.
        But that's going to
        require that you behave not as a usability person,
        looking at a completed
        design and searching for holes but that you operate as
        a
        designer--conceptualizing the work of the users,
        thinking about a design
        response and organizing that response into screens and
        interfaces.

        Usability people have known from just about day one
        that they had to do such
        things, of course. But the placement of usability
        after development produces
        something to test meant that the problem was somewhat
        hidden. Now it's out
        front--you aren't a usability person anymore, you're
        something else.

        Or am I out to lunch?

        Hugh



        Hugh R. Beyer
        CTO, InContext
        2352 Main St., suite 302
        Concord, MA 01742

        978-823-0105 x122
        beyer@...






        ---------------------------------
        Yahoo! Groups Links

        To visit your group on the web, go to:
        http://groups.yahoo.com/group/agile-usability/

        To unsubscribe from this group, send an email to:
        agile-usability-unsubscribe@yahoogroups.com

        Your use of Yahoo! Groups is subject to the Yahoo!
        Terms of Service.
      • Hugh Beyer
        _____ From: Ron Vutpakdi [mailto:vutpakdi@acm.org] Sent: Wednesday, January 26, 2005 3:54 PM To: agile-usability@yahoogroups.com Subject: [agile-usability] Re:
        Message 3 of 17 , Jan 30, 2005
        • 0 Attachment

           

           


          From: Ron Vutpakdi [mailto:vutpakdi@...]
          Sent: Wednesday, January 26, 2005 3:54 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:
          >
          > What got me was realizing that as soon as you become part of an agile
          > customer team, you're really not a usability person at all anymore. Your
          > training may well give you a powerful mindset, but your role is to
          be the
          > customer voice.

          Possibly being a little nitpicky here, but I don't agree that a
          "usability person" should have the role of being the "customer's
          voice."  The customer and the user aren't the same thing.  The
          customer is the fellow buying the system, but the user is the poor
          sucker who has to use it, and the two often aren't the same person.
          The "usability person" has to know about the customer and her
          needs/position/motivation, but the user is the one the "usability
          person" represents.

           

          No argument on content. I’m using “customer” in the Total Quality sense of everyone who depends on the system—direct and indirect users, buyers, etc.

           

          Hugh

           

        • 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 4 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 5 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.