Tuesday, June 12, 2007

User Research: Being smart, being practical

In Design School we were taught how to go about User Research in a thorough and meticulous fashion. In real life in the industry, there is seldom time for that. One usually comes up with good-enough short cuts which work.


I have done extensive User Research with SAP customers in India and have realized some marked differences in the way we used to do it in back in the Design School. The reason of this difference seems to be two-fold:

  1. Shortage of time to do something elaborate
  2. The difference in the domain and the user group itself (Enterprise product versus Consumer products I was used to working on before)

Some smart moves during User Research (in the Enterprise domain) are:

1. Identify appropriate customers and interviewees

Creating ‘Test Participant Profile’ not ‘Personas’

A TPP is a shorter, more focused version of a Persona, covering only:

  • Role Names and Functions
  • Business Tasks
  • Skills
  • Software Expertise

Simply because creating a whole persona is very time-consuming and factors like a user’s name, social profile etc. has little or no bearing on his work profile in a Business Software usage context. Further, it can be safely assumed that the users belong to a narrow group with a certain educational background, proficiency and skill level.

This is in contrast to gathering User data for Consumer software (like mail, ticket booking software etc) where a broader range of information consisting of a user’s social profile, interests etc. is required, simply because the user group is so large and varied and a user’s overall profile does affect his usage of such software

2. Having diversity in your ‘Interviewee group’

Suppose we interview users in 2 companies:


Company A: 10 to 50 employees
User roles not so defined; 1 user managing multiple roles
Not very refined processes, crude workarounds to problems


Company B: 500 to 2000 employees
Very streamlined user roles; 1 user managing only 1 role
Very refined processes, sophisticated workarounds (in house developed tools)

Therefore, not surprisingly, the data collected from the 2 sets of users is very varied and the user requirements widely different.


In such a case, during synthesis of this research, the data from these 2 companies should not be combined, as it will distort the data, which will not hold true for any scenario.


In this case, providing Customization at the user’s end is the optimum solution

No comments: