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

Re: [agile-usability] are UI people part of the development or customer team? -was Re: UI & user st...

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