Please, you may refer to me as ‘Patient’
In developing for enterprises I define 3 categories of ‘users’:
- End-user: the person who is actually working with a product on a daily basis;
- Experts: person who is considered by the enterprise as an expert in the field and is either the decision maker or influences the decision making;
- Customer: an entity (e.g. the enterprise ) which will ultimately foot the bill and is the main driver behind the purchase of a product.
Now all three types of users use a product in a different way but they are equally relevant. The End-user uses a product more directly. For the Expert the product would be more a means to an end. The Customer in this definition wants a Return On Investment (ROI).
All three users have legitimate uses for a product and must be considered when developing. However, when it is time to set priorities these three different uses might become a muddle.
Example: some business analytics tools come packed with shiny dashboards and gauges. The Customer would be pleased with exposing business critical information. The Experts is satisfied with the prospect of solving a business need. The End-user is – in this example: the person needed to input data in order for the analytics to work – livid with anger and frustration.
The causes may vary from no process in place to produce data to feed the tool, the tedious fashion for inputting or importing data or complex configurations to get information into the dashboard as required. In any case, being the End-users will feel more like a Patient, begging for a cure from a Doctor.
Traditionally, enterprise tools have put more empathize on the Expert and the Customer and who could blame them?
Who’s this feature for?
For knowledge portal development these user roles are somewhat similar with one important distinction: the End-user has by far more power and influence.
For instance, in a legal market these roles would probably translate into the following types:
- End-user: Attorneys, Librarians;
- Experts: Knowledge Manager, Information Officer;
- Customer: Law Firm.
Hereby the End-user does the actual information retrieval (searching & browsing) on a daily basis. The Experts monitors the comprehensiveness, proficiency, and efficiency for the Customer who sees that as its ROI.
Now comes the hard part: Who do you focus on when developing knowledge tools or services? Especially when features request keep piling on and requirements keep coming in. A specific feature might benefit all three equally but that will not always the case. One must always strive to satisfy all three users but if deadline pressures mount (or common sense prevails) you’re likely being forced to choose.
For example, a feature, which is perceived to be crucial for End-users, might raise the cost of a product tremendously which in turn isn’t beneficiary to either Expert or Customer.
User Intimacy
Much to the chagrin of IT, Security and Compliance consumer devices and services e.g. iPhone, Google Docs, WordPress, and Dropbox have been making inroads into enterprises by way of End-users. These tools have in common that they are squarely aimed at them and not Customers. I will not venture and say that they have a really inmate relationship with their users but they do have succeeded in pleasing a lot of them. Enterprise tools have a spotty record in that regard and – in some cases- have been forced to make way for these competitors. A trend started by influential End-users that have been pleading their case for fewer restrictions and more convenience resulting in productivity. We’ve all received corporate emails signed “Send from my iPad” knowing full well that iOS is not supported in your enterprise.
It might not be easy spotting End-users gains as oppose to those for Expert or Customer, but betting on them will surely pay off in the End.