Resistance to user-testing, especially user-testing very early in product development, remains rampant.

A lot of designers, engineers, builders, etc. trust their gut when it comes to how customers, users, and markets will respond to what they want to build.

They don't want to user test with wire frames and bare-bones prototypes and can't imagine iterating to something better than what they've imagined. They just want to build because they already just know what they should build.

How do you overcome this resistance? How do you get them to buy into the value of early UX testing?

1 Answer 1


They just want to build because they already just know what they should build.

Is that an assumption on your part? Isn't it our job to help challenge the assumptions people make about other people, particularly why they do what they do, and what motivates their behavior? How do you know their "gut" isn't right?

User research is supposed to be about understanding the behaviors, needs and motivations of users, but I don't often see that applied that to the people we work with.

Yes, developers and engineers and builders often have strong opinions about what will be better or worse for users. Knee-jerk resistance to UX testing is sometimes due to perceptions what we're doing as this heavy, hand-wavy departmental concern that can only slow the work down, and for dubious benefit.

Ever sat through a mandatory 2-hour meeting about sitting up straight at your keyboard? That's how some developers think about UX testing.

Skepticism is nothing personal, fortunately, and I would argue it's actually a good opportunity to get better at your craft. One part of that is studying the people you work and taking their needs seriously.

They often have the same motives as you: they just want to see their work come to life. They are the immediate customers of UX testing efforts, so progress depends on their contributions.

Help them help you. Dig into their hypotheses, and use their assumptions as the basis for your UX testing. You'll find that when you make a case with reason and involve them in the research, they not only lighten up but may actually loop you in and defer more of the research questions your way. You never know - maybe they're tired of defending decisions to one another and would welcome some help from an objective approach.

Make a point of understanding how early UX testing applies to what they're doing, and be able to explain that in layman' terms. Don't carpet-bomb the same generic explanations some UX professionals give each other, i.e "better and more usable products" or "greater empathy" or something equally subjective and non-falsifiable. Tailor the story to the audience.

For example, project managers' ability to deliver on deadlines is only as good as their ability to accurately size effort. Early UX testing helps reduce project uncertainty by focusing project scope around work which has been validated with customers.

With developers, you can strike the same nerve a different way. Good programmers make disciplined reuse of patterns, and in my experience they don't want to make code additions or changes without a compelling business case and pressure from management. UX testing designs with customers before actually building them can help take some of the pressure off developers so they can just code without fear they're "building the wrong thing."

UX testing is not a silver bullet of course, but unless they're eating the dog food it is a lot better than guessing.

Ultimately, we all work for the customer and are on the same team. It's not enough to know about testing, doing this work well is about understanding people. Find a way to defuse some of those tense conversations that happen during push-back, you may find uncover some great opportunities.

  • 1
    My developer partner "knows" he's building the right thing, that customers will love it, that it will sell once built. He won't user/market test anything, even though he knows it can be tested with pen and paper. (We're making math education software.) As for his hypotheses, he "knows": (1) He can find parents of students who will ignore school work to do his lessons, (2) His software-based lessons will be awesome, and (3) Customers will pay as they learn instead of by the hour. He "knows" he shouldn't test any of this, since testing is a waste of time if he's right. What should I say next? Commented Jul 11, 2017 at 21:31
  • P.S. I have been a self-employed, full-time math tutor for 8 years and have been pretty involved in math education workshops, conferences, classes, discussions, etc. I am 99% sure all of his hypotheses are massively wrong. Commented Jul 11, 2017 at 21:34
  • @WeCanLearnAnything - people sometimes avoid testing for fear of being proven wrong, and this is purely about ego. Honest beginners outgrow that fear on the path to learning something, while hacks just get bored and go back to their own private Idaho where they live without any fear of ever being wrong. If this guy is as delusional as you say and you're 99% sure all of his hypotheses are massively wrong, then you should think twice about using him as your developer partner. If he'd rather be "correct" than successful, wouldn't you rather be somewhere else?
    – Luke Smith
    Commented Jul 13, 2017 at 3:43
  • @WeCanLearnAnything p.s. how committed are you to getting a prescribed answer, vs one you didn't see coming and yet are confident is a valid result? Would you entertain the 1% probability that you've got it all wrong, if it results in your learning something new about the world? Just a thought.
    – Luke Smith
    Commented Jul 13, 2017 at 3:49
  • This week, I began my search for another partner due to his unwillingness to user/market test. If I'm wrong, then I want to find out immediately through user/market testing, which he won't do, even though we could easily build a series of lessons by hand and market test in a matter of days. I told my former partner to contact me in ~6 months or so after he has built and tested his ideas. Commented Jul 14, 2017 at 17:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.