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

RE: [agile-usability] Re: Customer vs user

Expand Messages
  • Myhill, Carl S (GE Energy)
    Not sure I get the problem with this customer and user thing but as Josh says, this is an essential distinction to make. I guess the context of your work can
    Message 1 of 17 , Dec 1, 2004
    • 0 Attachment
      Message
      Not sure I get the problem with this customer and user thing but as Josh says, this is an essential distinction to make. I guess the context of your work can confound clarity.
       
      If you are amazon.com for example, your customer and your user are the same person, so that's nice and easy.
       
      In what I do, working on designing large systems for corporates, I regard the customer as the 'business visionaries' with purchasing power. Marketing folks need to understand what the customers in the market are demanding, in order to shape our products such that they will sell to those with purchasing power.
       
      Users, are often unrepresented people who work in the businesses headed up by these business visionaries. Sometimes a 'super user' will get involved in specification of a new system but typically these super users are themselves unrepresentative. The regular people normally get no say about the software at all, in this context, until it arrives on their desk. But when it hits their desk, only then do they suddenly become empowered and can turn around and say "we can't use this". Acceptance problems, software rejected, etc.
       
      For example NY Times Article - Wanted by the Police: A Good Interface ( November 11, 2004 ) http://tech2.nytimes.com/mem/technology/techreview.html?res=9401E3DC1E3CF932A25752C1A9629C8B63 
       
      So, I see marketing folks interested in customers; and ucd folks interested in users. Often the needs of these two groups in my context are in conflict, and that needs to be hammered out, with the customers having the upper hand of course; but with us listening to users because we don't want acceptance failures.
       
      Well, this is my model for my context anyway.
       
      Carl
    • Desilets, Alain
      just about everyone I know in that community considers the customer to be the person who is making the purchase, the one who recommends or makes the purchase
      Message 2 of 17 , Dec 1, 2004
      • 0 Attachment
        Message
        just about everyone I know in that community considers the customer to be the person who is making the purchase, the one who recommends or makes the purchase decision and/or authorizes the purchase expense.
         
        -- Alain:
        In an in-house development setting, the customer could also be the person who commisionned the system to be built.
        ----
         
        Regardless of our desires to design for the user, the Golden Rule ("them that has the gold makes the rules") specifies that the customer is always right, no matter how wrong. As a professional, I have a responsibility to educate and communicate when I think that customer may be making an error but if I'm taking their money, I'm going to do as they ask. 
         
        -- Alain:
        Very concisely and eloquently put.
        ---- 
      • Dan Rawsthorne
        Just my $02. Users are those that actually use the software Clients are those that pay us some money Customers are those *on my team* that speak for the users
        Message 3 of 17 , Dec 1, 2004
        • 0 Attachment
          Message
          Just my $02.
            Users are those that actually use the software
            Clients are those that pay us some money
            Customers are those *on my team* that speak for the users and clients
           
          Dan  ;-)

          Dan Rawsthorne, PhD, Sr. Consultant
          www.netobjectives.com
          DrDan@...
          office:
          425-269-8628

          Net Objectives' vision is effective software development without suffering. Our mission is to assist software development teams in accomplishing this through a combination of training and mentoring.

           


          From: Desilets, Alain [mailto:alain.desilets@...]
          Sent: Wednesday, December 01, 2004 6:15 AM
          To: 'agile-usability@yahoogroups.com'
          Subject: RE: [agile-usability] Re: Customer vs user

          just about everyone I know in that community considers the customer to be the person who is making the purchase, the one who recommends or makes the purchase decision and/or authorizes the purchase expense.
           
          -- Alain:
          In an in-house development setting, the customer could also be the person who commisionned the system to be built.
          ----
           
          Regardless of our desires to design for the user, the Golden Rule ("them that has the gold makes the rules") specifies that the customer is always right, no matter how wrong. As a professional, I have a responsibility to educate and communicate when I think that customer may be making an error but if I'm taking their money, I'm going to do as they ask. 
           
          -- Alain:
          Very concisely and eloquently put.
          ---- 


          ______________________________________________________________________
          This email has been scanned by the MessageLabs Email Security System.
          For more information please visit http://www.messagelabs.com/email
          ______________________________________________________________________
        • William Pietri
          Hi! Sorry for joining this thread late, but I was on vacation. ... Two small notes: First, I suspect that this use of customer comes from TQM jargon:
          Message 4 of 17 , Dec 3, 2004
          • 0 Attachment
            Hi! Sorry for joining this thread late, but I was on vacation.

            On Wed, 2004-12-01 at 09:48 +1300, Keith Nicholas wrote:
            > I've never liked "customer" as the name for the role in XP. But its
            > hard to come up with a better word.

            Two small notes:

            First, I suspect that this use of "customer" comes from TQM jargon:

            http://quality.org/TQM-MSI/TQM-glossary.html

            I was exposed to this when the University of Michigan's Information
            Technology Division went through a TQM phase. My recollection is hazy,
            but I'm pretty sure the TQM experts involved in that had some sort of
            history with Chrysler.


            Second, I avoid using the term "customer" except with people already
            steeped in XP; because "customer" already has a common meaning, it can
            be confusing.

            Generally the term I use is "product manager". I like this because it
            puts the focus on what we are doing -- making a product for others to
            use. In contrast, terms like "project manager" and "development manager"
            focus more on the methods we use in pursuit of the goal.

            William

            --
            William Pietri <william@...>
          • Charlie Trainor
            I m happy with the term Customer , but if you don t like that I suggest the Scrum role Product Owner . In different situations this might be a Product
            Message 5 of 17 , Dec 4, 2004
            • 0 Attachment
              I'm happy with the term "Customer", but if you don't like that
              I suggest the Scrum role "Product Owner". In different situations
              this might be a Product Manager, an end user, a business expert,
              or even a committee - whoever makes the decisions on what the
              development team builds.

              Currently I'm playing the Product Owner role, even though there
              is also someone with the title of Product Manager, various
              business experts, partners, end users, and other stakeholders.
              I seek input from all of them, and some of them have a lot of
              influence over me, but in the end I'm the single hand on the
              development team's steering wheel.

              Since this is an agile usability list - but I've lost track of the
              original post that started all this - I'll just point out that
              Product Owners need to be able to weigh the costs and benefits of
              usability-related activities, just like other development activities.
              If there is a usability professional available, that person
              would be one of the experts providing input into the decision
              making process. The biggest risk (for me currently, but also
              quite a common problem) is not getting enough feedback from
              end users. But at least it is clear that it will be my fault
              if the usability of the product isn't up to scratch - we can't
              point fingers at each other and wonder who was supposed to
              worry about it.

              - Charlie

              William Pietry wrote:

              > Second, I avoid using the term "customer" except with people already
              > steeped in XP; because "customer" already has a common
              > meaning, it can be confusing.
              >
              > Generally the term I use is "product manager". I like this
              > because it
              > puts the focus on what we are doing -- making a product for
              > others to
              > use. In contrast, terms like "project manager" and
              > "development manager"
              > focus more on the methods we use in pursuit of the goal.
            Your message has been successfully submitted and would be delivered to recipients shortly.