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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.