What is User Research?

When we start a new development project, we often immediately throw ourselves into designing or programming. But what comes first? How can we carry out research to evaluate a prototype or get to know our users better? We discuss this with Paolo Tripodi, a designer at Moze.

Sergio Panagia

Sergio Panagia

Partner, Technical Director

Paolo Tripodi

Paolo Tripodi

Designer

Sergio Panagia: Welcome to the Moze podcast, a space for technical insight into the development of new digital products. I’m Sergio, partner of the studio, and with me today is Paolo, a designer at Moze. Hi Paolo.

Paolo Tripodi: Hello Sergio, and hello everyone!

Sergio: When we start a new development project, we often immediately throw ourselves into designing or programming. But what comes first? Today, together with Paolo, we talk about research, i.e., the set of activities prior to the execution of a new project. Paolo, what does it mean to do research in the context of a digital product?

Paolo: Excellent question, Sergio. Thanks for asking me! So first of all, I would say that as we can imagine, there is no single exhaustive answer. That would be nice, but it seems unlikely to me, just as there is no single way of doing research.

On the other hand, as we often experience, a client may ask us this question, perhaps point-blank, talking informally about a project. In that case, I would say to that client, “research, in short, means testing your ideas before developing your digital product. Not because it’s nice, not because it’s fashionable, but above all, the main reason is to potentially save a lot of money”.

Sergio: Yes, based on our experience in the field, companies often focus first on the new solution or functionality to be implemented, leaving out or neglecting somewhat the analysis of the problem to be solved. Why is this so, in your opinion?

Paolo: Unfortunately, I can only agree with your premise. So many things come to mind. So, to take the silliest example, nobody would book an expensive dinner with old friends without first contacting them to see if they are available, right?

Strange but true, this is not always the case when it comes to a digital product; to stay with our example, several restaurants are often booked instead, perhaps already with a seating order for each table.

Sergio: Hahaha, great example!

Paolo: A typical example of this is a new project, which could be a start-up, a new innovation project of a large company…

In this respect, first of all, it seems clear to me that a new project necessarily stems from an opinion, perhaps even a strong one, regarding the problems of a certain market or a certain product vision.

That said, balancing your ideas, your point of view with that of the customers or the people you are making your product for remains essential. Not for fashion or any other trivial reason, but mainly because not doing so can be very expensive first of all, and then also nerve-wracking in the long run.

Sergio: Yes, that’s right. Many of our clients, companies or start-ups, come knocking on our door with a promising product. However, design issues at the outset impact the user experience and hinder the growth of the product and the company, and they come to us and say, “Yeah, OK, we had to rush these things, but now let’s re-think it from the beginning”. In your opinion, how can research help to reverse the trend?

Paolo: Excellent question. So, basically, I would start by saying that there are two types of research that we can use: one is the one that everyone generally looks at, which is data: traffic data, page conversions, and so on.

Here, I would like to open a parenthesis by saying that everyone looks at the data. However, examining data properly is not at all a trivial matter, and as we have often observed, very few can do it.

The other research method is interviewing, known as qualitative research, aka for friends talking to my clients to understand their needs.

This is often, in the first place, regrettably the least used method we come across. In fact, it should always be the first method employed when starting a new project. Moreover, I will open a parenthesis by saying that this is the method that large technology companies have practically always used, together with data, to obtain results. These are a few considerations that come to mind.

The good news, however, is that you don’t need to be a scientist to do, or start doing, research. Learning the tools, just like we had to, is absolutely feasible even for those who have never done this kind of thing before.

And the great thing about this is that we have succeeded with many of our clients. 

It’s nice when that happens, and it’s especially nice afterwards to be thanked for it, which I think is one of the best things about our work.

Sergio: Yes, in a number of cases in our experience with our clients, we have managed, through tests and interviews, to fine-tune a new product idea or to refine what were initially thought to be features for a new functionality, and this actually saves time that would otherwise have to be invested in long development cycles, before any real engagement with the user. 

Paolo, starting from an analysis of the problems, and an in-depth discussion with the users, how do you then move on to the definition of the solution and its implementation?

Paolo: This is also an excellent question! So, to truly understand what our users’ real problems are, I would say that the first thing to do is definitely to have a good chat with a user or potential user. That’s the first step I would take.

With respect to this, the only caution I would add is that we should not be having so much of a “conversation” with our user, by trying to win him over to our way of thinking. On the contrary, the kind of conversation we should have is to listen to our user/customer as much as possible, perhaps even showing him a prototype of our app if we have one, in an attempt to understand his problems as they stand before he encounters our solution, in essence.

Once we have had 4 or 5 of these talks, listening attentively to what we are being told, what needs to be done to change our solution emerges almost naturally, almost intuitively.

I’ll give a concrete example: “the dashboard must show me these specific parameters”, and, therefore, we include them in the prototype precisely because of our strong convictions. And then, perhaps 5 out of 3 interviewees don’t know what they are looking at, what data they are looking at, and maybe two others do the same thing in Excel. So at this point, we can see that those infamous convictions that are well worth testing have been turned upside down.

On a more operational level, it also occurs to me that, in order to be effective in having these conversations, it is very important to separate the act of listening (i.e., the moment in which I sit down and listen to my users) from the act of analysis (which is the moment in which I draw conclusions). This gives me the option to deal with these two things with a fresh mind and in each of these two acts, which are consecutive, to go straight to the point!

Once I have carried out an analysis of this kind, and, therefore, once these conversations have given me a clear idea about what actions I can take, I can design new solution concepts. I can reiterate what I have designed and, in turn, subject these subsequent iterations to further tests, always with the idea of reducing the gap between our preconceptions and the user’s actual experience, and, above all, the user’s real understanding of what he has in front of him. 

And so, from this point of view, research, if you like, is more of an incremental process that supports development – rather than a stand-alone activity that simply ends once you start developing. 

Sergio: Finally, Paolo, is there a book or other resource you would recommend to a listener interested in learning more about digital research after our conversation?

Paolo: Definitely yes, certainly off the top of my head, I would recommend taking a look at the book Sprint by Jake Knapp. This is for several reasons; first of all, this book was for us the book and the methodology that introduced us to interviewing, to qualitative research, and so this is the first point. The other reason is that in this book, there is a very effective summary of how to carry out an interview with another human being, without going crazy, but above all, obtaining the desired result (a human being who is often a stranger, therefore, a person with whom we do not know what reaction to expect). The last thing that comes to my mind is why this description of how to interview another person is part of the Design Sprint process, which is itself an excellent synthesis of what research should look like within the development of a product. As we touched on before, I’m not talking about something that is done at the beginning of the process, and that’s the end of the story, but an integral part of every iterative cycle, every time, maybe not always, but at least every time that the unknowns at stake justify asking some questions.

Sergio: OK, thank you very much. We have come to realise, therefore, that research is a recurring activity that should be scheduled into the development cycle of a new project. Thanks, Paolo.

We are curious to know how others carry out research in development projects, so if you are interested in sharing your opinion or point of view, write to us at mozestudio.com. Paolo, thank you for your contribution.

Paolo: Thanks Sergio, and greetings to everyone.




    Press ENTER

    Proceed

    press ENTER

    Thank You

    We'll be in touch soon.