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

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

Expand Messages
  • Jon Meads
    From: aacockburn [mailto:acockburn@aol.com] ... . . . ... Jon, may I take it that you are using the word customer consistently here, so that you intend:
    Message 1 of 17 , Nov 30, 2004
    • 0 Attachment
      From: aacockburn [mailto:acockburn@...]
      --- In agile-usability@yahoogroups.com, "Jon Meads" <jon@u...> wrote:
      > 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.
      . . .
      > 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.

      Jon, may I take it that you are using the word "customer"
      consistently here, so that you intend:
      " 'the person who is making the purchase, the one who recommends or
      makes the purchase decision and/or authorizes the purchase expense'
      is always right, no matter how wrong." ?

       With appropriate exceptions. I've had situations where the person who made the purchase decision was replaced by another person just before a project started. Which implies that roles are important for customers as well as users. But basically, it is the person(s) who have purchasing responsibility that have objectives and who are expecting a return in value. A good customer, like a good boss, will state the objective and what value is expected and will let you do what you need to as a professional to deliver. But most customers are people and few are perfect.
       
      The critical thing to remember is that the customer is not always the user and, in order to meet the customer's objectives and provide the desired value, it is often a requirement to design with the user in mind. An example, the customer is concerned about productivity and believes that a redesign of the system can improve productivity.
       
      You do the contextual (user, environment, and domain) studies and see several possible solutions. Solution A will improve productivity by 30% but will increase training time and costs by 100%. It is also likely to increase turnover because users are unlikely to be satisfied with it. Solution B will improve productivity by 20% and will increase training time and costs by 50%. It is unlikely to affect turnover. Solution C will improve productivity by 10% and will increase training time and costs by 25% but will make the users more satisfied with their work, thereby reducing turnover significantly. There is no question that the users would prefer Solution C but A or B may be more in keeping with the customer's objectives and value requirements.
       
      And then there may be Solution D, which the customer wants that improves productivity by 50% and training by 200% and causes users to quit immediately after they are trained. You have a difficult decision if the customer insists on Solution D as much as you try to explain the folly of it. You have started the project but don't want to complete it as the customer is likely to blame you for the result.
       
      I think the above example illustrates the difference between customer and user and the customer being "always right".
       
      Cheers,
      jon
       

                 Jon Meads
                 Usability Architects, Inc.
                 PO Box 3222
                 Kirkland, WA 98083-3222
       
          Voice: 425-827-9296
           Cell: 206-409-7548
            Fax: 425-827-6692
          Email: jon@...
       
         Specialists in User-Centered Design & Engineering
             http://www.usability-architects.com/


    • 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 2 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 3 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 4 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 5 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 6 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.