I usually just tell them something along the lines of, “Oh, no, not at all.” If they persist, or if it really seems to be an issue, I do the traditional spiel about “this is not a test of you.”
If that doesn’t seem to be getting through, though, I usually follow that up with:
“This is a test of the system. You can do no wrong here today. If there’s a problem, it’s a problem with the website [or app or whatever], and I want to hear about it. That way, we can fix it up, and it won’t be a problem for others.”
I might also talk about how they were recruited just for this test and are the perfect person for it, that the system was designed for someone just like them, and that I’ve got 10 other people coming in that week who are exactly like them. I don’t like to do it, but if the user is really struggling with this issue, I might even go so far as to mention that other users had exact the same problem.
Now, on the other hand, there are also some team members who love to blame the users as well. With them, my approach is a little bit different. ;^) I might start out by cocking my head, frowning, and giving them the eye. If that doesn’t work, I usually point out that this person is a customer. Now, I might also sympathize a little with them by confessing that the user was difficult for me as a facilitator and that they were definitely on one side of the sophistication scale. That said, I also try to firmly get across the fact that this is a real user and needs to be addressed somehow in the design.
And if that doesn’t work, I have no hesitation about reading that observer the riot act. That usually involves reiterating that the “user is not you,” there are many different user types, empathy is a sure sign of a good designer, and – finally – these “idiots” also just so happen to be paying your salary.