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

Re: [agile-usability] New poll for agile-usability

Expand Messages
  • Tim Wright
    Not that Robert s post is spam, but I do need to add: - Are all posters to UseNet groups Spammers? I guess the answer is: over time, they tend to be. I wonder
    Message 1 of 22 , May 9, 2007
    • 0 Attachment
      Not that Robert's post is spam, but I do need to add:

      - Are all posters to UseNet groups Spammers?

      I guess the answer is: over time, they tend to be. I wonder if that statement can be generalised.

      Over time, all airline flight crew become test pilots. I guess if they fly enough, they will test new features.
      Over time, regular restaurant-goers become food safety inspectors. I guess if you're eating out regulary, you will pass information to your friends.
      Over time, all home buyers become building inspectors. I just bought a house and if I were to buy another, I would be much more of a building inspector! Also, who takes a friend who has bought a few houses along to check your new place out?

      Now, to generalise to programmers...

      Over time, all programmers become testers (we write unit-tests)
      Over time, all programmers become user-interface gurus (because we get to see people using our product)
      Over time, all programmers ...

      These seem particularly apt in an agile environment - I'm not sure they would work so well in a waterfall organisation.

      Tim

      On 5/8/07, Robert Biddle <Robert_Biddle@...> wrote:

      Jon Kern wrote:
      > re: " How many functionality testers are usability testers?"
      > are not all users (testers not withstanding) usability testers?

      I guess you might say that, but for testers it is the testing that is the primary
      task, and they have both experience and focus on that, with a supporting context.
      I would make the same distinction between users and functionality testers.

      Consider:

      - are all airline flight crew test pilots?
      - are all restaurant diners food-safety inspectors?
      - are all home buyers building inspectors?

      Robt




      --
      Kei te kōrero tiki au. Kei te kōrero tiki koe. Ka kōrero tiki tāua. Kōrero ai tiki tāua.
    • White, Jeff
      True, and I could say that since I ve been eating food for a long time, I m the equal of an executive chef at the world s finest restaurant. As much as I d
      Message 2 of 22 , May 9, 2007
      • 0 Attachment

        True, and I could say that since I’ve been eating food for a long time, I’m the equal of an executive chef at the world’s finest restaurant. As much as I’d like for that to be reality, it’s just not. And, I’m ok with that because I know it’s not my core skill set.

         

        All of Tim’s points have an amount of truth to them. But, people are in different roles for good reasons and in my opinion there’s absolutely nothing wrong with that.

         

        I would never assume a programmers job is easy enough that I can become a java “guru” just because I’ve seen dozens of java developers work on dozens of projects over many years. It would be nice if programmers had the same respect for the complexities of user interface design.

         

        Jeff

        Not that Robert's post is spam, but I do need to add:

        - Are all posters to UseNet groups Spammers?

        I guess the answer is: over time, they tend to be. I wonder if that statement can be generalised.

        Over time, all airline flight crew become test pilots. I guess if they fly enough, they will test new features.
        Over time, regular restaurant-goers become food safety inspectors. I guess if you're eating out regulary, you will pass information to your friends.
        Over time, all home buyers become building inspectors. I just bought a house and if I were to buy another, I would be much more of a building inspector! Also, who takes a friend who has bought a few houses along to check your new place out?

        Now, to generalise to programmers. ..

        Over time, all programmers become testers (we write unit-tests)
        Over time, all programmers become user-interface gurus (because we get to see people using our product)
        Over time, all programmers ...

        These seem particularly apt in an agile environment - I'm not sure they would work so well in a waterfall organisation.

        Tim

        .


      • Robert Biddle
        Hi Tim: I do agree there is a sense in which this is true. But I don t think it s helpful. People who use things often cope, but don t work to improve things.
        Message 3 of 22 , May 9, 2007
        • 0 Attachment
          Hi Tim:

          I do agree there is a sense in which this is true.
          But I don't think it's helpful.

          People who use things often cope, but don't work to improve things.
          So even when they become aware of problems, they don't help make things different.
          This is reasonable, because they are focused on their primary work, and don't really want to
          be distracted. Moreover, they may sometimes just give up, and use some other approach.
          Even when the software crashes with a fatal dialogue that invites: "Report Bug?"
          we don't bother.

          The reason I am making this point is that I have recently heard:
          * From programmers: we don't need UI professionals, we just need users
          * From UI professionals: we don't need Agile, because they reject the role of UI professionals

          Sigh.
          Robt


          Tim Wright wrote:
          >
          >
          >
          > Not that Robert's post is spam, but I do need to add:
          >
          > - Are all posters to UseNet groups Spammers?
          >
          > I guess the answer is: over time, they tend to be. I wonder if that
          > statement can be generalised.
          >
          > Over time, all airline flight crew become test pilots. I guess if they
          > fly enough, they will test new features.
          > Over time, regular restaurant-goers become food safety inspectors. I
          > guess if you're eating out regulary, you will pass information to your
          > friends.
          > Over time, all home buyers become building inspectors. I just bought a
          > house and if I were to buy another, I would be much more of a building
          > inspector! Also, who takes a friend who has bought a few houses along to
          > check your new place out?
          >
          > Now, to generalise to programmers...
          >
          > Over time, all programmers become testers (we write unit-tests)
          > Over time, all programmers become user-interface gurus (because we get
          > to see people using our product)
          > Over time, all programmers ...
          >
          > These seem particularly apt in an agile environment - I'm not sure they
          > would work so well in a waterfall organisation.
          >
          > Tim
          >
          > On 5/8/07, *Robert Biddle* <Robert_Biddle@...
          > <mailto:Robert_Biddle@...>> wrote:
          >
          > Jon Kern wrote:
          > > re: " How many functionality testers are usability testers?"
          > > are not all users (testers not withstanding) usability testers?
          >
          > I guess you might say that, but for testers it is the testing that
          > is the primary
          > task, and they have both experience and focus on that, with a
          > supporting context.
          > I would make the same distinction between users and functionality
          > testers.
          >
          > Consider:
          >
          > - are all airline flight crew test pilots?
          > - are all restaurant diners food-safety inspectors?
          > - are all home buyers building inspectors?
          >
          > Robt
          >
          >
          >
          >
          > --
          > Kei te kōrero tiki au. Kei te kōrero tiki koe. Ka kōrero tiki tāua.
          > Kōrero ai tiki tāua.
          >
        • Ash Donaldson
          ... Further to Robert s comments: As with all professions, you have dabblers and specialists. Personally, I have 12 years of study and practice in Human
          Message 4 of 22 , May 9, 2007
          • 0 Attachment
            On 10/05/2007, at 9:32 AM, Robert Biddle wrote:
            The reason I am making this point is that I have recently heard:
            * From programmers: we don't need UI professionals, we just need users
            * From UI professionals: we don't need Agile, because they reject the role of UI professionals

            Further to Robert's comments:  
            As with all professions, you have dabblers and specialists.  Personally, I have 12 years of study and practice in Human Factors, HCI and Cog. Psych. behind me.  Of course, working closely with BAs and Programmers over the years means that I've been exposed to much code and even had to dabble a bit at times.  Can I write something that sort of does what I want?  Sure.  I can whack together prototypes.  Is it easy for me?  No.  Would I trust my own code in production?  Hell no!

            In much the same way I see others gathering requirements - almost always incorrectly.  Do they get data?  Yes.  Do they think it's requirements?  Yes - straight from the horses mouths.  Are they real user and business requirements?  Hell no!  They're just opinions and wishlists.  
            For an amusing anecdote, see the Simpsons episode: "Oh Brother, Where Art Thou?".
            Homer discovers that he has a long-lost half brother, Herb Powell, who is the wealthy CEO of a car company. When Homer and Herb meet, they instantly hit it off and Herb takes in the Simpson family as his own. Herb hires Homer to help design a car for regular guys, but Homer's design proves so disastrous that it bankrupts Herb's company and forces the brothers apart once again.
            The car that Homer designs has every bell and whistle he thinks he wants ("I want a horn here, here and here.  You can never find a horn when you're mad"), comes in late, is ugly as sin, and the unit price is five times the average car.  A classic example of what happens when you ask people what their requirements are instead of undertaking the correct contextual studies and analysis to uncover their actual needs.

            I see others doing usability testing - almost always incorrectly.  Do they use users?  In many cases, no ('user representatives' aren't users and/or you can't keep using the same 'user' for valid data).  Do they gather results?  Yes.  Are these results valid?  In some cases (generalisable behaviour), yes; but in a large amount of cases - hell no!  It produces false positives, which in turn diverts attention to 'fixing' the wrong things.

            As someone once said to me: "Would you want a vet to operate on your Mother?" 

            So, is it good to dabble?  Yes.  It gives you a greater appreciation of what a specialist does / is good for / may need - and on a very small project, it may just be enough to get you over the line.
            Does that replace the need for a specialist?  Not on your Mother's life. ;)  

            Cheers,

            Ash Donaldson
            Principal
            Produxi Pty Ltd
            Designing better user experiences

            +61 (0)414 55 9996






          • Adrian Howard
            On 9 May 2007, at 15:23, White, Jeff wrote: [snip] ... True. However, I seem to encounter two breeds of specialist. The inward looking ones who don t want to
            Message 5 of 22 , May 10, 2007
            • 0 Attachment
              On 9 May 2007, at 15:23, White, Jeff wrote:
              [snip]
              > All of Tim's points have an amount of truth to them. But, people
              > are in
              > different roles for good reasons and in my opinion there's absolutely
              > nothing wrong with that.

              True.

              However, I seem to encounter two breeds of specialist.

              The "inward" looking ones who don't want to listen to anybody else,
              and enjoy telling other folk what to do. They suck.

              The "outward" looking ones who realise their speciality exists an an
              ecosystem of skills - and all of them are necessary to getting the
              job done. They rock.

              I like the term "generalising specialist" - wish I could remember who
              came up with it.

              > I would never assume a programmers job is easy enough that I can
              > become
              > a java "guru" just because I've seen dozens of java developers work on
              > dozens of projects over many years. It would be nice if programmers
              > had
              > the same respect for the complexities of user interface design.

              Nice generalisation there :-(

              What I'm fighting against is where one group is not letting the other
              contribute. I've seen too many developers not listening to UI folk,
              and too many UI folk not listening to developers - when _both_ groups
              have insights that the other needs.

              And this isn't just because programmers need to be "told what to do"
              and UI folk need to be "told what they can do".

              There isn't a line between the work that UI folk do and the work that
              the software folk do. The design work that both groups do affects the
              product - and the insights of one group and help the other. Synergy
              and consensus is what should be happening. Pointless power struggles
              over who is the "boss" is unfortunately sometimes the actual result.

              This is one of the things that I like about working on agile teams.
              They seem much more amenable to developing a respectful ecosystem of
              skills. Whole Team and all that.

              Cheers,

              Adrian
            • Desilets, Alain
              I agree wholeheartedly. It s not your user s job to find usability problems, no more than it is their job to find bugs in your system. Alain
              Message 6 of 22 , May 10, 2007
              • 0 Attachment
                I agree wholeheartedly.

                It's not your user's job to find usability problems, no more than it is their job to find bugs in your system.

                Alain

                > -----Original Message-----
                > From: agile-usability@yahoogroups.com
                > [mailto:agile-usability@yahoogroups.com] On Behalf Of Robert Biddle
                > Sent: May 9, 2007 7:32 PM
                > To: agile-usability@yahoogroups.com
                > Subject: Re: [agile-usability] New poll for agile-usability
                >
                > Hi Tim:
                >
                > I do agree there is a sense in which this is true.
                > But I don't think it's helpful.
                >
                > People who use things often cope, but don't work to improve things.
                > So even when they become aware of problems, they don't help
                > make things different.
                > This is reasonable, because they are focused on their primary
                > work, and don't really want to be distracted. Moreover, they
                > may sometimes just give up, and use some other approach.
                > Even when the software crashes with a fatal dialogue that
                > invites: "Report Bug?"
                > we don't bother.
                >
                > The reason I am making this point is that I have recently heard:
                > * From programmers: we don't need UI professionals, we just need users
                > * From UI professionals: we don't need Agile, because they
                > reject the role of UI professionals
                >
                > Sigh.
                > Robt
                >
                >
                > Tim Wright wrote:
                > >
                > >
                > >
                > > Not that Robert's post is spam, but I do need to add:
                > >
                > > - Are all posters to UseNet groups Spammers?
                > >
                > > I guess the answer is: over time, they tend to be. I wonder if that
                > > statement can be generalised.
                > >
                > > Over time, all airline flight crew become test pilots. I
                > guess if they
                > > fly enough, they will test new features.
                > > Over time, regular restaurant-goers become food safety
                > inspectors. I
                > > guess if you're eating out regulary, you will pass
                > information to your
                > > friends.
                > > Over time, all home buyers become building inspectors. I
                > just bought a
                > > house and if I were to buy another, I would be much more of
                > a building
                > > inspector! Also, who takes a friend who has bought a few
                > houses along
                > > to check your new place out?
                > >
                > > Now, to generalise to programmers...
                > >
                > > Over time, all programmers become testers (we write
                > unit-tests) Over
                > > time, all programmers become user-interface gurus (because
                > we get to
                > > see people using our product) Over time, all programmers ...
                > >
                > > These seem particularly apt in an agile environment - I'm not sure
                > > they would work so well in a waterfall organisation.
                > >
                > > Tim
                > >
                > > On 5/8/07, *Robert Biddle* <Robert_Biddle@...
                > > <mailto:Robert_Biddle@...>> wrote:
                > >
                > > Jon Kern wrote:
                > > > re: " How many functionality testers are usability testers?"
                > > > are not all users (testers not withstanding)
                > usability testers?
                > >
                > > I guess you might say that, but for testers it is the
                > testing that
                > > is the primary
                > > task, and they have both experience and focus on that, with a
                > > supporting context.
                > > I would make the same distinction between users and
                > functionality
                > > testers.
                > >
                > > Consider:
                > >
                > > - are all airline flight crew test pilots?
                > > - are all restaurant diners food-safety inspectors?
                > > - are all home buyers building inspectors?
                > >
                > > Robt
                > >
                > >
                > >
                > >
                > > --
                > > Kei te kōrero tiki au. Kei te kōrero tiki koe. Ka kōrero tiki tāua.
                > > Kōrero ai tiki tāua.
                > >
                >
                >
                >
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
              • Pascal Roy
                Adrian, I agree with you on the generalising specialist, an interesting term... I ve seen a number of times development completely halted because a bunch of
                Message 7 of 22 , May 10, 2007
                • 0 Attachment
                  Adrian, 

                  I agree with you on the generalising specialist, an interesting term...

                  I've seen a number of times development  completely halted because a bunch of specialists could not
                  agree in which tier things needed to go. Of course, each specialist had the best answer and it usually 
                  involved their own tier. It took a good generalist to resolve the issue and the solution typically involves many elements (in different tiers)...

                  Not saying you don't need specialists, you do. In fact, in a team, it would be good to have specialists in the major technical aspects you touch. 
                  IMHO, in each team, you really do need a good generalist who knows enough to see the whole picture.
                  Good generalists are also very often specialists in the fields that interest them more...  
                  They also often become the glue that holds the team together (from a technical stand-point  at least). They can make good agile coaches if they are also good with people.

                  However, in my experience, they are usually very hard to find. So If you've got one in your team, hang on to them.

                  Another experience I've had (two practical cases to be exact), which is a little bit infuriating is customers insisting on UI designs with known usability issues (not talking about fuzzy things here, talking about really practical stuff that I can pinpoint in the textbooks). They listen, seem to understand the consequences, but in the end insist and justify it saying that since they are paying for it... In business, at least in theory, the customer is always right. However, as an engineer, it is part of my code of conduct to do things right. Things are pretty clear in other engineering practices in terms of doing it right and wrong (like building a bridge), But in software engineering, practices are so fuzzy as to make this distinction very difficult to make (or at least make it seem somewhat arbitrary to customers?).  

                  Originally, I thought  the trouble was the fact that I'm not a "Usability Expert" (although it's become a passion of mine) per say and they just did not believe me. 
                  But even when I used the textbooks to back me up, it did not seem to do it for these guys. Or, maybe I'm just a bad salesman... 

                  Any usability expert here had this sort of experience? (it would make me feel better). If so, how does it make you feel? How do you react to it? 

                  Pascal Roy, ing./P.Eng., PMP
                  Vice-Président/Vice President
                  Elapse Technologies inc.

                  [url]        www.elapsetech.com
                  [email]]  pascal.roy@...
                  [cell]       514-862-6836


                  Le 07-05-10 à 05:53, Adrian Howard a écrit :


                  On 9 May 2007, at 15:23, White, Jeff wrote:
                  [snip]
                  > All of Tim's points have an amount of truth to them. But, people
                  > are in
                  > different roles for good reasons and in my opinion there's absolutely
                  > nothing wrong with that.

                  True.

                  However, I seem to encounter two breeds of specialist.

                  The "inward" looking ones who don't want to listen to anybody else,
                  and enjoy telling other folk what to do. They suck.

                  The "outward" looking ones who realise their speciality exists an an
                  ecosystem of skills - and all of them are necessary to getting the
                  job done. They rock.

                  I like the term "generalising specialist" - wish I could remember who
                  came up with it.

                  > I would never assume a programmers job is easy enough that I can
                  > become
                  > a java "guru" just because I've seen dozens of java developers work on
                  > dozens of projects over many years. It would be nice if programmers
                  > had
                  > the same respect for the complexities of user interface design.

                  Nice generalisation there :-(

                  What I'm fighting against is where one group is not letting the other
                  contribute. I've seen too many developers not listening to UI folk,
                  and too many UI folk not listening to developers - when _both_ groups
                  have insights that the other needs.

                  And this isn't just because programmers need to be "told what to do"
                  and UI folk need to be "told what they can do".

                  There isn't a line between the work that UI folk do and the work that
                  the software folk do. The design work that both groups do affects the
                  product - and the insights of one group and help the other. Synergy
                  and consensus is what should be happening. Pointless power struggles
                  over who is the "boss" is unfortunately sometimes the actual result.

                  This is one of the things that I like about working on agile teams.
                  They seem much more amenable to developing a respectful ecosystem of
                  skills. Whole Team and all that.

                  Cheers,

                  Adrian


                • Adrian Howard
                  ... I read the original post as referring to having an onsite customer using the system. I m not saying that this is a complete replacement for more formal
                  Message 8 of 22 , May 10, 2007
                  • 0 Attachment
                    On 10 May 2007, at 12:40, Desilets, Alain wrote:

                    > I agree wholeheartedly.
                    >
                    > It's not your user's job to find usability problems, no more than
                    > it is their job to find bugs in your system.

                    I read the original post as referring to having an onsite customer
                    using the system.

                    I'm not saying that this is a complete replacement for more formal
                    tests (coz it isn't :-) and I've certainly seen a sort of Stockholm
                    Syndrome type relationship set in with the customer adapting to a UI
                    that becomes worse as it evolves during a project.

                    However, even with these issues, observing somebody who isn't a
                    developer using the system on a daily basis can help an enormous
                    amount in both spotting, and raising the priority of, usability
                    issues within the team.

                    Cheers,

                    Adrian
                  • Adrian Howard
                    ... [snip] Don t worry - I ve seen this a lot. Even when I ve been employed primarily for my user experience hat :-) The absolute best way I ve found to
                    Message 9 of 22 , May 10, 2007
                    • 0 Attachment
                      On 10 May 2007, at 12:58, Pascal Roy wrote:
                      > Another experience I've had (two practical cases to be exact),
                      > which is a little bit infuriating is customers insisting on UI
                      > designs with known usability issues (not talking about fuzzy things
                      > here, talking about really practical stuff that I can pinpoint in
                      > the textbooks). They listen, seem to understand the consequences,
                      > but in the end insist and justify it saying that since they are
                      > paying for it...
                      [snip]

                      Don't worry - I've seen this a lot. Even when I've been employed
                      primarily for my user experience hat :-)

                      The absolute best way I've found to convince folk is by
                      demonstration. Show them a real user having problems with the "bad"
                      system. Show them having no problems with the "right" system.

                      Adrian
                    • Pascal Roy
                      That s just it. They don t want to pay you to spend the time do it right just so you can eventually show them the right way... ;-) I guess I ll have to do it
                      Message 10 of 22 , May 10, 2007
                      • 0 Attachment
                        That's just it. They don't want to pay you to spend the time do it right just so you can eventually show them the right way... ;-) 
                        I guess I'll have to do it for free...

                        Pascal Roy, ing./P.Eng., PMP
                        Vice-Président/Vice President
                        Elapse Technologies inc.

                        [url]        www.elapsetech.com
                        [email]]  pascal.roy@...
                        [cell]       514-862-6836


                        Le 07-05-10 à 08:30, Adrian Howard a écrit :

                        X-SpamDetect-Info: ------------- Start ASpam results ---------------
                        X-SpamDetect-Info: This message may be spam. This message BODY has been altered so 
                        X-SpamDetect-Info: your mail client can be set to filter it, see http://netwinsite.com/surgemail/aspaminfo.htm
                        X-SpamDetect: ******: 6.300000 Suspicious tags-to-text ratio=0.5,Some html comments=2.0,Gifs in urls=0.8,Aspam=3.0
                        X-SpamDetect-Info: ------------- End ASpam results -----------------
                        
                        


                        On 10 May 2007, at 12:58, Pascal Roy wrote:
                        > Another experience I've had (two practical cases to be exact),
                        > which is a little bit infuriating is customers insisting on UI
                        > designs with known usability issues (not talking about fuzzy things
                        > here, talking about really practical stuff that I can pinpoint in
                        > the textbooks). They listen, seem to understand the consequences,
                        > but in the end insist and justify it saying that since they are
                        > paying for it...
                        [snip]

                        Don't worry - I've seen this a lot. Even when I've been employed
                        primarily for my user experience hat :-)

                        The absolute best way I've found to convince folk is by
                        demonstration. Show them a real user having problems with the "bad"
                        system. Show them having no problems with the "right" system.

                        Adrian


                      • Desilets, Alain
                        ... Oh, sorry. I didn t have time to follow this thread from the beginning. I was just reacting to Robert s post. ... Yes, I agree. I even weed out lots of
                        Message 11 of 22 , May 10, 2007
                        • 0 Attachment
                          > -----Original Message-----
                          > From: agile-usability@yahoogroups.com
                          > [mailto:agile-usability@yahoogroups.com] On Behalf Of Adrian Howard
                          > Sent: May 10, 2007 8:00 AM
                          > To: agile-usability@yahoogroups.com
                          > Subject: Re: [agile-usability] New poll for agile-usability
                          >
                          >
                          > On 10 May 2007, at 12:40, Desilets, Alain wrote:
                          >
                          > > I agree wholeheartedly.
                          > >
                          > > It's not your user's job to find usability problems, no
                          > more than it
                          > > is their job to find bugs in your system.
                          >
                          > I read the original post as referring to having an onsite
                          > customer using the system.

                          Oh, sorry. I didn't have time to follow this thread from the beginning.
                          I was just reacting to Robert's post.

                          > I'm not saying that this is a complete replacement for more
                          > formal tests (coz it isn't :-) and I've certainly seen a sort
                          > of Stockholm Syndrome type relationship set in with the
                          > customer adapting to a UI that becomes worse as it evolves
                          > during a project.
                          >
                          > However, even with these issues, observing somebody who isn't
                          > a developer using the system on a daily basis can help an
                          > enormous amount in both spotting, and raising the priority
                          > of, usability issues within the team.

                          Yes, I agree. I even weed out lots of usability issues by using the
                          system myself even though I'm the one who built it. I guess I can do
                          that because I'm a very impatient user. So even when I use software I
                          built, I will get annoyed rapidly at anything that is not really easy to
                          use.
                        • Adrian Howard
                          ... [snip] ... [snip] Don t apologies - I could be wrong! I think you could read it either way :-) Adrian
                          Message 12 of 22 , May 12, 2007
                          • 0 Attachment
                            On 11 May 2007, at 03:02, Desilets, Alain wrote:

                            >> [mailto:agile-usability@yahoogroups.com] On Behalf Of Adrian Howard
                            [snip]
                            >> I read the original post as referring to having an onsite
                            >> customer using the system.
                            >
                            > Oh, sorry. I didn't have time to follow this thread from the
                            > beginning.
                            > I was just reacting to Robert's post.
                            [snip]

                            Don't apologies - I could be wrong! I think you could read it either
                            way :-)

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