As I said in the last lesson, shifting responsibility for user research, testing, and prototyping onto colleagues won’t land smoothly with everyone. It’s a big ask. To make progress, you need to get ahead of objections: both the ones people voice and the ones they keep to themselves.

When I coach teams through this transition, I encourage them to start conversations by acknowledging concerns upfront. A simple line like, “I know some of you might have concerns about this approach, so let me share a few thoughts before we dive in” takes the sting out of resistance.

It is tempting to avoid focusing on the objections for fear that you will plant them in people's minds. However, in my experience, you're better off getting ahead of these things. Because once somebody expresses an objection, they tend not to back down. However, if you raise the issue first, then they can choose not to pursue it further.

Here are the most common objections you’re likely to face and a few hints on how to address them. This isn’t an exhaustive list and you will need to customize your responses to suit your audience and situation. However, they should point you in the right direction.

“I don’t have time to add UX activities.”

Lightweight UX techniques save time by catching issues early and reducing endless revisions later. A five-minute sketch or quick test can prevent weeks of rework.

“This is your job, not mine.”

UX is everyone’s responsibility. Just as safety isn’t only the job of the health and safety team, user experience can’t sit in one silo. Your team provides guidance and oversight, but the workload must be shared if projects are to succeed.

“UX isn’t in my job description.”

Point out that creating a good user experience is baked into every role that shapes products and services. It’s not an add-on. Instead, it’s a fundamental part of doing any job well.

“I’m not a UX expert. Won’t quality suffer?”

Right now, many projects get little or no UX attention because your team is overstretched. Equipping colleagues to do the basics raises the overall standard. You’ll still be there to provide coaching and set guardrails.

“UX will slow projects down.”

In fact, the opposite is true. Without UX input, teams burn time in debates and rework. Suggest piloting the approach on one project, if it doesn’t help, they don’t need to continue.

“We’ve always done it this way.”

User expectations have shifted dramatically. As IBM notes, “A user’s last best experience becomes their minimum expectation.” The old way can’t keep up with rising standards.

“This will require extra resources.”

You’ll provide templates, tools, and training. The only added resource is a little attention, which quickly pays for itself in smoother delivery.

“I don’t want to be accountable for UX outcomes.”

Reassure colleagues that the UX team retains overall responsibility. Their role is to contribute, not to carry the full weight. You remain the safety net.

Objections are normal. Treat them as signals of what colleagues need to feel safe trying something new. Anticipate them, respond clearly, and keep the tone supportive rather than defensive.

In the next lesson, we’ll explore the resources, support services, and educational materials that make this shift stick.

Talk soon,

Paul