Users and Customers
02 March 2008
I was interested to read an article on possible future financial models for the Internet telephony provider, Skype. The auction site, eBay, bought Skype in late-2005. The problem facing eBay is how to persuade those that have signed-up to Skype's free telephony services to subscribe to enhanced, fee-based services. One of the comments relating to the article made the telling observation that “the problem is the valuation of $2.6bn - when will investors learn that users are not the same thing as customers” (my emphasis).
It started me thinking on how software development practitioners refer to those people who directly interact with software systems. Most of the time, they are referred to as rather dismissively as “users”. It’s this term that gives the impression that they freeloaders, just “using” the system, rather than customers who have paid for it. More tongue-in-cheek, it’s been pointed out that the only other class of people labelled this way are those that take illegal drugs.
However, to use the word “customer” for software development projects risks ambiguity. In casual conversation, a customer is someone who both chooses goods or services and pays for them. In software development projects, it’s often the case that these activities are split between two different people. (In XP, these roles are informally-labelled the goal-donor and the gold-owner). More conventionally, though, the budget-holder is known as the sponsor.
So what is the best term to use for those people who define the human interaction with the system? Other suggestions have been “functional beneficiaries” – this describes the role well but this is a bit of a mouthful. What about “stakeholders”? Well, this is probably best reserved as a term to describe all those that have an interest in the system (including indirect interests such as regulatory bodies).
Which leaves us with a bit of problem. I have tried to introduce the term "interactors" - because they interact directly with the system - but this has lead to confusion over the term "actor" which is used in use case techniques. So it looks as if we are left with the long-but-worthy "functional beneficiary" or the short-but-condescending "user".