You've got an ugly baby

Imagine your best friend has just had a baby, something they’ve been hoping for for years. You’re so excited, dying to meet your new God-child. Your friend asks you to sit down while she grabs the baby, and places the little love-bug in your arms. You move the blanket to take a peek at that gorgeous little face and… is it a gremlin? A hobbit? Some sort of Benjamin Button situation? But of course, you coo and gasp and tell your friend how beautiful and angelic their spawn is. How could you tell her the truth?

 

Who in their right mind would have the strength to say they’ve got an ugly baby?

 

This is how our users can feel when they come in to test our prototypes. When they first meet us, they are walking into our territory (or home) to look at our interface (or baby). We’ve paid for them to be there, so they will start from the perspective that it’s them and us (the facilitator and interface are the ‘them’).

There is a separation, however unintentional, between us - and that separation can easily lead to false coo’s and reports of beauty. We are asking them to review something, we are paying for their time, and because of this they want to be on our side. They want to be ‘right’ and to be similar to us (a basic human trait), and - most importantly - to do well.

It’s entirely human to feel worried about being embarrassed, or to worry about admitting we are wrong. The act of failing shows us where we aren’t standing up to societal expectations and standards, and this can be amplified when in the presence of other people (Lamia, 2011). This is thanks to the Spotlight Effect - the tendency that we have to think that many more people are watching us and paying attention to us then actually are (Gordon, 2013). We are left feeling vulnerable and exposed, and desperately trying to please and do it right. So how does this affect us in the UX world?

User testing is something we’ve written about before and continue to research. It’s a crucial step in understanding user needs and thought processes, and from there we can design useful, intuitive and innovative products that make users happy. And the first step in that is setting the right psychological environment to get the right responses from the participants.

 

We take steps to make our participants feel as relaxed as possible - we indicate that we are not testing them, that we are looking for ways to improve the design. We meet them and greet them and shake hands, forming minor (but important) bonds. We explain that we didn’t design the interface (creating space between us as facilitators and the interface itself), and we sit close to them but looking at the screen, to physically place us ‘on their side’. For most people, this does relax them and they openly discuss any flaws or issues with the design.

For others we need to expand on this behaviour and continually reinforce this. We need to confirm that their feedback (positive or negative) is good, and is helpful - showing them that we are in their team and the interface is the thing we’re looking at. We have to be careful not to reinforce the wrong thing though - showing agreement with a positive comment can quickly lead to people thinking we want to hear positive feedback, which leads us back to psychological square one.

But some people will still struggle with a task or a question during testing, and we as testers will observe this happening. When we then ask them about the task and look for feedback, they might answer something along the lines of ‘That was easy, once I knew where to look’, or ‘I didn’t think of looking there, but now that you’ve pointed it out it makes sense’. So how do we know whether to record this is a problem, or to take their word for it? Well, one indication could be if others struggle with the same task, but this isn’t always reliable - when one out of five or six people struggle that can still relate to a fair percentage of your audience.

 

The problem with ignoring the one person problem is that we can potentially miss issues that could be minor, but are still causing confusion and trouble for our users. We can try and reassure them as much as possible, but some people will still insist that it was their fault and there is no flaw in the design.

To help us help our users, we need to understand how trust works. How it can be formed, maintained, or broken with people we have just met. We need to get them on our team, to help them understand that it’s us and them vs the prototype. Some of this can be done verbally - reassuring them of the above mentioned points - that we did not design the prototype, that we are not testing their abilities, that we are independent and looking for flaws. We can also build trust with our users using body language. Being warm and welcoming, giving the person a handshake and big smile on greeting them can help.

But in user experience, one of our best weapons is truly being not invested. We have to project complete disinvestment in the current design and that we are there for them - to help them and to learn from them. We don’t want to lead our users into an answer, by influencing them one way or another.

So what can we do? Well, we focus on a three step approach - The Promise, the Price and the Guarantee. In terms of user testing, the Promise is making clear what they are getting in return - an incentive, for example. The price is what you are asking for in return - for them to be in the test for a certain amount of time, going through the prototype with you. The Guarantee is what happens if something goes wrong - and this is where a large amount of trust can be built up. We explain that we can stop the session, we can stop recording, we can solve whatever problems might occur. While this might not fully relax all participants, covering all of these factors with them can ensure we can try and make them feel as comfortable as possible.

 

We have to remember that at the end of the day, even if it isn’t, our users view the prototype as our baby. And if it’s ugly, they’re not always going to want to share that with us.