📹 New! Remote User Testing - Get video + voice feedback on designs and prototypes
Request Demo

Should User Researchers Give Feedback to Teams?

Where does user research feedback start?

The other day, I saw a bad prototype. It came up during a design critique. We were going to start user testing that very prototype the next day. I wrote down my notes and mentioned it to the designer.

The problems I saw were:

For me, these were easy things to fix. I wanted to give the designer this feedback for two reasons:

  1. To make the design cleaner, and to encourage attention to detail.
  2. To ensure we were getting the right feedback from the users.

The second reasoning behind this, for me, is more important. When I present a prototype to users, I would rather not spend the precious time we have with them confused about easily changed information. Or information that doesn’t matter in the test. It can be a big waste of time, and participants can get stuck on these small inconsistencies.

What happened in this case? Unfortunately, the designs didn’t get changed in time. We tested the older designs with the issues I mentioned. While we did get some great feedback on the user experience, there was some time wasted on those smaller inconsistencies. I had to explain them and wave them off as small mistakes that don’t matter. However, it made the interviewing experience seem less productive and prepared. Almost every user recognized the changes I had asked to be made.

Regardless, again, we still received great information from users, but it felt clunky to explain away the prototype. Now, I know prototypes are supposed to be far from perfect, but this felt beyond the usual prototype spiel I give.

So, my biggest question in this case: is it okay for the researcher to request the changes I did? Or is it on the researcher to perform the interview in a manner where these inconsistencies don’t matter to the user?

Should User Researchers Give Feedback to Teams? DilbertCredit: Dilbert

When should user researchers give feedback?

This particular case made me question when, and at what level, user researchers should give feedback to our teams. I generally give feedback during the following opportunities:

I’m not entirely sure if this list encompasses every opportunity, but it was my starting off point. I don’t want designers or other team members to think I am an expert in UI/UX (or any other field, for that matter) or that I am overstepping boundaries.

Here is how I give feedback at each of these steps:

At what level should we give feedback?

Since the first three opportunities for feedback are much more straightforward, I will focus on synthesis for this particular case. I have the following questions when it comes to giving feedback (specifically targeting synthesis):

I truly believe user research isn’t about giving people answers, it is about giving people tools to better contextualize something. We aren’t meant to “tell people what to do.” So, with this in mind, what are we supposed to be writing in terms of recommendations?

When I tested the aforementioned solution (which was a huge feature), it was glaringly obvious our users would not find it helpful or useful. And they would not pay for it. There were a few aspects of it they liked, but, by large, it wasn’t sticking with them. They simply were not interested and would rather have the company work on other features or improvements.

When I received those results, I wasn’t entirely sure what to do. The solution was already half-way built, and the team had spent a good amount of time working on it. I decided to give my honest recommendation: stop working on this immediately and pivot to working on other, more impactful, areas. I gave some ideas on how we could change the idea to suit our users better, but it should not be a high priority. I was lucky to have enough people on my side to be met with little resistance.

However, when it comes to these tests, I always wonder what level we should give this feedback and these recommendations? I often state the recommendations as problems instead of solutions:

“User is unable to locate the “pay” button or move to the next step” versus “move the “pay” button to higher on the page or make it a bolder color.”

This still gives enough flexibility for someone to make a better decision, without me telling them exactly what to do. However, as I mentioned, I also made an honest recommendation of not continuing on with a product. I’m not entirely sure what the balance is, but I am sure there is one. But I would still love to know…

How do you give feedback as a user researcher?

. . .

If you liked this article, you may also find these interesting:

If you are interested, please join the User Research Academy Slack Community for more updates, postings, and Q&A sessions :)

. . .

Originally posted on Nikki's Medium.

A qualitative user experience researcher who loves solving human problems, petting all the dogs, writing on Medium and teaching at User Research Academy

Related Posts

Best practices on why is UX research important to design a successful product.

In short Atomic Research is the concept of breaking UX knowledge down into its constituent parts: The Atomic Research model — a funnel from data to conclusions, then around again Experiments “We did this…” Facts “…and we found out this…” Insights “…which makes us think this…” Conclusions “…so we’ll do that.” By breaking knowledge down like this allows for some extraordinary possibilities. How It… Read More →

My name is Olga and I’m an introvert. Well, sort of. On a good day, I’m perfectly able to engage in effortless small talk. But on a bad day, in the words of Marina, “I wanna stay inside all day, I want the world to go away”. And yet, I’m an UX researcher, which means I got myself a job… Read More →