One of the cheapest and most flexible User Experience research methods, user interviews are used in many phases of the design process to gather information from stakeholders, users, and subject matter experts. When designing an interview, I want to make sure I am using them to learn about what users think about a site, an application, a product, or a process.
In this article, I want to focus on the most common (and in my opinion, the most useful) time I use user interviews — at the very beginning of the design process. In the case of the application I am currently working on — a mobile employee performance tracker — I want to design my interviews to inform personas, journey maps, feature ideas, and workflow ideas.
Interviewers & Interviewees
My first interview will be with the main stakeholder for the project. We have arranged to have the interview in person, and for the interview to last 45 minutes.
Occasionally, I have had multiple stakeholders or users in an interview, but these interviews then become focus groups. Because focus groups have multiple users, subject matter experts, or stakeholders involved, they have different goals and rules as to what is the most effective way to get useful information out of the meeting.
I have also had multiple members from my team in the meeting, where there are multiple people interviewing the interviewee, taking turns asking questions. This method for user interviews can also be effective, and allows for more team collaboration on the project. If there is going to be more than one interviewer, it is important to touch base before the interview to make sure the goals for the outcome of the interview are aligned.
In order to ensure the success of my first user interview for this project, I want to set a realistic, specific goal for what I want to learn from the stakeholder. I want the interview to feel like a research study, not an informal conversation.
Goals for user interviews should be concise. The information collected during the interview should be relevant to the design needs. Making an interview goal too broad, like learn about users, may make an interview fail because it may not result in specific enough design directions. Keeping the goal specific and realistic, related to the stakeholder’s behavior and attitudes about how employee performance is currently tracked, and how this mobile application can improve that process, should direct how I construct the interview.
For this interview, I already know that this employee tracker app is aimed to improve morale and improve employee performance. My goal is to find out how this mobile employee tracker app can be designed in a way that will improve employee performance and lead to higher employee satisfaction, and where there are opportunities for the mobile app to integrate seamlessly into the employee workday.
We can break down my main goal into several smaller, sub-goals aimed at informing our personas, journey maps, feature ideas, and workflow ideas.
Asking the Right Questions
A question list ensures that both parties will get the most out of the time spent sitting together. For my question list, I also want to get feedback from my team on my question list before I sit down with the stakeholder. I’m also less likely to forget important questions, I’m able to construct clear, non-leading questions, and I reduce my stress levels by having questions on hand to refer to.
To prepare for the interview even further, I want to anticipate different answers to my questions and come up with some follow up questions based on my research goals. This is important if we come to a question the stakeholder does not have an answer to, or if I come across new information about the process that I didn’t know previously. Examples of follow up questions may sound like “Can you tell me more about that?”
I want to make sure each question in my question list is of high quality. Ideally, each question will elicit substantial, unbiased answers from the interviewee. Question types to avoid include closed questions (which lead to a simple “yes” or “no” with no context or details given) and leading questions. Leading questions may unintentionally prime the user into giving me a certain response.
Preparing a long list of questions, more questions than I believe I will have time to ask, will ensure the best results from the user interview. This is very different from a usability test, where I would want to limit my interaction with the user in order to avoid skewing data. This particular user interview has no interaction with a design at all, and only seeks to understand the current process for employee performance tracking and how we wish to improve it with this application.
My question list will be broken up into several categories in order to ensure we are tackling our main goal (how this mobile employee tracker app can be designed in a way that will improve employee performance and lead to higher employee satisfaction) as well as the sub-goals I indicated earlier: questions aimed at informing personas, journey maps, feature ideas, and workflow ideas.
The Question List
Persona related questions:
- Who is our typical user? What kinds of jobs do they do?
- Do some users have different categories that will be tracked through the app, or will everyone have the same set of categories? What are those categories?
- Will each category be tracked through another system, or will some/all be self-reporting?
- Will they use the application by choice or as a job requirement?
- Will the tracker be for their own benefit, or are they comparing their statistics to others?
- How is employee performance currently tracked? How will this app enhance or change the current process?
- How do we want users to feel while using the application?
- What will our greatest barrier be to getting people to use this application?
- What will our users be most excited about when accessing this application?
- Do you know of anyone that is similar to our typical user that we can talk to?
Journey map related questions:
- Where will the data on employee performance be collected from? (Self reported or from another system?)
- How often do we want users to use the application, and for how long? (Once a day at the end of a shift, once a week, etc)
- Do we want users to view only their data, or to compare their data to others in the application?
- Do we want to notify users when there are changes to their data (encouraging notifications when a certain threshold is passed, etc)
- Do we want users to be able to share the data outside of the application, such as through email?
- How much access do we want to give users to their past data? Should we give them an ability to compare data over weeks, months, years?
- Should we create a point system to track progress overall, or just the raw data?