π 4 User Research Lessons for Beginner Product Designers
Product Designers can only do a good job if we understand our users.
In Carousell, users play a central part in the product-building process, and that's why we conducted many user interviews to understand our users.
On May 2019, the team went to KL, Malaysia, to conduct some usability tests to verify our new idea for the meetup and payment.
As you know, our product team is based in Singapore. But for this feature, we want to build for the Malaysian market. So we had to go there and test and see how real users would use our product.
This is also the first time I did user research somewhere outside of Vietnam and met totally new people who don't speak my mother tone language,β¦ scary. But this is a good chance for me to practice anyway.
1. User research is very tired
Yes, it was very tiring.
It wasn't because you have to wake up early and sleep late in the evening. It's because you have to spend hours speaking with people, lead the conversation, asks many questions, and make the participant comfortable. Your mind will be overwhelmed by so much information from users, and you will feel drained of energy.
That's why you should only do a maximum of 3 interviews a day and try to relax to prepare for the next day. Otherwise, you will be sick of interviewing after the trip and give up the idea of becoming a product designer with strong user testing skills.
2. There are no perfect prototypes
Before the test, we spent lots of time creating a prototype. We tried to cover all the cases that could happen when participants interacted with the prototype. We wanted it to be as close to the real product as possible to get accurate validations.
And when we showed the prototype and asked participants to interact with it, everything messed up.
They wanted to go to the next page, but the next button didn't work.
They wanted to close a page, but the close button didn't allow them.
They wanted to choose Credit as a payment method, but when they clicked on it, another screen popped upβ¦.
And many other unexpected cases.
Yes, it is always like that when we test our prototype. No matter how much time we spend preparing it, it's not always enough.
So go with what you have. And the most important thing is to ask what users expect when clicking on that element, what they think about it, what it means to them, and why they think so.
Guide them, but don't lead. We can explain at the end, but let them struggle with that prototype. We will get many undiscovered things from their struggle.
3. Keep the test short
On our test, we did from 1.5 hours to 2 hours. We had too many things to validate, and we were curious about how people use our new features.
We started the conversation smoothly in the first interview with warm-up questions and simple tasks. But after one hour, the participant seemed to talk less. Their sharing wasn't open anymore. "It's ok!", "Oh yeah, it's very clear to me" "Hmm, I like it!"β¦
We realized that the participants were getting tired. We asked them to take a break, but they didn't want to. Because they didn't want to waste time, they felt guilty if they took a break.
We pushed ourselves to stress when we planned to do a user test for one hour and a half or two hours. We did the research plan and tried to add as many questions as possible to fit the time.
On the other hand, what about our participants? Not only we but our participants will also grow tired of the ceaseless talking. And when they're tired, they will not share with us their true thoughts. They will do the test perfunctorily and just want to finish it early.
So next time you do a user test, try to frame the test to under one hour and add only as few tasks as possible. If we have many things to test, we can do it with different users simultaneously. Keep it short.
4. Run a dry test first
Yes! It is always a good idea to test it first. It doesn't only apply to the development process. Anything would be better with the test. The same is true for user testing.
We do QA before launching features to the world.
We do user testing before starting to implement features.
The same is true for user testing.
We can run a dry test with our college first. So we can predict what a real test would look like. We can adjust questions to make them clearer and change the order of activities to make the conversation smoother. Then you will be more confident when doing the test.
User testing takes work. That's why we need to practice. As Bruce Lee said:
"I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times."
Practice makes the master.