Customer vs User
Jason Che-han Yip
user has an originating reference?
Customer - pays for product but does not necessarily use it
User - uses product
--
Graduate Student, SE Lab, University of Calgary,
http://www.sern.enel.ucalgary.ca/yip
----
XP2000 - June 21-23, 2000
eXtreme Programming and Flexible Processes in Software Engineering
http://www.spe.ucalgary.ca/extreme
Darren Collins
>Does anyone know whether the concept of separating the customer vs the
>user has an originating reference?
>
>Customer - pays for product but does not necessarily use it
>User - uses product
>
without knowing what it does or what it's for (I think they only look at the
price and the pictures on the box), and I'm expected to use it to become
more efficient :-)
Sorry, couldn't resist. I don't have a sensible answer for you.
Darren Collins
Editor, CodeCraft - The C++ Newsletter
http://www.cyberelectric.net.au/~collins
troyer
Government procurement where there is an acquisition agent charged with
acquiring the product and then passing it on to the end user(s).
This situation arose because of the complexity of Federal Acquisition
Regulations and public laws. The acquisition agencies are specialists
in navigating the bureaucratic maze. Unfortunately, they occasionally
lose contact with the end user and wind up with a product that doesn't
really satisfy anyone.
Jason Che-han Yip wrote:
>
> Does anyone know whether the concept of separating the customer vs the
> user has an originating reference?
>
> Customer - pays for product but does not necessarily use it
> User - uses product
>
> --
> Graduate Student, SE Lab, University of Calgary,
> http://www.sern.enel.ucalgary.ca/yip
> ----
> XP2000 - June 21-23, 2000
> eXtreme Programming and Flexible Processes in Software Engineering
> http://www.spe.ucalgary.ca/extreme
--
Tom Royer
Lead Engineer, Software Test
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
Voice: (781) 271-8399
FAX: (781) 271-8500
tro...@mitre.org
"If you're not free to fail, you're not free." --Gene Burns
Jason Che-han Yip
>
> I don't have a specific reference, but the practice is common in
>
> Government procurement where there is an acquisition agent charged with
>
> acquiring the product and then passing it on to the end user(s).
>
>
>
> This situation arose because of the complexity of Federal Acquisition
>
> Regulations and public laws. The acquisition agencies are specialists
>
> in navigating the bureaucratic maze. Unfortunately, they occasionally
>
> lose contact with the end user and wind up with a product that doesn't
>
> really satisfy anyone.
necessarily represent the end-user very well. This leading to
user-centred design and all that. I was wondering if there was some
initial publication that started it all.
>
>
>
>
>
>
David Alex Lamb
Jason Che-han Yip <jch...@ucalgary.ca> wrote:
>Actually I was referring more to realizing that the "customer" does not
>necessarily represent the end-user very well. This leading to
>user-centred design and all that. I was wondering if there was some
>initial publication that started it all.
By now most of us probably don't remember. I picked up the idea by reading
"Managing Software Projects" by Francois Lustman back in the mid-1980's but it
was probably a well-established idea by then.
Have you tried tracking down the oldest 'user-centred design' paper you can
find and see what they reference?
--
"Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5
http://www.cs.queensu.ca/~dalamb/
Andrew Gabb
> Does anyone know whether the concept of separating the customer vs the
> user has an originating reference?
>
> Customer - pays for product but does not necessarily use it
> User - uses product
I think this was always known by some at least. See also big
(sometimes blue) companies that found that targeting the users was
not the way to wealth. It worked for a while.:=)
There are numerous articles that address this implictly or
explicitly, but I've not seen one that only addresses it. I tend to
use 'customer' to mean the full customer organisation, and then use
the following to split up the subgroups: user, acquirer, supporter,
sponsor (who actually gets the money approved). Many are actually
requirements engineering papers, because it is often in the
requirements that these roles get confused (or conflict).
You might find my paper 'Requirements Denial - Examining the
Excuses' useful (http://www1.tpgi.com.au/users/agabb/).
Andrew
--
Andrew Gabb
email: ag...@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021, fax: +61 8 8269-3280
-----
Ken Foskey
>
> Does anyone know whether the concept of separating the customer vs
> the user has an originating reference?
>
> Customer - pays for product but does not necessarily use it
> User - uses product
I just picked up a good description of this in a requirements template
on:
http://www.systemsguild.com/GuildSite/Robs/Template.html
Paraphrasing:
Client: Where the initial money comes from.
Customer: Who buys the resulting product.
User: Who uses the product.
Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/
Jason Che-han Yip
> I just picked up a good description of this in a requirements template
> on:
>
> http://www.systemsguild.com/GuildSite/Robs/Template.html
>
> Paraphrasing:
>
> Client: Where the initial money comes from.
> Customer: Who buys the resulting product.
> User: Who uses the product.
Thanks for the reference. I read it more like this:
Client: Person or organization that is paying the developers
Customer: Person or organization that is paying the Client for the Product
User: Person who will use the Product