Hey all,

This topic could prove controversial, but I've had a couple of conversations recently that make me think this is a subject worth discussing. It's about the role of user researchers in organizations.

Now, I know a lot of you reading this will be thinking to yourself that you'd kill to work somewhere willing to invest in hiring a dedicated user researcher. But be careful what you wish for, because I'm not sure it's always a good idea. Especially if it ends up creating a gatekeeper between stakeholders and users.

You see, I've worked with a few companies over the last year or so where the roles of user researcher and user experience designer have been separated. On the surface, this looks like a good idea. After all, generally speaking, the more specialized you are, the better job you'll do in a particular niche. And that's true for user researchers. There are many nuances to carrying out user research that a more generalist user experience designer may overlook.

However, by separating the roles, you can create a couple of problems that I've witnessed recently.

First, precisely because of their expertise, some user researchers carry out such in-depth research that it doesn't always sit comfortably with the timescales allocated to projects internally. The result is that user research can become time-consuming and so only happens once or twice during the project. Instead of facilitating a culture of testing and iteration, you end up with a piece of upfront research and a sanity check towards the end when it's too late to change things.

Although in theory, this kind of in-depth user research should provide benefits, in my experience at least, a leaner, more iterative approach tends to win out. Put another way, I favor a series of lightweight research and testing exercises throughout the project over more in-depth research at the beginning and end.

If this is an approach you are interested in learning more about, I have a workshop that I can run in your organization.

Second, and probably even more significantly, the involvement of a user researcher reduces the interactions that the UX designer has with users. Instead of running user testing themselves, they get back a report from the user researcher and often don't experience the user frustrations firsthand.

Admittedly, the user researcher's observations may well be more in-depth and insightful because of their experience and expertise. However, I believe you lose something when the UX designer isn't observing and interacting with users firsthand. They'll learn a lot more this way than from reading a report.

Of course, this won't always be the case. In some organizations, the user researchers will go out of their way to involve the designer. However, in my experience, this is the exception and not the rule. That's not because of reluctance on either the part of the designer or researcher, but instead for the sake of efficiency. The pressure to deliver will often mean it's seen as excessive to have the designer involved in testing when it's seen as the job of the user researcher.

None of this is meant as a criticism of user researchers. Neither am I suggesting that there isn't a place for separate user researchers.

However, I see the role of user researchers to be focused on the bigger picture. They should be gathering insights that apply to the wider organization, while project-specific testing should be done primarily by UX designers.

See Also: Rethinking The Role Of Your UX Teams And Move Beyond Firefighting

User researchers can support them by providing training and advice, but I think it's dangerous to centralize all user research with the user researcher. Doing so, in my experience, results in less research and testing for the reasons I've given.

That said, I recognize that I'm drawing on my own experience here, and maybe things are different where you work. I'd therefore love to hear from you on this one. Do you have separate user researchers, and if so, does that still allow for lots of lightweight research and testing to refine ideas and answer questions throughout the project?

Hello all.

If you work on websites, rather than web apps, the chances are you want people to do something on that site. It might be sign up for a newsletter, buy a product or getting in touch. Whatever it is you want people to do you will find them cautious. That is just human nature. We are always looking for the “danger” in any situation. People fear making the wrong decision or wasting their money. They worry about what will happen if they act and how things might go wrong.

You can have an amazing product, great design, and compelling content. But if you fail to address people's concerns, they will hesitate to act.

A vital skill when working on websites is the ability to address these concerns. Even if content creation is not your main job, you need to guide those who create content. Otherwise, you might end up receiving the blame if the website underperforms.

Objection handling is useful not only for creating websites but also in everyday life. You may need to persuade people to do something, whether it's convincing a child to eat vegetables or getting a manager to approve your pay raise.

Identifying objections and knowing how to respond are valuable skills in many situations.

So, how do you find out what objections your audience might have?

1. Demonstrate empathy.
2. Talk to those who know your audience well.

For example, to improve a website's conversion rate, talk to the sales or customer support teams. They can help you understand people's objections better.

You can also ask your audience directly. I often run exit-intent surveys on landing pages to find out why people choose not to act. This feedback can provide valuable insights for improving the page and increasing the conversion rate.

Once you know their objections, you can start working on how to address them. It may be tempting to ignore objections, but this rarely works. Addressing objections directly shows that you understand your audience. This approach not only addresses their concerns but also builds trust.

When speaking to people directly, it’s helpful to preempt objections. Don’t wait for them to raise issues. If you address their concerns before they mention them, they have the opportunity to remain silent. This means they will not lose face in front of others, something especially important with senior stakeholders. They really do not like being corrected by someone below them!

On your website, link your responses to objections with elements that might trigger them. For example, if you're asking for credit card information, reassure users about security at that moment. Don't expect them to look for answers in your FAQ section!

There is much more to say about objection handling. I have just published a comprehensive post on my website that explores this topic in depth.

However, the reason I have raised the issue here is that objection handling is a crucial skill that anybody working in marketing or UX needs to know. In fact, it is a good skill to have no matter what your role. And yet, somehow it is not a skill you hear people discuss very often.