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

Re: [agile-usability] UI & user stories - are they mini fixed scope contracts...

Expand Messages
  • PaulOldfield1@aol.com
    (responding to Jeff) ... That sounds fine so far. Would be good if we could cut some of the fiddle out of the UI work so it gets more predictable - is there
    Message 1 of 27 , Aug 30, 2006
      (responding to Jeff)
       
      > However, this leaves a lot of details on the table to be figured
      > out during the iteration.  This forces a bit of discussion
      to
      > happen during the iteration, and that UI pairing thing to
      > happen.  This increases the liklihood that there may
      be
      > changes to the story - fine grain changes, but changes that
      > may affect the time estimated.  And, for the developers
      on
      > the list, you probably know that fiddling with UI can be
      some
      > of the most time consuming and frustrating stuff. 
      That sounds fine so far.  Would be good if we could cut
      some of the 'fiddle' out of the UI work so it gets more
      predictable - is there any way of doing this?  Haven't
      fiddled with UI much myself recently.
       
      > So my question is: is the strategy I described a bad one?
       
      Good, I'd say.
       
      > of course the amount of trust and the quality of communication
      > between developer and UI person here is critical.
       
      That's why this is the agile-usability not just usability forum,
      isn't it  ;-)
       
      > ... When he [the luminary] saw the amound of work we were
      > doing, in particular how much we were writing - he started
      > referring to what we were doing as a mini-waterfall.
       
      Hmm... I'm only going by your description, but I think I might
      agree with your agile luminary.
       
      > What causes me to try to change the direction of this thread
      > is: since there are a few people tuned in that obviously
      have
      > opinions on what's appropriate in a story driven
      development
      > context, I'm curious how many details are acceptable to be
      > resolved.  And, when does resolving details become
      changing
      > scope during the iteration.
      There are IMHO two things you want before the start of an
      iteration.  First, an agreement on the goal - at the end of
      the iteration the software will meet a specified need, often
      expressed as a user story.  Second, you will know enough
      about the goal to give a reasonably accurate estimate of
      how much effort it will take to meet the goal.  I guess it's up
      to the project to decide how far out you can be before it
      gets unreasonable, but if anyone's demanding so much
      accuracy that you have to do all the design up front, then
      you need either to push back on that demand or find a way
      to cut down on the variability in your way of working.  Or
      accept you're mini-waterfall with all that entails (hint -
      probably the wrong way to go).
       
      One question - is there any reason you have to get the usability
      right *this* iteration?  For example, is the cost of change so
      high that you need to get it right first time?  Or some other
      reason?
       
      Paul Oldfield
       
       
    • Pascal Roy
      One question - is there any reason you have to get the usability right *this* iteration? For example, is the cost of change so high that you need to get it
      Message 2 of 27 , Aug 30, 2006

        One question - is there any reason you have to get the usability

        right *this* iteration?  For example, is the cost of change so

        high that you need to get it right first time?  Or some other

        reason?

         

        No,you don’t NEED to get it right necessarily. But if you can get it without more work, than why wouldn’t you want to get it right the first iteration?

        With the right people there, maybe that’s possible. Now, if if does imply significantly more work, than I guess it would be the customer’s decision, wouldn’t it?

        Perhaps to him, it has business value to have the bad UI for now even if there is rework cost involved later on.

         

        Open question: In some cases, I have the feeling it does not necessarily cost to come up with a basic but usable UI vs a basic but unusable UI. I think it has more to do with having the right expertise involved when the UI design decisions are taken. As far as I know right now, UI design decisions are very often made by people with zero knowledge in basic usability. Am I wrong in thinking that?  

         

        Pascal Roy, ing./P.Eng., PMP

        Vice-Président/Vice President

        Elapse Technologies Inc.

         

        [url]    http://www.elapsetech.com

        [email]  pascal.roy@...

        [cell]   514-862-6836

         

         


        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of PaulOldfield1@...
        Sent: 30 août 2006 15:24
        To: agile-usability@yahoogroups.com
        Subject: Re: [agile-usability] UI & user stories - are they mini fixed scope contracts...

         

        (responding to Jeff)

         

        > However, this leaves a lot of details on the table to be figured

        > out during the iteration.  This forces a bit of discussion to

        > happen during the iteration, and that UI pairing thing to

        > happen.  This increases the liklihood that there may be

        > changes to the story - fine grain changes, but changes that

        > may affect the time estimated.  And, for the developers on

        > the list, you probably know that fiddling with UI can be some

        > of the most time consuming and frustrating stuff. 

        That sounds fine so far.  Would be good if we could cut

        some of the 'fiddle' out of the UI work so it gets more

        predictable - is there any way of doing this?  Haven't

        fiddled with UI much myself recently.

         

        > So my question is: is the strategy I described a bad one?

         

        Good, I'd say.

         

        > of course the amount of trust and the quality of communication

        > between developer and UI person here is critical.

         

        That's why this is the agile-usability not just usability forum,

        isn't it  ;-)

         

        > ... When he [the luminary] saw the amound of work we were

        > doing, in particular how much we were writing - he started

        > referring to what we were doing as a mini-waterfall.

         

        Hmm... I'm only going by your description, but I think I might

        agree with your agile luminary.

         

        > What causes me to try to change the direction of this thread

        > is: since there are a few people tuned in that obviously have

        > opinions on what's appropriate in a story driven development

        > context, I'm curious how many details are acceptable to be

        > resolved.  And, when does resolving details become changing

        > scope during the iteration.

        There are IMHO two things you want before the start of an

        iteration.  First, an agreement on the goal - at the end of

        the iteration the software will meet a specified need, often

        expressed as a user story.  Second, you will know enough

        about the goal to give a reasonably accurate estimate of

        how much effort it will take to meet the goal.  I guess it's up

        to the project to decide how far out you can be before it

        gets unreasonable, but if anyone's demanding so much

        accuracy that you have to do all the design up front, then

        you need either to push back on that demand or find a way

        to cut down on the variability in your way of working.  Or

        accept you're mini-waterfall with all that entails (hint -

        probably the wrong way to go).

         

        One question - is there any reason you have to get the usability

        right *this* iteration?  For example, is the cost of change so

        high that you need to get it right first time?  Or some other

        reason?

         

        Paul Oldfield

         

         


        __________ Information NOD32 1.1731 (20060830) __________

        Ce message a ete verifie par NOD32 Antivirus System.
        http://www.nod32.com
      • PaulOldfield1@aol.com
        (responding to William) ... Agreed; that s my point about whether we *need* to get the UI right this iteration. Good to hear some people work that way. Do you
        Message 3 of 27 , Aug 30, 2006
          (responding to William)
           
          > I'm also a fan of splitting stories when surprise UI work
          appears
          > during an iteration. Often it's possible to get something
          functional
          > but unappealing out in the original point budget...
           
          Agreed; that's my point about whether we *need* to get the UI
          right this iteration.  Good to hear some people work that way.
          Do you think this is something that could be timeboxed?

          > And I think over time good teams evolve ways for UI
          designers
          > to tweak without developers around.
           
          Is there any reason why UI designers could not become
          developers, and vice-versa?  That is, take on more and more
          of the tweaks over time until the 'developer' is doing only
          the architectural and 'heavy lifting' stuff?
           
          Paul Oldfield
        • Jeff Patton
          ... Actually the issue happens both with usability/UI related things, and other functional characteristics of the user story. The reason why they need to be
          Message 4 of 27 , Aug 30, 2006
            --- In agile-usability@yahoogroups.com, PaulOldfield1@... wrote:

            > One question - is there any reason you have to get the usability
            > right *this* iteration? For example, is the cost of change so
            > high that you need to get it right first time? Or some other
            > reason?

            Actually the issue happens both with usability/UI related things, and
            other functional characteristics of the user story. The reason why
            they need to be right is a project "smell" all by itself.

            I've seen this pattern played out many times on many projects. Let's
            call them "waterfall projects in agile clothing:"
            1. Collaborative team driven by customer gets together and writes
            user stories
            2. Collbortive team driven by development gets together and estimates
            stories
            3. Customers collaboratively plan a first product release getting all
            the high value stories in
            4. Iterative development begins
            5. Story is bigger than expected, someone suggests splitting it to
            take on additional work next iteration.
            6. The release is full - since we've already planned all the stories
            we can do in the release. If we split a story or don't get it right
            this iteration, it means some other story has to move out of the
            release.
            7. This causes pressure for getting it right each iteration.
            This causes documents supporting stories to grow, collaboration to
            decrease, and tension to rise.

            Does that pattern sound familiar to anyone currently on an agile
            project?

            There's lots of things wrong here, and lots of strategies for fixing
            them. The problem is related to usability stuff only in that
            usability, amoung other areas of product development, carries with it
            some uncertainty that will emerge during development.

            I'm not sure I've /ever/ in the last 12 years been on a project where
            there wasn't a scheduled release, and some expectation for a certain
            number of features being released then. That often, if not always,
            causes some tension around getting things right sooner - ideally the
            first time. I work hard to dispell that tension and have a few
            strategies for dealing with it. I'm sure everyone hates it, but that
            tension is an annoying reality that needs to be expected and dealt
            with.

            thanks,

            -Jeff






            >
            > Paul Oldfield
            >
          • Desilets, Alain
            Open question: In some cases, I have the feeling it does not necessarily cost to come up with a basic but usable UI vs a basic but unusable UI. I think it
            Message 5 of 27 , Aug 30, 2006
              Message

              Open question: In some cases, I have the feeling it does not necessarily cost to come up with a basic but usable UI vs a basic but unusable UI.   I think it has more to do with having the right expertise involved when the UI design decisions are taken. As far as I know right now, UI design decisions are very often made by people with zero knowledge in basic usability. Am I wrong in thinking that?   

               

              -- Alain:

              I think that's accurate. Often there are ways to greatly increasing the usability by putting in a small amount of extra effort. In such situations, going for the more usable design is often the appropriate decision (but that's for the customer to decide). But you have be concerned about usabilit

              (Message over 64 KB, truncated)

            • Jeff Patton
              I m changing thread names as ideas start to mutate to make them more intention revealing.... ... This is another puzzle that people doing UI and usability work
              Message 6 of 27 , Aug 30, 2006
                I'm changing thread names as ideas start to mutate to make them more
                intention revealing....

                --- In agile-usability@yahoogroups.com, PaulOldfield1@... wrote:
                > Is there any reason why UI designers could not become
                > developers, and vice-versa? That is, take on more and more
                > of the tweaks over time until the 'developer' is doing only
                > the architectural and 'heavy lifting' stuff?

                This is another puzzle that people doing UI and usability work in an
                Agile space often deal with.

                Customers specify the work that needs to be done. Development
                estimates and performs the work.

                Oftentimes UI people both specify and perform the work. Sometimes
                they act as the customer when specifying the work. Sometimes they act
                with the authority of the customer when doing so. Sometimes each
                suggestion they make is reviewed by the customer. If they have the
                customer's trust, often it isn't.

                The basic question might be: do we include UI people who are touching
                code - html and css - as part of the development team? Do they
                estimate? Do they put on their customer hat and decide how the
                software should look and work, then put on their developer hat and
                estimate it? Could their customer self argue with their developer
                self? [picture scene from The Fight Club]

                I'm sure there's lots of right answers, but I wonder what people have
                seen work?

                thanks,

                -Jeff
              • Jeff Patton
                ... necessarily ... UI. I ... when the UI ... decisions ... usability. Am I ... Even worse: I ve often observed an unusable solution concocted by non UI people
                Message 7 of 27 , Aug 30, 2006
                  --- In agile-usability@yahoogroups.com, "Pascal Roy" <pascal.roy@...>
                  wrote:
                  > Open question: In some cases, I have the feeling it does not
                  necessarily
                  > cost to come up with a basic but usable UI vs a basic but unusable
                  UI. I
                  > think it has more to do with having the right expertise involved
                  when the UI
                  > design decisions are taken. As far as I know right now, UI design
                  decisions
                  > are very often made by people with zero knowledge in basic
                  usability. Am I
                  > wrong in thinking that?

                  Even worse: I've often observed an unusable solution concocted by non
                  UI people be both unusable, and very expensive to build.

                  -Jeff
                • William Pietri
                  ... Personally, I often use estimation values as rough timeboxing. If during the construction of a story people ask for things that weren t in my original
                  Message 8 of 27 , Aug 30, 2006
                    PaulOldfield1@... wrote:
                    > (responding to William)
                    >
                    > > I'm also a fan of splitting stories when surprise UI work appears
                    > > during an iteration. Often it's possible to get something functional
                    > > but unappealing out in the original point budget...
                    >
                    > Agreed; that's my point about whether we *need* to get the UI
                    > right this iteration. Good to hear some people work that way.
                    > Do you think this is something that could be timeboxed?

                    Personally, I often use estimation values as rough timeboxing. If during
                    the construction of a story people ask for things that weren't in my
                    original estimate, I try to be mindful of whether it would have
                    increased the estimate. If the answer is yes, that's when I'm inclined
                    to split or change estimates. E.g.: "I thought we were only talking
                    about X when I said two points. I could probably change that to Y for
                    the same price, but adding Z will make it 3 points. Shall we just add a
                    new card for Z?"

                    I'm not sure how orthodox that is, but it seems to work for me and mine.

                    > > And I think over time good teams evolve ways for UI designers
                    > > to tweak without developers around.
                    >
                    > Is there any reason why UI designers could not become
                    > developers, and vice-versa? That is, take on more and more
                    > of the tweaks over time until the 'developer' is doing only
                    > the architectural and 'heavy lifting' stuff?

                    I think motion in both directions is good. For example, I certainly like
                    to see developers fixing spacing and style conformance issues without
                    waiting for a designer to tell them, and I think working in close
                    proximity with a good designer is the best way to pick those things up.
                    And I think it's great when designers become more comfortable with the
                    raw material of their medium and the tools the development team uses, so
                    that a designer can work directly on the things they care about.
                    Likewise, close contact makes learning this pretty natural.

                    But yes, I generally like it when systems evolve to give power to the
                    people, letting developers focus on the geeky details. As a developer,
                    it's both scary and freeing. As a user, it's fantastically empowering.

                    William
                  • William Pietri
                    ... It has never happened to me, but I ve certainly heard tell about it. When my clients move in this direction, I remind them of something that I think I
                    Message 9 of 27 , Aug 30, 2006
                      Jeff Patton wrote:
                      > I've seen this pattern played out many times on many projects. Let's
                      > call them "waterfall projects in agile clothing:" [...]
                      > 6. The release is full - since we've already planned all the stories
                      > we can do in the release. If we split a story or don't get it right
                      > this iteration, it means some other story has to move out of the
                      > release.
                      > 7. This causes pressure for getting it right each iteration.
                      > This causes documents supporting stories to grow, collaboration to
                      > decrease, and tension to rise.
                      >
                      > Does that pattern sound familiar to anyone currently on an agile
                      > project?

                      It has never happened to me, but I've certainly heard tell about it.
                      When my clients move in this direction, I remind them of something that
                      I think I stole from Barry Boehm: agile processes aren't plan-driven,
                      they're planning-driven.

                      William
                    • Jon Meads
                      Paul Oldfield writes: Is there any reason why UI designers could not become developers, and vice-versa? My experience is that the usability skills a person
                      Message 10 of 27 , Aug 30, 2006
                        Paul Oldfield writes:   "Is there any reason why UI designers could not become developers, and vice-versa? 
                         
                        My experience is that the usability skills a person has often (not always, but often enough) go out the window once that person starts writing code. This is particularly the case when the usability issue is not cosmetic (screen design) but architectural (task design).
                         
                        Cheers,
                        jon
                         

                                   Jon Meads, Usability Architects, Inc.
                                  
                        Designing the User Experience
                                   425-827-9296, jon@...


                      • Ron Jeffries
                        Hello Pascal, thank you for the thoughts quoted here. On Wednesday, ... How is it possible, if it can be gotten un-right, to get it right without more work?
                        Message 11 of 27 , Aug 30, 2006
                          Hello Pascal, thank you for the thoughts quoted here. On Wednesday,
                          August 30, 2006, at 3:41:53 PM, you wrote:

                          > No,you don’t NEED to get it right necessarily. But if you can get it without
                          > more work, than why wouldn’t you want to get it right the first iteration?

                          How is it possible, if it can be gotten un-right, to get it right
                          without more work?

                          Ron Jeffries
                          www.XProgramming.com
                          The fact that we know more today, and are more capable today,
                          is good news about today, not bad news about yesterday.
                        • PaulOldfield1@aol.com
                          (responding to Pascal) ... Of course, if the estimate wasn t too far out. ... Agreed. ... Agreed. It would be nice to cut re-work costs as much as possible,
                          Message 12 of 27 , Aug 30, 2006
                            (responding to Pascal)
                             
                            >> is there any reason you have to get the usability
                            >> right *this* iteration?
                             
                            > No,you don’t NEED to get it right necessarily. But if you
                            > can get it without more work, than why wouldn’t you want
                            > to get it right the first iteration?
                             
                            Of course, if the estimate wasn't too far out.
                             
                            > Now, if if does imply significantly more work, than I guess it
                            > would be the customer’s decision, wouldn’t it?
                             
                            Agreed.
                             
                            > Perhaps to him, it has business value to have the bad UI
                            > for now even if there is rework cost involved later on.
                             
                            Agreed.  It would be nice to cut re-work costs as much as
                            possible, but we have to accept *some* hit if we don't get
                            it right first time.  We want this cost small so we don't try
                            and go overboard to get it right first time.
                             
                            > Open question: In some cases, I have the feeling it does
                            > not necessarily cost to come up with a basic but usable UI
                            > vs a basic but unusable UI. I think it has more to do with
                            > having the right expertise involved when the UI design
                            > decisions are taken.
                             
                            Agreed.
                             
                            > As far as I know right now, UI design decisions are very
                            > often made by people with zero knowledge in basic usability.
                            > Am I wrong in thinking that?
                             
                            I guess that's going to vary between teams.  Surely an agile
                            team would detect a problem early if there were such a
                            problem?
                             
                            One common problem happens when people don't know there
                            is a better way of doing things.  I know it's common because
                            it's been happening to *me* for over 20 years, and I'm still
                            finding that there are better ways.  We need to get this
                            expertise transmitted faster.  But we need to get the awareness
                            of a better way transmitted, or there's no driver for transmitting
                            expertise.
                             
                            Paul Oldfield
                          • Pascal Roy
                            It is possible if you have somebody on your team who actually has a little bit of knowledge about usability and who can actually tell that the UI being built
                            Message 13 of 27 , Aug 30, 2006

                              It is possible if you have somebody on your team who actually has a little bit of knowledge about usability and who can actually tell that the UI being built has a problem (even a basic usability issue).  IMHO, most developers have very little knowledge of usability yet they are tasked to design interfaces in most teams (well, at least in my experience). A little knowledge would at least remove some of the most basic errors.  It’s not more work, it’s about having skilled people do the work. And we’re not talking about subtle rocket science usability tweaks here which I agree may require tons of more  work and may not add sufficient business value to be justified, I’m talking about some of the more basic stuff (like the example I gave earlier about that poor United person who had to write stuff down between screens in order to simply get me my mileage plus ticket). Doesn’t take a rocket scientist to figure out that perhaps that person needed all the info in a screen to do her job completely? I guess the developers didn’t quite get to that. Not that the software could not do the job, it did… Eventually. However, it made me angry because of the time I had to wait, and it caused that poor woman to feel really embarrassed (as in feel stupid).  Btw, she had to do the data entry twice over, because the first time, she had made a mistake when she entered the info from the first screen on the second screen from her written notes. At least, I made her laugh when I told her I hated software as much as she did and that’s what I did for a living. Fun stuff… That sort of thing makes me think it is the responsibility of developers to learn about usability the more so in an agile environment. And guess what, I can attest that it’s even fun, it makes you think from a different perspective: the other side of the screen…

                               

                              Pascal Roy, ing./P.Eng., PMP

                              Vice-Président/Vice President

                              Elapse Technologies Inc.

                               

                              [url]    http://www.elapsetech.com

                              [email]  pascal.roy@...

                              [cell]   514-862-6836

                               

                               


                              From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Ron Jeffries
                              Sent: 30 août 2006 17:04
                              To: agile-usability@yahoogroups.com
                              Subject: Re: [agile-usability] UI & user stories - are they mini fixed scope contracts...

                               

                              Hello Pascal, thank you for the thoughts quoted here. On Wednesday,
                              August 30, 2006, at 3:41:53 PM, you wrote:

                              > No,you don’t NEED to get it right necessarily. But if you can get it
                              without
                              > more work, than why wouldn’t you want to get it right the first
                              iteration?

                              How is it possible, if it can be gotten un-right, to get it right
                              without more work?

                              Ron Jeffries
                              www.XProgramming. com
                              The fact that we know more today, and are more capable today,
                              is good news about today, not bad news about yesterday.


                              __________ Information NOD32 1.1731 (20060830) __________

                              Ce message a ete verifie par NOD32 Antivirus System.
                              http://www.nod32.com

                            • Pascal Roy
                              Paul, you nailed it right on the nose…. Maybe I’m wrong, but from what Jeff told me in Montreal at the CRIM, there are just not that many people
                              Message 14 of 27 , Aug 30, 2006

                                Paul, you nailed it right on the nose….

                                Maybe I’m wrong, but from what Jeff told me in Montreal at the CRIM, there are just not that many people knowledgeable on usability.

                                That means, most teams actually don’t know any better. I think that needs fixing…

                                 

                                Pascal Roy, ing./P.Eng., PMP

                                Vice-Président/Vice President

                                Elapse Technologies Inc.

                                 

                                [url]    http://www.elapsetech.com

                                [email]  pascal.roy@...

                                [cell]   514-862-6836

                                 

                                 


                                From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of PaulOldfield1@...
                                Sent: 30 août 2006 17:09
                                To: agile-usability@yahoogroups.com
                                Subject: Re: [agile-usability] UI & user stories - are they mini fixed scope contracts...

                                 

                                (responding to Pascal)

                                 

                                >> is there any reason you have to get the usability

                                >> right *this* iteration?

                                 

                                > No,you don’t NEED to get it right necessarily. But if you

                                > can get it without more work, than why wouldn’t you want

                                > to get it right the first iteration?

                                 

                                Of course, if the estimate wasn't too far out.

                                 

                                > Now, if if does imply significantly more work, than I guess it

                                > would be the customer’s decision, wouldn’t it?

                                 

                                Agreed.

                                 

                                > Perhaps to him, it has business value to have the bad UI

                                > for now even if there is rework cost involved later on.

                                 

                                Agreed.  It would be nice to cut re-work costs as much as

                                possible, but we have to accept *some* hit if we don't get

                                it right first time.  We want this cost small so we don't try

                                and go overboard to get it right first time.

                                 

                                > Open question: In some cases, I have the feeling it does

                                > not necessarily cost to come up with a basic but usable UI

                                > vs a basic but unusable UI. I think it has more to do with

                                > having the right expertise involved when the UI design

                                > decisions are taken.

                                 

                                Agreed.

                                 

                                > As far as I know right now, UI design decisions are very

                                > often made by people with zero knowledge in basic usability.

                                > Am I wrong in thinking that?

                                 

                                I guess that's going to vary between teams.  Surely an agile

                                team would detect a problem early if there were such a

                                problem?

                                 

                                One common problem happens when people don't know there

                                is a better way of doing things.  I know it's common because

                                it's been happening to *me* for over 20 years, and I'm still

                                finding that there are better ways.  We need to get this

                                expertise transmitted faster.  But we need to get the awareness

                                of a better way transmitted, or there's no driver for transmitting

                                expertise.

                                 

                                Paul Oldfield


                                __________ Information NOD32 1.1731 (20060830) __________

                                Ce message a ete verifie par NOD32 Antivirus System.
                                http://www.nod32.com
                              • Fred Beecher
                                Hi all, I ve been following the discussion on this list for a couple of weeks... I ve found it quite valuable, so thanks! On to my own contribution... ... The
                                Message 15 of 27 , Aug 30, 2006
                                  Hi all,

                                  I've been following the discussion on this list for a couple of
                                  weeks... I've found it quite valuable, so thanks!

                                  On to my own contribution...

                                  On 8/30/06, Jeff Patton <jpatton@...> wrote:
                                  >
                                  > The basic question might be: do we include UI people who are touching
                                  > code - html and css - as part of the development team? Do they
                                  > estimate? Do they put on their customer hat and decide how the
                                  > software should look and work, then put on their developer hat and
                                  > estimate it? Could their customer self argue with their developer
                                  > self? [picture scene from The Fight Club]

                                  The question of where UI design (UID) belongs in an organization is
                                  ancient and much agonized over. But the relative consensus is that, in
                                  most cases, UID does not belong under IT. In terms of this discussion,
                                  I see the development team as representing IT, so I would say, no, UI
                                  does not belong on the development team.

                                  Regarding hats, UIDs always have to wear two hats, the customer hat
                                  and the user hat. Our job is to ensure that business goals are met in
                                  a user-centric manner. Adding a third hat (the developer hat) is a
                                  recipe for overwork, bottlenecks, and burnout. Not to mention that
                                  getting a really good UID who also has really good coding skills would
                                  be a neat trick in itself.

                                  Any decent UID has *some* technical knowledge and the ability to
                                  understand more... we have to, because we design how the application
                                  interacts with its users. So it is the UID's responsibility to
                                  constantly communicate to and interact with the development team.
                                  "Here's what we're doing for this function... Can we accomplish XYZ
                                  this way?... What have you got so far?" etc. The best way I've found
                                  to do this is via one person, a tech lead, who is responsible for the
                                  overall development. This person is the interface between the business
                                  and design teams and the development teams. This is the person I would
                                  bug for technical feedback, status updates, design changes, etc., so I
                                  wouldn't have to interfere with developers' work.

                                  This setup has worked well for me in the past, and while it wasn't in
                                  an agile environment, I see no issues with integrating it into such an
                                  environment. I do have to stress, though, that
                                  communication between design and development is crucial for project
                                  success. Without that there is a high risk of failure.

                                  - Fred
                                • Tom Poppendieck
                                  Jeff - Your question could as well be asked with respect to QA, Business analysts, or Technical writers as with respect to UI people. I suspect it reveals a
                                  Message 16 of 27 , Aug 30, 2006

                                    Jeff –

                                     

                                    Your question could as well be asked with respect to QA, Business analysts, or Technical writers as with respect to UI people.  I suspect it reveals a weakness of the doctrine of customer team vs developer team.  It would be better to substitute the concept that there is ONE team which includes every person who will have work to perform whether that work is coding, testing, designing, writing, or researching.  For planning purposes, every person whose work and capacity need to be engaged estimates their own contributions.  The teams as a whole is committed to deliver the most valuable product it can each iteration.  Depending on their skills and knowledge, different individuals will take the lead in decisions in their areas but every member of the team contributes to each area when they can.  An overall lead, perhaps a product owner, a champion, a chief engineer maintains final influence in high level tradeoffs and maintaining focus on the overall vision.

                                     

                                    - Tom Poppendieck

                                     


                                    From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Jeff Patton
                                    Sent: Wednesday, August 30, 2006 3:00 PM
                                    To: agile-usability@yahoogroups.com
                                    Subject: [agile-usability] are UI people part of the development or customer team? -was Re: UI & user st...

                                     

                                    I'm changing thread names as ideas start to mutate to make them more
                                    intention revealing... .

                                    --- In agile-usability@ yahoogroups. com, PaulOldfield1@ ... wrote:

                                    > Is there any reason why UI designers could not become
                                    > developers, and vice-versa? That is, take on more and more
                                    > of the tweaks over time until the 'developer' is doing only
                                    > the architectural and 'heavy lifting' stuff?

                                    This is another puzzle that people doing UI and usability work in an
                                    Agile space often deal with.

                                    Customers specify the work that needs to be done. Development
                                    estimates and performs the work.

                                    Oftentimes UI people both specify and perform the work. Sometimes
                                    they act as the customer when specifying the work. Sometimes they act
                                    with the authority of the customer when doing so. Sometimes each
                                    suggestion they make is reviewed by the customer. If they have the
                                    customer's trust, often it isn't.

                                    The basic question might be: do we include UI people who are touching
                                    code - html and css - as part of the development team? Do they
                                    estimate? Do they put on their customer hat and decide how the
                                    software should look and work, then put on their developer hat and
                                    estimate it? Could their customer self argue with their developer
                                    self? [picture scene from The Fight Club]

                                    I'm sure there's lots of right answers, but I wonder what people have
                                    seen work?

                                    thanks,

                                    -Jeff

                                  • PaulOldfield1@aol.com
                                    (responding to Jon) ... I would distinguish between the breaking up of user jobs into tasks, and the design of individual task interactions. The former
                                    Message 17 of 27 , Aug 31, 2006
                                      (responding to Jon)
                                       
                                      > My experience is that the usability skills a person has often
                                      > (not always, but often enough) go out the window once that
                                      > person starts writing code. This is particularly the case when
                                      > the usability issue is not cosmetic (screen design) but
                                      > architectural (task design).
                                       
                                      I would distinguish between the breaking up of user jobs into
                                      tasks, and the design of individual task interactions.  The
                                      former should ideally be informed by system designers in
                                      order that sensible decisions can be made.  The latter is a
                                      task that could be undertaken by someone that had UI
                                      design and Usability skills - or by two people collaborating.
                                       
                                      I would expect the person that I denote as having UI design
                                      skills to be able to code the UI.
                                       
                                      Yes, sometimes one lot of skills 'goes out the window' when
                                      a new lot of skills are picked up.  I don't know why this is,
                                      but thankfully it isn't universal or we'd be in trouble.  At
                                      least this person should be able to understand the one
                                      who collaborates with him and employs the skills that
                                      he himself has lost.  By this process, he may regain the
                                      ability to think in the way he used to think, without losing
                                      the new skills.  I've also seen that happen.
                                       
                                      Paul Oldfield.
                                    • PaulOldfield1@aol.com
                                      (responding to William) ... seems to work for me and mine is the touchstone. Orthodox is something we use to train apprentices. ... I just find it unnatural
                                      Message 18 of 27 , Aug 31, 2006
                                        (responding to William)
                                         
                                        > "I thought we were only talking about X when I said two
                                        > points. I could probably change that to Y for the same
                                        > price, but adding Z will make it 3 points. Shall we just add a
                                        > new card for Z?"
                                        >
                                        > I'm not sure how orthodox that is, but
                                        it seems to work for
                                        > me and mine.
                                         
                                        "seems to work for me and mine" is the touchstone.  Orthodox
                                        is something we use to train apprentices.
                                         
                                        > And I think it's great when designers become more comfortable
                                        > with the raw material of their medium and the tools the
                                        > development team uses, so that a designer can work directly
                                        > on the things they care about. Likewise, close contact
                                        makes
                                        > learning this pretty natural.
                                        I just find it unnatural that a designer is unable to work the
                                        medium for which he is designing.  Surely this doesn't happen
                                        in many other places?  Civil engineering is a possible
                                        exception, but designing engineers and architects usually
                                        get their hands dirty early in their careers, and understand
                                        what's going on when they go on site.
                                         
                                        Paul Oldfield
                                      • Desilets, Alain
                                        Agreed. It would be nice to cut re-work costs as much as possible, but we have to accept *some* hit if we don t get it right first time. We want this cost
                                        Message 19 of 27 , Aug 31, 2006
                                          Message
                                           
                                          Agreed.  It would be nice to cut re-work costs as much as
                                          possible, but we have to accept *some* hit if we don't get
                                          it right first time.  We want this cost small so we don't try
                                          and go overboard to get it right first time. 
                                           
                                          -- Alain:
                                          Often (but not always), I find it cost more to get it right the first time, than it does to get it partially right and then correct that the second time.
                                          ---- 
                                           
                                        • Desilets, Alain
                                          IMHO, most developers have very little knowledge of usability yet they are tasked to design interfaces in most teams (well, at least in my experience). --
                                          Message 20 of 27 , Aug 31, 2006
                                            Message
                                            IMHO, most developers have very little knowledge of usability yet they are tasked to design interfaces in most teams (well, at least in my experience).  
                                             
                                            -- Alain:
                                            I agree. And most developers used to know little about testing. That has changed a lot with Agile. I'm hoping we can effect a similar change of mindset for usability.
                                            ----
                                             
                                             A little knowledge would at least remove some of the most basic errors.  It’s not more work, it’s about having skilled people do the work. And we’re not talking about subtle rocket

                                            (Message over 64 KB, truncated)
                                          • Desilets, Alain
                                            ... I just find it unnatural that a designer is unable to work the medium for which he is designing. Surely this doesn t happen in many other places? Civil
                                            Message 21 of 27 , Aug 31, 2006
                                              Message
                                              > And I think it's great when designers become more comfortable
                                              > with the raw material of their medium and the tools the
                                              > development team uses, so that a designer can work directly
                                              > on the things they care about. Likewise, close contact makes
                                              > learning this pretty natural.
                                              I just find it unnatural that a designer is unable to work the
                                              medium for which he is designing.  Surely this doesn't happen
                                              in many other places?  Civil engineering is a possible
                                              exception, but designing engineers and architects usually
                                              get their hands dirty early in their careers, and understand
                                              what's going on when they go on site. 
                                               
                                              -- Alain:
                                              Wait a minute... architects don't lay bricks do they?
                                              ----
                                            • William Pietri
                                              ... Personally, I d agree. Good print designers have an eerie knowledge of the minutiae of printing processes. It seems weird to me that a number of people who
                                              Message 22 of 27 , Aug 31, 2006
                                                PaulOldfield1@... wrote:
                                                > > And I think it's great when designers become more comfortable
                                                > > with the raw material of their medium and the tools the
                                                > > development team uses, so that a designer can work directly
                                                > > on the things they care about. Likewise, close contact makes
                                                > > learning this pretty natural.
                                                > I just find it unnatural that a designer is unable to work the
                                                > medium for which he is designing. Surely this doesn't happen
                                                > in many other places? Civil engineering is a possible
                                                > exception, but designing engineers and architects usually
                                                > get their hands dirty early in their careers, and understand
                                                > what's going on when they go on site.
                                                >

                                                Personally, I'd agree. Good print designers have an eerie knowledge of
                                                the minutiae of printing processes. It seems weird to me that a number
                                                of people who sell themselves as web designers don't die of
                                                embarrassment when it turns out they don't know a thing about HTML. I
                                                certainly rarely like their work, and I never like implementing it.

                                                William
                                              • PaulOldfield1@aol.com
                                                (responding to Alain) ... Not as a matter of course (and you get to decide whether the pun was intended). However, the Civil Engineers alongside me at
                                                Message 23 of 27 , Aug 31, 2006
                                                  (responding to Alain)
                                                   
                                                  > Wait a minute... architects don't lay
                                                  bricks do they?
                                                   
                                                  Not as a matter of course (and you get to decide whether
                                                  the pun was intended).
                                                   
                                                  However, the Civil Engineers alongside me at University
                                                  had to mix and pour concrete; the architects had to
                                                  build a brick arch.  Maybe other educational establishments
                                                  don't include this.  All the architects I know could pitch
                                                  in and give a hand but would normally leave it to those
                                                  who practice the skills regularly.
                                                   
                                                   
                                                  Paul Oldfield
                                                • Ron Jeffries
                                                  Hello Tom, thank you for the email quoted here. On Wednesday, August ... Kent Beck used to say that he considered the customer/programmer split in XP to be a
                                                  Message 24 of 27 , Aug 31, 2006
                                                    Hello Tom, thank you for the email quoted here. On Wednesday, August
                                                    30, 2006, at 10:44:11 PM, you wrote:

                                                    > Your question could as well be asked with respect to QA, Business analysts,
                                                    > or Technical writers as with respect to UI people. I suspect it reveals a
                                                    > weakness of the doctrine of customer team vs developer team. It would be
                                                    > better to substitute the concept that there is ONE team which includes every
                                                    > person who will have work to perform whether that work is coding, testing,
                                                    > designing, writing, or researching. For planning purposes, every person
                                                    > whose work and capacity need to be engaged estimates their own
                                                    > contributions. The teams as a whole is committed to deliver the most
                                                    > valuable product it can each iteration. Depending on their skills and
                                                    > knowledge, different individuals will take the lead in decisions in their
                                                    > areas but every member of the team contributes to each area when they can.
                                                    > An overall lead, perhaps a product owner, a champion, a chief engineer
                                                    > maintains final influence in high level tradeoffs and maintaining focus on
                                                    > the overall vision.

                                                    Kent Beck used to say that he considered the customer/programmer
                                                    split in XP to be a flaw, but that he couldn't see a way to get rid
                                                    of it.

                                                    While I agree that what we want is the "Whole Team" notion you
                                                    describe here, with everyone chipping in, it seems to me that in
                                                    addition to some (possibly "natural") leader like you describe,
                                                    today's business environment typically identifies an individual with
                                                    "product responsibility". That individual, being held responsible to
                                                    someone "upstairs", probably really needs authority consistent with
                                                    that responsibility.

                                                    And, as is always best with leadership, the best situation will be
                                                    that they actually exercise that authority very seldom with respect
                                                    to what the team does.

                                                    It's a mystery, I guess ...

                                                    Ron Jeffries
                                                    www.XProgramming.com
                                                    If we're not shipping our software when it's ready,
                                                    it's poor business practice.
                                                    If we're not sure whether our software is ready,
                                                    it's poor software practice.
                                                    http://www.xprogramming.com/blog/Page.aspx?display=FrequentReleases
                                                  • Desilets, Alain
                                                    (responding to Alain) ... Not as a matter of course (and you get to decide whether the pun was intended). However, the Civil Engineers alongside me at
                                                    Message 25 of 27 , Aug 31, 2006
                                                      Message

                                                       
                                                      (responding to Alain)
                                                       
                                                      > Wait a minute... architects don't lay bricks do they?
                                                       
                                                      Not as a matter of course (and you get to decide whether
                                                      the pun was intended).
                                                       
                                                      However, the Civil Engineers alongside me at University
                                                      had to mix and pour concrete; the architects had to
                                                      build a brick arch.  Maybe other educational establishments
                                                      don't include this.  All the architects I know could pitch
                                                      in and give a hand but would normally leave it to those
                                                      who practice the skills regularly.
                                                       
                                                       
                                                      Paul Oldfield 
                                                       
                                                      -- Alain:
                                                      Right. So UI designers don't have to design in HTML and CSS as long as they have some grasp of what HTML and CSS can and can't do, which is what I was trying to point out.
                                                      ---- 
                                                    • Jim Kauffman
                                                      ... When the division of Siemens I used to work for decided to go Agile, they included the concept of a shusa (see http://www.poppendieck.com/leadership.htm)
                                                      Message 26 of 27 , Aug 31, 2006
                                                        > -----Original Message-----
                                                        > From: agile-usability@yahoogroups.com
                                                        > [mailto:agile-usability@yahoogroups.com] On Behalf Of Ron Jeffries
                                                        > Sent: Thursday, August 31, 2006 1:16 PM
                                                        > To: agile-usability@yahoogroups.com
                                                        > Subject: Re: [agile-usability] are UI people part of the
                                                        > development or customer team? -was Re: UI & user st...
                                                        >
                                                        > Kent Beck used to say that he considered the
                                                        > customer/programmer split in XP to be a flaw, but that he
                                                        > couldn't see a way to get rid of it.
                                                        >
                                                        > While I agree that what we want is the "Whole Team" notion
                                                        > you describe here, with everyone chipping in, it seems to me
                                                        > that in addition to some (possibly "natural") leader like you
                                                        > describe, today's business environment typically identifies
                                                        > an individual with "product responsibility". That individual,
                                                        > being held responsible to someone "upstairs", probably really
                                                        > needs authority consistent with that responsibility.
                                                        >
                                                        > And, as is always best with leadership, the best situation
                                                        > will be that they actually exercise that authority very
                                                        > seldom with respect to what the team does.
                                                        >
                                                        > It's a mystery, I guess ...
                                                        >
                                                        > Ron Jeffries

                                                        When the division of Siemens I used to work for decided to go Agile, they
                                                        included the concept of a "shusa" (see
                                                        http://www.poppendieck.com/leadership.htm) to provide leadership to the Scrum
                                                        teams. I don't know what the result has been.


                                                        -Jim Kauffman
                                                      • Jeff Patton
                                                        ... analysts, ... reveals a ... I agree. When things start going wrong when building a product it often does turn literally into customer team vs. developer
                                                        Message 27 of 27 , Aug 31, 2006
                                                          --- In agile-usability@yahoogroups.com, "Tom Poppendieck" <tom@...>
                                                          wrote:
                                                          > Your question could as well be asked with respect to QA, Business
                                                          analysts,
                                                          > or Technical writers as with respect to UI people. I suspect it
                                                          reveals a
                                                          > weakness of the doctrine of customer team vs developer team.

                                                          I agree.

                                                          When things start going wrong when building a product it often does
                                                          turn literally into customer team vs. developer team.

                                                          It is interesting how XP as a process has permeated agile
                                                          development. That customer team development team structure is now
                                                          common. Story driven development is common. XP style estimation and
                                                          velocity tracking is common. Scrum style burn down charts have
                                                          wormed their way in. That customer/developer divide seems here to
                                                          stay leaving lots of other roles left to "choose sides."

                                                          Of course it shouldn't be that way, and on healthy teams it isn't.

                                                          I'll stop short of asking if there's anything that should change
                                                          about XP - or if something about XP causes this divide... since I'm
                                                          not really prepared to think about the answer. ;-)

                                                          Thanks,

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