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.

Hello all,

I've always been a strong advocate for establishing measurable success criteria in every project. The digital world offers us a wealth of metrics to track - from conversion rates and lifetime customer value to engagement and user experience. It's a data goldmine!

But recently, I've been reminded that adopting metrics can be a dangerous game, especially if we become too obsessed with them. Let's explore four key dangers of metrics and how to navigate them effectively.

I'm currently working with an insurance company that's fallen into this trap. They're tracking the number of quotes sent out rather than actual sales. Consequently, they're making decisions that boost quote numbers at the expense of real conversions.

How does this happen? It's called the McNamara fallacy - our tendency to measure what's easy to measure and, over time, assume it's the only metric that matters.

Be wary of this trap. While measuring something is better than nothing, avoid placing too much weight on easily accessible metrics. They're just part of the equation, and the metrics you can't easily measure (like lifetime customer value) are often the most important.

Quarterly targets are common, but they can lead to dangerously short-term thinking. If you're fixated on this quarter's sales target, you might prioritize costly customer acquisition over more sustainable strategies like customer retention and word-of-mouth recommendations.

When we focus on a small number of short-term metrics, it's easy to misinterpret what's happening. You might miss seasonal variations or fail to see that the overall picture is healthier than it appears.

I once had a client who pulled a feature after just three days because it caused a dip in a single metric at launch. There was no time to understand the full impact or whether it was having positive effects in other areas. They jumped to conclusions based on limited data.

Metrics should guide our decision-making, not dictate it. Our actions shouldn't be reduced to simplistic if/then statements (If [metric] goes up = good. If [metric] goes down = bad).

We need to make informed judgment calls, take calculated risks, and have the nerve to give ideas time to succeed. For instance, it's common for website changes to receive initial negative reactions as they disrupt users' procedural knowledge. But if you give people time to adjust, the results often improve.

So, how do we harness the power of metrics while avoiding these pitfalls? Here's my advice:

1. Use a range of metrics: Work with your team to establish metrics that encompass conversion, usability, and engagement. This gives you a more complete picture.
2. Allow time before reacting: Agree upfront on how long you'll wait before responding to data after implementing changes. Expect short-term negative impacts and plan accordingly.
3. Align metrics with overall goals: Challenge short-term metrics by asking whether they truly support your organization's broader objectives.

Implementing these strategies isn't always smooth sailing. Many organizations are deeply entrenched in their thinking, and changing established metrics often falls outside my direct control.

However, by laying these foundations early, we create a reference point for when things go awry. We can revisit these conversations and adjust course as needed.

Remember, metrics are powerful tools, but they're not the end goal. Use them wisely, and they'll guide you toward meaningful improvements and sustainable success.

What are your experiences with metrics? Have you encountered similar challenges? I'd love to hear your experiences! Drop me a reply.