How the Usability Matrix of Emotions Can Benefit Your Software Testing

[article]
Summary:

Emotional response is a big deal in usability, but how much do the emotions preceding those responses play a part? David Greenlees explains how the Usability Matrix of Emotions can capture the more common emotions that users may have when they begin to use the software product you oversee and how understanding these emotions can shape your usability testing.

The importance of emotions in usability testing is well known, however the focus is more commonly put on the emotions that are produced during and after the use of a software product. The emotions a user has prior to using the product can play a big part in usability, and should therefore be given the same level of importance as those.

Let’s take a look at an easy way to try and catch some of those emotions before your product hits the virtual shelves.

This concept didn't come to me while I was working on a project for a client, as concepts normally do. I was sitting on a bus, I was tired (it was the end of the working day), and I was annoyed as the bus was full and I was somewhat squashed with one leg pushed into the aisle. I'm lucky that this was a relatively short bus trip home for me, but that was not enough to alter my mood to a more positive one.

I needed to log into an online auction site as there was an item I had my eye on and the auction was ending soon. Normally, I would just place my maximum bid long before the auction ends and be comfortable with the fact that I may not get the item; I’m usually happy when the software behind the auction site stops me from reaching my maximum bid. On this occasion, however, I really wanted the item.

Considering all the emotions and feelings I already had, adding anxiety to the list made me very uncomfortable. Now is probably a good time to mention that last-minute bidding and I don't mix. I get incredibly anxious; I always have.

There was ten minutes left and I watched as the price increased incrementally. Having to hit the refresh button was rather annoying, I might add. With a few minutes to go I began to bid. The process of placing the bid and confirming it was not entirely confusing, but it was quite painful. Perhaps dealing with the changing 3G-connection speed was part of the issue; however, I do think there were some unnecessary steps in the process.

With a minute to go, I quit because of so many distractions: the bus was bumping around, the elbow of the passenger next to me hit me in my ribs, I was tired, my nerves were agitated, and the overall bidding process was tedious. I couldn't take it anymore, and I came to the conclusion that the item just wasn't worth it.

Upon reflection I find it very hard to believe that for the sake of one minute I actually let the item go, but I did. Whatever was happening to me at the time was enough for me to give up on the bidding process.

Is this an uncommon or rare scenario? I think not, although I will admit I have no concrete data to back that up.

All of the emotions and feelings brought on by my surroundings were not in the control of the software designers or developers; however, the bidding process was. Would I have quit if the bidding process was simpler? While I can't be sure, I'm certain that it would have somehow impacted my decision.

So, how did this experience change the way I view emotions in usability testing, and the way I believe we should all view them?

Have you ever stopped to think about how your users may be feeling at the more common times and places of use for your software? Of course you have if you're a UX designer, but what about the usability testers and practitioners out there?

Throughout my career I've seen many different emotional responses during usability evaluations and testing, and I also learned to understand the potential impact of those responses. It was only in more recent years that I learned the importance of which emotions a user might have preceding an evaluations or what emotions may be brought on by the user’s surroundings at the time of use.

There is no doubt that you can gain very insightful information from a user who begins to get angry using your software, but what about a user who was angry before he started using it? How would that impact his use? Would it lower his “reservoir of goodwill?(1)” Would it change the way he interacts with your software? For example, would the user hit the device's screen rather than tap it?

Enter the Usability Matrix of Emotions.

The Usability Matrix of Emotions is a tool I have begun to use in order to capture the more common emotions that users may have when they begin to use the software product I am overseeing; it’s very easy to set up, but more difficult to use than you might first think.

fig 1

Figure 1. Example matrix of emotions.

 

The Concept
The first part of the matrix lists the application and its features, if there is a logical way to break these up, and the potential emotions that those features could induce. The second part takes it a step further and introduces locations of use and the potential emotions that those locations could bring on.

Combine the two and you have a mash-up of potential emotions that your users may be feeling before and during the use of your software.

For example, using the above matrix, we have highlighted that bidding on an item makes this particular user excited, nervous and anxious, and gives them a feeling of being rushed. If this user was sitting on the bus at the time of bidding, she would enter into the bidding process feeling angry (she hates the bus), she might feel nervous or anxious (crowds are not her favorite thing), and she might be tired (it’s been a long day at the office). Overall, you can imagine that an application with poor usability could push this person “over the edge.”

The trick is getting the most common emotions listed for your software's context. For example, you could imagine that “nervous/anxious” would be a common emotion for users of emergency medical software. It would be extremely important to test how those users interact with the software while under the stresses of emergency medical situations. Guidance from the software such as prompts or help text would need to be very clear, and its inputs must be quick, easy, and accurate.

So, as we commonly do in usability, we need to think about our users’ demographics. As your software morphs into bigger and hopefully better things, you can easily add to your matrices.

The Hard Part
How do you induce emotions? Actually, let me reword that; how do you induce potentially negative emotions in a professional environment while conducting usability evaluations? If you have pictures in your mind of a fighter making his way to the ring while his trainer is slapping him across the face in order to make him angry, then you’re off the mark, unfortunately. If only it were that easy.

The question of whether or not you need to induce emotions is one that I cannot answer; it is fraught with potential danger. The last thing you want to do is slap your tester across the face before he sits down with your software! The lawsuit would not be worth the potential usability insights gained.

There is, of course, the potential to test and conduct usability evaluations in the wild. If it’s possible, perhaps ride the bus with the user or join them for a coffee in the café while he uses the software. This can be a great way to induce required emotions, but logistically it can also be quite difficult.

Instead, you can use past evaluation experience—in fact, any past software user experience. Have you ever had a usability tester who was already displaying a certain emotion come in for an evaluation? Did you notice any difference in the way he used the software that could be directly related to his emotions? If so, then capture that knowledge. Use that knowledge to drive the way you interact with software while performing usability testing yourself.

For example, I have noticed that particularly frustrated users will not wait long between mouse clicks. They have a tendency to keep clicking until there is some sort of visual change apparent to them. Would it be a viable option to add some sort of visual-thinking representation to the software in order to avoid the multi-click crash? If your user demographic consists of people in environments that induce higher levels of frustration, then perhaps it would.

Here’s one final way to look at it: would you have caught the multi-click crash if you didn’t use your Usability Matrix of Emotions for guidance?

Footnotes:
(1) Reservoir of goodwill - Steve Krug, Don't Make Me Think

User Comments

3 comments
duncan nisbet's picture
duncan nisbet

Great model David should really help with an aspect of my testing which I consider to be rather weak.

I'm going to try & apply the model at work...

October 15, 2013 - 8:06am
Liz Renton's picture
Liz Renton

Interesting. Although it probably sounds a bit corny I wonder whether sometimes some 'role play' might even be useful to test these types of scenarios if they are considered to be likely to occur for users of an application. In the same way that we would ideally simulate the environmental conditions of use, it may be worth considering simulating the situation of use e.g. people trying use application under pressure of a time constraint or when they are tired or both.

It can also be useful to approach this from the other direction. E.g. if you notice yourself (or other testers) are getting frustrated or impatient it can be worth stepping back to examine whether this is related to the design of the application, the situation of use, or some other unrelated factor.

September 30, 2013 - 7:37pm
Parimala Hariprasad's picture
Parimala Hariprasad

Great perspective David. This matrix if used in the eCommerce and mobile world can be very very powerful!

Thanks for sharing!

November 21, 2013 - 7:34am

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.