“Alarm Bells” in User Research

I have gone to many big SAP customers in India for User Research and there are a few things i have learnt to be wary of when going to big Organizations for User Research:

• Set the expectations right beforehand itself. You haven’t gone to talk about new features in the upcoming releases, you aren’t from Marketing, you aren’t there to provide Technical support. Too much time gets wasted till they actually understand the purpose of your visit.
  

• Guard against spending too much time in the Boardrooms. As I have come to realize, nothing worthwhile is ever achieved in Boardrooms. :) Go to where the user actually sits. His workplace can speak volumes.

• Be on your alert when the user starts using phrases like ‘usually…’, ‘in our company..’, ‘in general…’, ‘normally…’. Ask him specifically as to how HE does the task or better still, ask him to show it to you. There might be differences in the way he says he works and how he actually works.

• Be careful as to who is watching the user perform the task…his Manager, IT Staff… it changes the way he will interact with the system

Similarly, do not interview the User in front of his superior. It will tone down his responses regarding the difficulties he faces with your software or the workaround he uses to get his job done.

• Write down beforehand high-level ‘Bullet Points’ regarding questions you would really like answered. Otherwise, if you only ask him to run you through a task on a system, you might only end up doing Usability Bug-fixing.

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