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

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

Expand Messages
  • Gary F
    ... I m really surprised to see you putting it that way, but perhaps I m missing something. I never perceived contextual design as requiring one start with a
    Message 1 of 17 , Jan 26, 2005
      --- Hugh Beyer <beyer@...> wrote:

      ...
      > 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.

      I'm really surprised to see you putting it that way, but perhaps I'm missing something. I never
      perceived contextual design as requiring one start with a completed design. It often works that
      way because so many projects wait until after they've done an amateur design before bringing in
      professional usability people. Is it just that so many of your clients operate in that mode that
      you've started taking it for granted? Or am I misunderstanding you?

      Gary

      __________________________________________________
      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
      http://mail.yahoo.com
    • Hugh Beyer
      Oops-I think you re misunderstanding me. Contextual Design certainly doesn t expect a completed design-it s often used to generate the product concept. And I
      Message 2 of 17 , Jan 26, 2005

        Oops—I think you’re misunderstanding me. Contextual Design certainly doesn’t expect a completed design—it’s often used to generate the product concept.

         

        And I know that usability people have understood for years that they must be involved up-front in order for their work to have much impact—otherwise you’re just changing the icing on the cake.

         

        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. And that requires a deep understanding of the user’s work practice, of rational design, and also of usability issues. Usability folks who walk into this role without realizing this are likely to be surprised.

         

                    Hugh

         

         


        From: Gary F [mailto:gfyho@...]
        Sent: Wednesday, January 26, 2005 10:47 AM
        To: agile-usability@yahoogroups.com
        Subject: Re: [agile-usability] Role of UCD in agile processes

         


        --- Hugh Beyer < beyer@... > wrote:

        ...
        > 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.

        I'm really surprised to see you putting it that way, but perhaps I'm missing something.  I never
        perceived contextual design as requiring one start with a completed design.  It often works that
        way because so many projects wait until after they've done an amateur design before bringing in
        professional usability people.  Is it just that so many of your clients operate in that mode that
        you've started taking it for granted?  Or am I misunderstanding you?

        Gary

        __________________________________________________
        Do You Yahoo!?
        Tired of spam?  Yahoo! Mail has the best spam protection around
        http://mail.yahoo.com

      • Ron Vutpakdi
        ... be the ... 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
        Message 3 of 17 , Jan 26, 2005
          --- 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.

          Even if the customer and the user are the same person, being the
          "user's voice" is a rather risky proposition. I see usability people
          as user *advocates* who have a deep understanding of the users and
          push for things on their behalf but also know that, in the end, the
          only person who can speak for the user properly is the user himself.
          Thus, the importance of having real users involved in the process if
          possible.

          >And that requires a deep understanding of the user's work
          > practice, of rational design, and also of usability issues.
          Usability folks
          > who walk into this role without realizing this are likely to be
          surprised.

          I believe that most usability folks who are really involved throughout
          the entire process (rather than tacked on at the end), *will* know
          that the need to understand the user's work practice and usability
          issues.

          Whether or not they also need to be good interaction designers depends
          on the person and team make up (more usability and design mature
          organizations usually separate the interaction design and
          usability/human factors roles (and then pair two+ people on the same
          team). Whether or not a "usability person" can be a good interaction
          designer is also in considerable doubt by some very vocal interaction
          designers.

          Ron
        • Gary F
          ... Now I get you. The same is often true for QA people, whether or not the team is agile. I guess I m so used it that I take it for granted. This may seem
          Message 4 of 17 , Jan 27, 2005
            --- Hugh Beyer <beyer@...> 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. And that requires a deep understanding of the user's work

            Now I get you. The same is often true for QA people, whether or not the team is agile. I guess
            I'm so used it that I take it for granted.

            This may seem anomalous to some, but it's not that usability and QA people are usurping the users'
            role. Rather, in the ideal situation, all of the team members should be able to expess the voice
            of the customer. Since few teams are there yet, it is those who are closest to the users who fill
            it most.

            Gary


            __________________________________________________
            Do You Yahoo!?
            Tired of spam? Yahoo! Mail has the best spam protection around
            http://mail.yahoo.com
          • Gary F
            ... 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. No
            Message 5 of 17 , Jan 27, 2005
              --- Ron Vutpakdi <vutpakdi@...> wrote:

              > 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.

              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. No manager wants to be told that his employees
              have become less productive because they can't use the new software. Also, the division is often
              even more complex. A database system has to satisfy the manager funding it, the sysadmin
              installing it, the DBA managing it, the security person auditing it, the developers building
              systems that use it, and the ISVs building tools to help those developers.

              So rather than trying to be totally precise all the time, it's just easier to use whichever of the
              two terms feels right at the time, and only raise this distinction when necessary. I'm not sure
              whether it's necessary on a public forum; I think the concept is well known and doesn't need
              frequent repetition, but I can't back that up.

              >
              > Even if the customer and the user are the same person, being the
              > "user's voice" is a rather risky proposition. I see usability people
              > as user *advocates* who have a deep understanding of the users and

              "User advocate" and "voice of the user" mean the same thing. The term "voice of the user" is
              jargon; a real user on the team is called the user, not the voice of the user.

              > push for things on their behalf but also know that, in the end, the
              > only person who can speak for the user properly is the user himself.
              > Thus, the importance of having real users involved in the process if
              > possible.

              The conclusion is certainly correct, but I don't agree with the premise. Indeed, much of the
              motivation for contextual inquiry is that users aren't very good at observing their own behavior,
              they lack a certain objectivity, and they often lack the vocabulary to express all of their needs
              effectively.

              As far as usability is concerned, both are necessary to get a proper understanding.

              >
              > Whether or not they also need to be good interaction designers depends
              > on the person and team make up (more usability and design mature
              > organizations usually separate the interaction design and
              > usability/human factors roles (and then pair two+ people on the same
              > team). Whether or not a "usability person" can be a good interaction
              > designer is also in considerable doubt by some very vocal interaction
              > designers.

              This may be just semantics, but while many people make this distinction, many others don't.
              Another way of looking at it is that someone who can only do one or the other is a specialist in a
              particular aspect of usability, while someone who can do both is a usability expert. The
              usability team, whether one person or many, does best when both skills are present.

              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.

              Gary



              __________________________________
              Do you Yahoo!?
              Yahoo! Mail - Helps protect you from nasty viruses.
              http://promotions.yahoo.com/new_mail
            • Jeff Patton
              ... news flash ... realized is ... require a ... I regret creating this list with the name agile-usability... I d just came back from the UPA conference last
              Message 6 of 17 , Jan 27, 2005
                --- 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?

                Thanks for your post!

                -Jeff
              • 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 7 of 17 , Jan 27, 2005
                  --- 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 8 of 17 , Jan 29, 2005
                    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 9 of 17 , Jan 30, 2005

                       

                       


                      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 10 of 17 , Jan 30, 2005

                         

                         


                        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 11 of 17 , Feb 1, 2005
                          --- 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.