Takeaway: Clients and users are not always the same entity. Clients pay for the product. Users use the product. Clients and users can have different success criteria for your product.
Clients and users may not always have overlapping needs. Clients and users can have different success criteria for your product.
As the client, I may care about:
* showing value for the money spent on your software
* did the purchase save significant staff time and budget?
* did the purchase contribute to visible wins?
* did the product fit in my roadmap and align with my strategy?
As the user, I may care about:
* feeling enabled, smart and efficient
* did the software make me better at my job?
* did the software help me look good in front of my manager?
* did the software make it easy for me to glean critical insights?
* did the software reduce the amount of grunt work I need to do?
* is the software fun to use?
Key point: When clients and users are different, it is not sufficient to satisfy the needs of only one group. Your product should try to strike a balance between catering to the needs of the clients and the needs of users. Client-user balance is a key indicator of how the product ‘quality’ is perceived.
NOTE: There are cases where there is a large (or even complete) overlap of client and user needs from a product. See the examples section for more details
How does understanding the client-user balance make me a better tester?
Being mindful of users and clients has multiple benefits. Understanding client-user balance increases my awareness of the context under which I am testing software. I have found trying to verbalize new features in the context of client-user balance helps everyone in my team:
1. design better tests
2. appreciate product strategy and roadmaps better
3. provide better input right from the planning stage
4. form better perceptions of risk
5. prioritize tests better
Anytime I am confronted with a new piece of software to test, I ask myself “who is the client?”, “who is the user?”. I invariably come up with acceptance tests, identify potential pain-points and get a sense of the maturity of the product under test.
Example 1: your company makes games for kids: Your user is the kid who wants to have fun. Your client i.e., the one who pays for the product, is the parent. Parents probably want the game to be educational, safe and engaging. Your product should try to balance the needs of both the parents and the kids.
Example 2: your company sells software to a large enterprise: Chances are high that your user and client are two very different people. The client could be the CIO, while the users could be the folks in HR. Your client may not necessarily care, or even know, about your latest UI overhaul. Your users will be grateful for a new UI!
Example 3: your company sells ad-space and attracts users by providing a useful feature like say, search (hello, Google!): Your client does not care about improvements to search as long as it gets them more impressions and clicks. Your users care about the quality of the search!
Example 4: your company sells a specialized debugger for one man consultancies: Your user and client are one and the same here!
What affects the client-user balance?
Some factors that affect the client-user balance:
a) Size of the customer
hint: the smaller the size of the customer, the better the relation between the client and user
b) Maturity of your product
hint: early stage products usually need to appeal to the client first – unless you have deep pockets
c) Uniqueness of your product
hint: harder the problem or higher the quality of your solution, the more you can get away with catering to the client
d) Product loyalty
hint: Niche products have rabid fan bases and (on average) have higher tolerance for low usability
Identify your client and your user. Describe what each of them care about. Is your software balanced and catering well to both the client and the user? How did the factors listed above play into your company’s business strategy?
Artwork courtesy: Edward Alan
© 2013-2017, Arunkumar Muralidharan. All rights reserved.