Don’t fear mistakes. There are none. (Miles Davis)

I feel for my UX teams – the IAs, the IDs, the writers, the graphic designers, even the coders. They put their hearts and souls into their designs. It must really be hard to watch someone rip it apart or fail miserably trying to actually use it. And that must be especially difficult when you have to simply sit there and watch, with a thick piece of one-way glass between you and that user.

Something similar happens during any usability test report-out. Reports tend to simply report the findings – and not point fingers – but it still must be hard to hear. 

Now, personally, I do try to do some things in my reports that can help the team feel a little better. Probably the most important is to make sure there are positive results (ones to celebrate) as well as negative ones (ones to fix). 

I also do something similar during actual testing as well. Like most usability engineers (at least I would hope), I try to debrief after every user. These things – at least for the first few users – tend to be a little awkward. One way I’ve found effective to break the ice is to offer a few observations about things that worked well. That usually gets the ball rolling, and the team will naturally move on to the things that didn’t work so well.

A lot, however, depends upon the individual. Some people are just a lot more sensitive than others. I find that sensitivity is especially the case for newer team members and for those who are simply new to usability testing or UX in general. (Very experienced designers can’t wait to get into the lab. Their philosophy is generally, “Bring it on!”)

In fact, I’ve actually noticed that these newer team members often go through something not unlike Elizabeth Kubler-Ross’s Five Stages of Grief. The first step, for example, is usually a combination of Kubler-Ross’s first three – denial, anger, and bargaining. For example, observers might ask, “Where do you get these users from?” Or they might focus on issues with the prototype or with questions and carping about methodology. The best way to handle observers at this stage is to just get them to not over-react (even if this means allowing them to vent a little) and to make sure that they come to some more tests. 

A second stage – after a number of users or even after a number of tests – is often something not unlike depression. When that happens, I try to be supportive. I might, for example, point out what worked well or some easy fixes. Finally, though, the observer reaches acceptance. And at that point, they are probably pretty well sold.

One thing that I like to tell observers wherever they are on their journey is that testing their stuff and incorporating the feedback is a real feather in their cap. I also go on to say that not everyone gets a chance to get their stuff tested, and that their willingness to do so really separates them from the average IA, ID, writer, graphic designer, or even coder.

One of my all-time faves