RE: [agile-usability] Re: Customer vs user
- From: aacockburn [mailto:acockburn@...]
--- In firstname.lastname@example.org, "Jon Meads" <jon@u...> wrote:
> community considers the customer tobe the person who is making the
> purchase, the one who recommends ormakes 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 customeris 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
MessageNot 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=9401E3DC1E3CF932A25752C1A9629C8B63So, 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 Messagejust 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.---- MessageJust my $02.Users are those that actually use the softwareClients are those that pay us some moneyCustomers are those *on my team* that speak for the users and clientsDan ;-)
Dan Rawsthorne, PhD, Sr. Consultant
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
Subject: RE: [agile-usability] Re: Customer vs userjust 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
- 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:
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
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 Pietri <william@...>
- 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.
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.