User Interview — Where did I start?
Data is a pretty broad concept, it can be everything, or it can be nothing, depending on how we look at it and use it. As a matter of fact, sometimes it’s even harder to make use of it than how to find it, cause most of the time, data is enormous. Thus without sorting and sifting data in the right way, it’s easy to be rolling and spinning around in that huge amount of data, like sailing without a lighthouse at night, which results in drowning between the waves or getting lost with no destination.
It all started with a mess…
There were times when kicking off a design without a specific objective would still work somehow, since most of the products have a certain pattern for the majority of users. However, in the long run, the lack of information about the current state of the product caused me nervous, like my feet were not on the ground, like a blind man walking in darkness. The more trouble from the lack of information, the more realization I had:
- I found that there were too many problems with the current product, but I got lost in defining the starting point, which features could be fixed, which affected the most, which could be ignored at the present time, and what else we could miss
- Did my users use the product the way I expected them to do?
- Who was using my product, what was their purpose, what was important and how does it affect them?
- Whether the complaints of users had been understood correctly, how many people felt the same problem?
“Hey, too many things need to be sorted out and we’re going to be groping like this forever if we don’t have more information about the user.” — that’s how this project was implemented at the beginning.
I started by sketching out my needs, imagining the possible results could be once this project was finished, I could achieve:
- I needed to understand how my users were using the product in the way I expected it to be
- I needed to understand whether their purposes were similar to my expectation, who they were, why they expected it.
- Whether I understood correctly their problems, did I miss anything in between?
“Start with the end in mind.” ― Stephen R. Covey
Okay, I do think I need it, but how…
We pretty much didn’t know where to start at first, then we just got our hands dirty with what we currently had. We might not know the user well, but fortunately, we did understand the product, and that product was built on expectations. At this point, let’s say, we had our own expectations, and on the other end, we were about to have the expectations of the users, so what we needed to do is shape both parties’ points to be as close as possible.
As in the first step I already outlined my goals, then all I had to do is to concretize that goal with hypothesizes, the expectations when forming the product in the early days:
- The hypothesis about how users use the product: user journey
- The hypotheses about the objective and purpose of using the product: user personas
Collected and recorded any hypothesis that our product team and other stakeholders had about the users, then organized the information as the final result that we expected it to be once the project ended.
Sometimes to begin with, simply start by imagining.
User journey hypothesis
- I started by listing down all the necessary steps to reach the user’s end goal, then organized them into 3 main stages: before, during and after the procedure in the horizontal order
- Then I listed down all the factors that affected the whole process in the vertical order
- And finally filled in the information to that template
I tried to make sure that we and other stakeholders are in the same line, otherwise it may take more time to back and forth about our decisions.
Selecting the methodology
Depending on the nature of the subjects to be examined and the type of information to be extracted, I selected the methodology by imagining which circumstances would be most favorable to gather information from them.
However, we might not aware of all the possibilities that could happen and there was something I learned along the time.
1st experience: Built the perfect plan without being limited by money and time in advance. Let the imagination run wild before reality hits hard.
2nd experience: Planned and discussed it with the stakeholders as soon as possible and be prepared that “your perfect plan” would always be subjected to change by the factors of time and money, left some plenty of time, and be ready for the adjustment and alternatives preparation.
Building the questionnaire list
How to ask the right questions? There’s no right direction that I could tell, but there were some ideas that I could give in case you don’t know where to start.
- Sketched out the general structure of the questionnaire, starting with the issues I want to know.
To be specific, if we needed to know information about the user, then my questionnaire would have a section for the user to tell their story. If we needed to know the order of steps in their work, save a section to talk about it. And if we needed information about each step of their work, so add that to the questionnaire too. The template for our user interview would have a structure like:
a. Introduction:
b. Main Interview:
— General Usage
— Overall User Journey
— Questions during Observation / Field research / Usability Testing / User interview / User Journey Step
c. Wrap up - After having the overall order, we concretized them by details, starting from the most general information to gradually more specific questions. With each section, there was a common set of templates used to modify depending on the situation.
a. Introduction template would include the following information:
— Warm up: some ice breaking questions
— User profile: general information about the user
— Technical literacy: question to evaluate user’s tech-savvy level
b. General Usage template would include the following information:
— What: who was the user, what were they doing?
— When & where: when and where did they use the product?
— With whom: who was doing the same work with them?
— How many: their frequency of using the product
c. User Journey Step template would include the following information: Based on the steps that were developed and listed in the user journey hypothesis, continued to build a suitable set of questions for each user journey step based on the form below.
— Behavior: user’s actions
— Time taken: time to perform the task
— Pain point: difficulty while using the product
— Improvement: what could make the user more comfortable
— Cross-app evaluation: compared with other competitors
d. Wrap Up template would include the following information:
— Emotions: overall feelings of the product
— Important steps: which step had the most impact on users to assess the importance and urgency of the feature
— Unmeet needs: unmet needs of the user
Unfortunately, note that no matter how perfect my set of questions could be, in reality, things could always turn out differently. Users might not answer the question in order, or they simply got me wrong, these things could happen all the time. Sometimes just went with the flow, let the user speak. My best advice here would be to try to understand the product as much as possible, so you could always capture the user’s story.
“Basically, we are all different…”
The users of our products, while they may have the same goal, the way they use it, the needs and the problems they face can be very different if they don’t share the same background and personality. In short, we are fundamentally different.
In order to truly understand the reasoning behind an event, one must understand both the context, age, and technical level of the person using it. The same went with building a product, users’ thoughts could be similar or different depending on internal and external factors. That is why we needed to segment our user groups so that we could evaluate the strengths and weaknesses of each, then prioritized the conditions in which we could satisfy them.
Started by including other stakeholders (sale or strategy team) in the process to get to know how they categorize users. Then, based on that, I built my own criteria to segment groups of users that were different in pattern. Our way of segmentation was not necessarily the same as the way other teams classify, but it couldn’t be too far from the definition of other teams, because at the end of the day, we all needed to speak the same language to understand each other.
Some examples of basic criteria:
- Gender
- Age
- Technical level
- Frequency of using the product
- Differences in workflow
- Work role
- Purpose
Then, depending on the conditions of time and money, the sample size for each group could be decided later.
These criteria and classification could be considered as the first draft of user personas, which would be defined once we had enough insight into their demand, their frustration, and their goal.
So close to the victory
We must constantly update and work with stakeholders, including planning, reviewing the questionnaire, sample size and timeline for the recruitment section. Keeping the stakeholder in the loop as soon as possible would save us time and avoid some heart attacks in the future.
When all of the above tasks were done, including the recruitment, other things like reviewing the budget and preparing the tools for the upcoming interview would not be an issue. A list of necessary tools, particularly for a field trip, things like lapel mic and compact tripod should be prepared in advance.
There was no secret to being too sublime at all, just prepared, prepared, and prepared (including a mindful soul and the confidence for unexpected events).
Once again let me appreciate the journey I have so far with you guys Phamdotuanh, Nikiprojek, Thai Lam, Cheol Jun Lim, Amy Nguyen, Phuong Han and more.
