Four shots fired before UX research starts @ Halodoc

High-precision machines like rockets are optimized to work in particular environments and conditions. Once it is launched, you can't do anything other than wait for it to achieve what it has been designed for. Sometimes, it is easy to point out what should have been done. But a backup system still needs its own plan. Hence, not every contingency can be planned for.

And now, you might be wondering if you clicked on the wrong article.

In Halodoc, we don't build rockets. But if we consider the fact that we're trying to simplify healthcare in Indonesia, it could mean the same thing. This, as a matter of course, affects the nature of how we conduct our UX research.

We are sure you've been hearing this for a thousand times already: one of many responsibilities a UX Researcher has is to collate insights about users, whether it is their goals, motivations, pain points or workarounds. But when your users are real survivors of clinical disorders or seasoned doctors with no time other than handling patients to spare, conducting research is a challenge in itself. As a team of six in an agile environment, we have to move fast. At the same time, we also have to see to it that we don't trigger any trauma or hinder someone in serving others.

We even need to ask ourselves: can we go to the field this time?

We've learned the hard way that ‘no’ isn’t a foreign answer to that question. We need to plan our research right, delivering quality despite our limitations. Thus, we make sure we have these on the table first before getting our gears ready.

The Rationale

Imagine this: a PM comes up to you all concerned because something is not working the way it is expected to be. They want to know why.

Okay, you think, it is valid. Understanding how your products perform and how users experience your product is essential, after all. We need primary research.

However, this is where things usually go wrong. We tend to overestimate each others' capacity to convey something; the illusion of transparency. Here is also where the first question should come in.

Why do we see this as a problem?

A bad review, a decline of a funnel, a finding from past research -- anything can be a problem. But in what context does this become a problem? How is it supposed to work? What’s its purpose? Is it the actual problem? As a UX Researcher, it is our job to make it make sense.

The Hypothesis

At this point, we should already be on the same page about the problem at hand. Still, it isn’t enough. What about the first question the stakeholder asked that turns out to be not the actual problem? There must be a reason why they lean in that direction. Everyone knows about something at some level, after all. Thus, we move forward and ask:

What do we know about it so far?

We should've already had the answer, you think. But what we really look for from this question is any surfacing hypotheses. Not only that, but we also don't want to miss the thinking process of how we come up with the hypotheses.

One day, a stakeholder in Halodoc wanted to know why a certain type of users have not been leaving ratings for the teleconsultation they have done. They elaborated on the purpose of the feature and how it should perform. Is it because users are unaware of the feature? Probably. We thought for a second and recalled that some users mentioned something about feeling bad to give a bad rating. Boom.

It isn’t uncommon that after hearing the further explanation, something clicks. We have data regarding this, we believe. Turns out, we already have the answer. Primary research might not be needed.

Even so, in such a scenario, a secondary analysis is necessary hence the next question.

The Importance

Now we know that the problem isn't based on false assumptions or mere curiosity. We also know that we're not exactly clueless about it. We've established the foundation.

You ask, what's next? We check the importance. We want to make sure we aren't going to go out to the field or spend the research budget for naught. In doing so, we ask:

What will we do once we get the result?

Often, there are already some initiatives from the stakeholders' side to optimize the product. If not, there should be some decision put on hold waiting for the result. Either way, these highly affect the expectation of the research, especially on the deliverables.

We’ll implement the feature if it is proven right, said a PM. That means they need validation for ‘it’. Preferably in numbers, a frequency of incidence. Add potential concerns or pain points, you remind yourself, considering the result will also be the basis for a feature.

We can come up with a bunch of other deliverable forms, but we shouldn’t get ahead of ourselves until the next question.

The Urgency

Early this year, we had plenty of research going on for a new product release in the next quarter that already occupied half of the research team. Then, a stakeholder came over to us. I have something to discuss, they said. You guessed right, a research brief.

After grasping the importance, we hunt for urgency. You probably know the drill already -- a basic when you're short in resources.

When is the latest date we can deliver results that will still be useful?

The answer will enable us to allocate the proper time and manpower to handle a study. In other words, it helps us to manage the quality expected from the research within limitations. But, above all, we are actually trying to answer: is it even feasible? Will the targets be available for us within this timeframe?

Often, this is also where the negotiation begins.

Additionally,

Do note that there are many ways to address these four aspects and that they are not only meant for the stakeholders. As a UX Researcher, we should ask these to ourselves too. Yes, even the fourth question. We should at least have a rough idea when would be the "right" time to deliver the results.

Some of the questions might sound ignorant -- like you know nothing about your own product. They might also result in a raised brow or a mixture of surprised and offended looks. But we wouldn't want to spend countless hours doing in-depth interviews only because it is nice to know something.

Can we go to the field this time? Probably not. Should we not do any research? Still no. Before coming to that conclusion, however, let’s ask some questions first.

We are always looking out to hire for all roles for our team. If challenging problems that drive big impact enthrall you, do reach out to us at careers@halodoc.com.

About Halodoc

Halodoc is the number 1 all around Healthcare application in Indonesia. Our mission is to simplify and bring quality healthcare across Indonesia, from Sabang to Merauke.

We connect 20,000+ doctors with patients in need through our Teleconsultation service. We partner with 1500+ pharmacies in 50 cities to bring medicine to your doorstep. We've also partnered with Indonesia's largest lab provider to provide lab home services and to top it off, we have recently launched a premium appointment service that partners with 500+ hospitals that allow patients to book a doctor appointment inside our application.

We are extremely fortunate to be trusted by our investors, such as the Bill & Melinda Gates Foundation, Singtel, UOB Ventures, Allianz, Gojek and many more. We recently closed our Series B round and, in total, have raised USD$100million for our mission.

Our team works tirelessly to make sure that we create the best healthcare solution personalised for all of our patient's needs and are continuously on a path to simplify healthcare for Indonesia.