4 mental shifts to be a User Researcher

Learning to work and think differently

Priscila Avila
UX Collective

--

A rubik’s cube with the legend “Figure it out”
Photo by Karla Hernandez on Unsplash

One of the first things I was taught in Design school was that, as industrial designer, I was not a mere product builder, I was a problem solver. During the 4-year programme, I learned a design framework, manufacturing processes, tested materials, made prototypes, but above, the goal was to design solutions.

Whenever I finished a project, I would go back to the initial problem statement and ask myself if my design was solving the problem. Interesting enough, for my thesis project, the initial theme, water waste, had nothing to do with the final proposal, that addressed the problem of long waits at the airport in connecting flights. And actually, it was not a product, it was a service.

I had 2 concerns for my final evaluation:

  • The disconnection between the initial problem statement and the final proposal
  • The “lack of creativity” in my proposal, since I was not inventing any new product.

It was only after work experience and Service Design education that I understood why I received the highest mark back in 2012.

In this article I will explain the mental shifts I had to make as I moved into User Research roles. These are based in my experience, it might vary from one person to the other, depending on each individual context, educational and professional background.

1. You are not the subject matter expert

My professional career started as a Packaging Engineer, for dairy products specifically. I was the person to go to when defining the right material, shape, storing conditions, resistance and storage specifications of a new bottle, box, can, bag.

I knew things.

It was quite technical, but a 2-year traineeship taught me processes, quality standards, materials, environmental considerations and variables that I would never imagine had an impact in the performance of a container, like the direction and length of the microscopical fiber of the paper used to make a corrugated box.

After getting Service Design education, I decided to take a new professional path as a technology consultant and my first problem was feeling like I didn’t know what I was doing. I knew the process, the innovation frameworks, but I didn’t know anything about the clients I was working for, their business, their offerings, their problems, their context, their users.

That was the first mental shift I had to make. You are not the subject matter expert. Yes, you know how to do research, the methods, but when it comes to the client’s business, users, challenges, you are an alien. An observer. Your job is to embed yourself as quickly and deep as possible, learn and figure out the relationship between the interconnected elements.

You don’t make conclusions based on your expertise, but on what you learn. The success of your research will depend a lot on your ability to abstract yourself from the equation and remove your biased opinions.

2. Turn creative mode off

One of the most difficult things has been resisting the temptation jump to conclusions and solutions. And that’s completely normal. That’s how we are wired. When humans recognize and understand a problem, our brain starts making connections to frame a solution. It leverages previous knowledge, past experiences, pre-conceptions, rules of thumb, or whatever information is found in the memory system.

When you are a design researcher, you need to consciously take your brain out of solutioning mode. To constantly remind yourself that you are in “sponge” mode, absorbing all the relevant data to the problem before you start making connections.

Getting into creative mode too quickly can make us blind to additional data that could give the project a different scope or direction. You could end up designing something that users don’t need, do not solve the real problem or solve it partially.

3. Educate the team about what your role

As a packaging specialist, my job was self-explanatory. In every new project, there was a big team of Marketing, Sales, Innovation, Production and Finance professionals. I was in the Innovation team with a formula specialist and a project manager. I don’t think I ever had to explain to anyone what was it that I did as a packaging specialist or what would be my deliverables. As I said, it was self-explanatory.

As a design researcher, you need to explain your role very often. The fact that you are brought to the team does not mean that everyone understands what you do. So, part of the role is educational too.

When I was starting a project as a User Researcher, I soon realized that only the UX team knew the purpose of my role. After holding stakeholder interviews, I prepared a presentation to the Technical, Business and UX teams highlighting the confidence that research can provide when making decisions about a product or service. I explained my role, showed the research plan and expected deliverables.

More than informing how I would be using my time, my goal was to find alignment with the team about the process we should take to make decisions based on user needs instead of what the business thought the user needs.

Since then, I have included this activity every time I start a project. I’ve found that this also provides confidence to the client that you know what you are doing and you are genuinely interested in making the user’s voice heard.

4. The problem is not the problem

X Company is launching a product packed in individual packs of 180g of weight, produced at a speed of 45 packs per minute at a temperature of 65°C. Storage at temperatures ranging from 10°C to 35°C and humidity between 35% and 75%. Double stack for 6 months. The product will be displayed in Costco where pallets should not be higher than 1.0m

These were the type of problems I had to solve as a packaging engineer in my early professional career.

Yes, I needed to see the product, go to the client’s production facilities, take measurements, ideate, prototype, test, but I never really questioned the problem or brief I was given. That was not my job. My job was to design and define the technical specifications to meet the requirements of the client.

As a design researcher, that mindset changed. Why? First of all, because problems are more abstract. Second, because often, the initial problem is not the problem, is just a symptom of it or has an embedded solution in it, which contradicts the purpose of having a user researcher in the first place.

How can we encourage our customers to upgrade to the premium version of our product?

This was the problem statement of one of my projects as a User Researcher. The first weeks in this project were about defining the real problem. We found that users were not subscribing because the economical implications seemed huge, while the perceived benefits low.

So, it was a problem of perception, not of encouragement.

Ryan Reynolds taking off his face mask asking Why?

Reframing the problem is part of some of the most accepted innovation frameworks, like the Double Diamond by the Design Council. If you learn it early in your career, it just feels natural. For me, it required a mind shift to constantly question if we are solving the right problem.

So, what gave me the highest mark in the thesis project mentioned in the beginning? It was identifying the right problems to solve, thinking in terms of user needs rather instead of products.

Parting thoughts

My experience as a design researcher has taught me that feeling comfortable with the unknown will never be easy, goes against nature, but once you understand that is part of the role, you start enjoying the process of figuring out what you need to figure out. You then feel comfortable being that person in the room whose favorite word is WHY?

--

--