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

Role of UCD in agile processes

Expand Messages
  • Hugh Beyer
    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
    Message 1 of 17 , Jan 21, 2005
    View Source
    • 0 Attachment
      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@...
    • Ron Vutpakdi
      ... do such ... produces ... it s out ... It all depends what you mean by usability person. To some, a usability person is just the really annoying person who
      Message 2 of 17 , Jan 21, 2005
      View Source
      • 0 Attachment
        --- In agile-usability@yahoogroups.com, "Hugh Beyer" <beyer@i...> wrote:
        > 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.

        It all depends what you mean by usability person.

        To some, a usability person is just the really annoying person who
        comes in after development is done (or almost done), runs some tests,
        and then shakes his finger at you saying that you need to change this,
        this and that when it's too late to do so.

        Often times, the placement of usability after development is a result
        of the management team and possibly the development team who naively
        just want some to come in and "do usability" without understanding
        what that really means.

        In my view, a usability person should be involved throughout the
        process. Ideally, the usability person should be a key participant in
        the initial formulation of a project, starting with helping to collect
        initial data from users and then helping to formulate a complete
        solution (including an interaction design).

        What usability folks really do and how they are seen can dramatically
        vary from person to person. Some really do concentrate solely on the
        late end testing. Some primarily work early in the process
        (ethnographic research and/or interaction design). Others work
        throughout the development process.

        Ron
      • Petteri Hiisilä
        ... Yeah, usability can be at least two things: 1) design and 2) testing. It requires completely different skills and attitude. I can admit that I m a terrible
        Message 3 of 17 , Jan 24, 2005
        View Source
        • 0 Attachment
          > It all depends what you mean by usability person.
          >

          Yeah, usability can be at least two things: 1) design and 2) testing. It
          requires completely different skills and attitude. I can admit that I'm
          a terrible usability tester, but I've had some success in the design
          arena. Most people either suck or are average trying to do both. There
          are some exceptions, but they are so called big stars and may still have
          more reputation than skill :)

          > To some, a usability person is just the really annoying person who
          > comes in after development is done (or almost done), runs some tests,
          > and then shakes his finger at you saying that you need to change this,
          > this and that when it's too late to do so.


          Yeah, the information ice age.

          > In my view, a usability person should be involved throughout the
          > process. Ideally, the usability person should be a key participant in
          > the initial formulation of a project, starting with helping to collect
          > initial data from users and then helping to formulate a complete
          > solution (including an interaction design).
          >

          Your view is shared by, I believe, most people who want to create more
          useful software.

          We involve design people in the team, and usability testing is conducted
          by outsiders. They test our paper prototypes and "dummy" screen shot
          implementations and either approve or disapprove the test. Usually all
          the major problems and tweaks are found with just one usability test
          iteration. This happens before any coding starts, and costs maybe 10-15
          % of the whole budget.

          > What usability folks really do and how they are seen can dramatically
          > vary from person to person. Some really do concentrate solely on the
          > late end testing. Some primarily work early in the process
          > (ethnographic research and/or interaction design). Others work
          > throughout the development process.


          Good observation. I can confirm this from my own experience.

          Best,
          Petteri

          --
          Petteri Hiisilä
          Palveluarkkitehti / Interaction Designer /
          Alma Media Interactive Oy / NWS /
          +358505050123 / petteri.hiisila@...

          "I know what I believe. I will continue to believe
          what I believe and what I believe - I believe what
          I believe is right."

          - George W. Bush
        • Myhill, Carl S (GE Energy)
          Good point. Some of us are starting to call this User Experience Design for that reason. Usability done after the code is written is rarely helpful on that
          Message 4 of 17 , Jan 24, 2005
          View Source
          • 0 Attachment
            Message
            Good point. Some of us are starting to call this 'User Experience Design' for that reason. Usability done after the code is written is rarely helpful on that release of a product. We'd rather get involved at the outset of the project, meet the users, do some design on paper (with developers too) and all that. We're not keen on that after the fact usability stuff!

            Carl
             
            -----Original Message-----
            From: Hugh Beyer [mailto:beyer@...]
            Sent: 21 January 2005 14:09
            To: agile-usability@yahoogroups.com
            Subject: [agile-usability] Role of UCD in agile processes

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




          • Baker, Lisa
            I don t know that you re not a usability person, but, no, you are not out to lunch, Hugh. In our organization, using XP methodology to create a retail
            Message 5 of 17 , Jan 24, 2005
            View Source
            • 0 Attachment

              I don’t know that you’re “not” a usability person, but, no, you are not out to lunch, Hugh.

                In our organization, using XP methodology to create a retail product, the product marketing manager is the “customer voice.” But, as you know, my partnership with them to do the CI and persona development means that the work we’re not just “dialog Nazis” ;-). The work we do as “HFs” or  “usability people” influences the product requirements, and indeed, changes the priorities assigned to different stories in the release plan.

                I am definitely not looking at a complete design… but we have a framework and concept prototypes to show the “big picture,” then deliver prototype pieces for the iteration stories.

                Sometimes, it feels like the “usability” people add work to the developer by saying “this sucks, fix it.”  We’re trying to show them that by adding our work and expertise to the process, we save the developer’s time in completing stories. My basic ideology is it is better to influence up front design than do downstream triage so we’re shifting our limited resources upstream, even though it means we short some usability testing.

                Lisa

               

               

              Lisa Baker

              Interaction Design Lead

              LANDesk Software, Inc.

              Lisa.baker@...

              801.208.1315

               

              "Simplifying our customers' work"

               

               


              From: Hugh Beyer [mailto:beyer@...]
              Sent: Friday, January 21, 2005 7:09 AM
              To: agile-usability@yahoogroups.com
              Subject: [agile-usability] Role of UCD in agile processes

               

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





              This email, and any files or previous email messages included with it, may contain confidential and/or privileged material. If you are not the intended recipient please contact the sender and delete all copies.

            • Baker, Lisa
              On this topic, Dave Broschinsky (my partner here) and I recently made a presentation to the local CHI chapter called Interaction Design in an Agile World,
              Message 6 of 17 , Jan 24, 2005
              View Source
              • 0 Attachment

                On this topic, Dave Broschinsky (my partner here) and I recently made a presentation to the local CHI chapter called “Interaction Design in an Agile World,” discussing what we’re doing to interlace our work with the XP process. We had both NUCHI people and agile developers attend. It seemed to go over well.

                  If you’re interested in seeing the presentation, let me know. If there is enough interest, we can set up a Webex/conference call and do one online. It’d be really fun to do it in person and see everyone, but it seems like we’re too spread out to make that work easily.

                  Thanks.

                  Lisa

                 

                 

                Lisa Baker

                Interaction Design Lead

                LANDesk Software, Inc.

                Lisa.baker@...

                801.208.1315

                 

                "Simplifying our customers' work"

                 

                 


                From: Hugh Beyer [mailto:beyer@...]
                Sent: Friday, January 21, 2005 7:09 AM
                To: agile-usability@yahoogroups.com
                Subject: [agile-usability] Role of UCD in agile processes

                 

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





                This email, and any files or previous email messages included with it, may contain confidential and/or privileged material. If you are not the intended recipient please contact the sender and delete all copies.

              • 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 7 of 17 , Jan 26, 2005
                View Source
                • 0 Attachment
                  --- 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 8 of 17 , Jan 26, 2005
                  View Source
                  • 0 Attachment

                    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 9 of 17 , Jan 26, 2005
                    View Source
                    • 0 Attachment
                      --- 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 10 of 17 , Jan 27, 2005
                      View Source
                      • 0 Attachment
                        --- 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 11 of 17 , Jan 27, 2005
                        View Source
                        • 0 Attachment
                          --- 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 12 of 17 , Jan 27, 2005
                          View Source
                          • 0 Attachment
                            --- 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 13 of 17 , Jan 27, 2005
                            View Source
                            • 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 14 of 17 , Jan 29, 2005
                              View Source
                              • 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 15 of 17 , Jan 30, 2005
                                View Source
                                • 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 16 of 17 , Jan 30, 2005
                                  View Source
                                  • 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 17 of 17 , Feb 1, 2005
                                    View Source
                                    • 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.