UX Research: Practising empathy within the team

source

As a former psychology student, my professor once said that a key to every successful business is empathy. I never really grasped the meaning of it until I joined GO-JEK as a UX researcher. An impactful product can only exist as a solution to user’s problem. Being able to empathise towards users’ needs is crucial in every business line.

The good thing is: empathy is not something innate. It’s not something you’re born with and written in stone where you cannot do anything about it.

Instead, empathy is learned and we get better as we practice.

As UX researchers, we keep doing research and getting in touch with the users frequently. Our jobs give us this privilege to keep listening, observing, immersing ourselves in user’s stories. We get all the access to absorb insights and keep practising empathy towards our users.

But the work doesn’t stop there. Empathy towards user should NEVER be exclusively for researchers. Every single person involved in building a user-centred product should be able to put themselves in users’ shoes. But how? They don’t get to interact with the users as much as researchers do.

This is how simple action by involving product team in the research process plays vital role in spreading the empathy throughout the team. I’m gonna share some of the things that we do in GO-JEK Research team to achieve more involvement and collaboration with other functions within the product team (PM, PO, designers, engineers).

#1 First thing first, one or two team dinners won’t hurt. Get to know your whole team, meet them in person, remember their names, make friends with them. Get to know more about them, how much knowledge they have about users, what they’re curious about, etc. Having an in-person interaction with the team is much more effective in building conducive communication atmosphere than just a video call.

In GO-JEK, we have teams in Jakarta, Bangalore, and Singapore. We do collocation every 2 months when we come to visit each other for a period of time. I personally feel that collocation is really powerful in giving us the sense of a team working together to achieve a consensual goal.

#2 “Align early, consistently”. Borrowing one of GO-JEK ten values that speaks for itself. Always try to align research with the product team as early as possible. Of course we-researchers- still have to finish the homework. Plan your research thoroughly but don’t forget to always give room for inputs and adjustments here and there.

Whenever possible, I try to set up a call to make sure that the team actually goes thru and gives inputs to my plan before I execute it. Involving the team from the very beginning of the research can grow ownership for the rest of the research process.

#3 Include the team to come along during the research and meet users. It’s really valuable for the team to immerse in user’s context, to actually see and assess how their own hard work is helping a real human being (or not).

In GO-JEK, we usually pair a researcher and a designer to do usability testing. It sometimes strikes me how designers can see things and grasp insights through a completely different angle from me in a single testing session. It also happens vice versa, where researchers can offer other different angle to produce insights from the testing. This kind of collaborative process enriches learning that we get from a single testing session. Another bonus for researcher: a pair of fresh eyes will always be helpful in feeding back your overall testing flow and maintaining second perspective in synthesising the results.

#4 ACTIVELY invite everyone in the team to attend your research result sharing session. There will be time when the team is busy doing their job. Attending your research session may not be the first thing that come to their mind. But they might actually be willing to learn from your research but simply hesitant.

What I do to avoid the latter, sometimes I(shamelessly) come to their desks and individually ask them whether they can join the sharing session. Show that it’s actually super important to attend the session and learn from your users. Most of the time, they join!

#5 How you present the result is key. On most people’s ears, the word “research” alone may sound so serious, boring, and complicated already. To avoid that stigma, it’s important to think of it as a story telling. We have to figure out how not to tell a torturingly boring story out of our research.

I try avoiding too detailed result whenever I prepare a presentation to the team — though the detail still has to sit somewhere in the appendix of documentation folder. If possible, I always find a way to tell the story with diagram/picture to substitute the text. Basically applying UX knowledge onto your report and sharing session. I treat the whole team as users and the research result is my product. Another thing that you can do is dry run the material with someone and ask them for feedbacks. That’s what researchers do, right, listening to feedbacks?

#6 Equip your sharing session with interesting media documents. Videos of users interacting with the products are really powerful to help team members to see what users see and experience what users experience. Sounds like a good empathy practice, right?

However, UT videos showcasing can be time consuming, so I avoid scatteredly showing Usability Testing videos — it’s not an hour of Nat-Geo documentary open screening session. Instead, every part being showcased needs a purpose. I think of it as supporting details that strengthen my overall summary result from the testing. I would show videos when users cannot complete the task to emphasise pain points. Or, showing a video where a comment of a user is worth quoting. A tip: don’t forget to translate or give annotation to the video to make it easier for audience to get what you’re actually showing in the video.

#7 Spare minimum 30% of your time in sharing session for Q&A and brainstorm on solution. I believe that good research cannot only deliver complex statistical analysis. Good research deliverable should be something engaging that triggers rich discussion on the possible solutions and next steps. This is why a brainstorming exercise is crucial to trigger the collaborative work in order to come up together with solutions.

“Good research deliverable should be something engaging that triggers rich discussion on the possible solutions and next steps”

Research sharing session should not be a one way information flow from researchers to the team. To make this happen, on my previous sharing session in Bangalore, I simply hide my summary and recommendation slide. Instead, I embedded an empty slide as a collaborative space to jot down the discussion. It’s even better if you’re doing it in a meeting room with available whiteboards!

brainstorming with the team

I’d start with a question: “from this presentation I just shared, what do you guys think as the most painful experience our users find while using our apps?” This will trigger them to think with user’s head and feel with user’s feelings. In this phase, do not filter any ideas or thoughts. Let it flow and write down ALL of the thoughts mentioned.

After that, we can start filtering and clustering things that have similar issue/sources. Triggers the team to prioritise the findings by the outcome it will affect. Then move on to work together on possible solution to address the pain points we prioritised before. In my previous experience, this phase — where the team discuss what they can do to solve the problem technically, will take quite long that it will exceed the meeting time. As a researcher, you know that your sharing session works if those who attend the session keep being engaged and continue discussing what’s next from your research!


So, those are actionable things that we, as researchers in GO-JEK, are doing to help the whole team practise empathy towards our users. Do you agree that involvement of the team is important to practice empathy? Or do you have other thoughts or practice on this? Please do share and discuss in the comment section down below.