When conducting and writing up user research findings, I make a point of defining the experience goals alongside participant’s actual real life goals.  This is because, as users interact with a system, they are made to feel a certain way – just as people can, software can bring the best or the worst out of a user.  Yet, while users’ feelings are part of the usability of a software product, we don’t often test to understand that side of user experience.
When I conduct any kind of research with users, I pay attention to how people are feeling and to how they want to feel.  For example, of two people who want to use a website to check on their finances, one can tell me:  “I want to be in control at all times”; whereas  the other might say: “I expect to be alerted when something goes wrong”.  To me these two ways of feeling when someone uses software translate into different interface design requirements. The first person wants an interface that makes her feel in control, such as a dashboard tool; while the second user wants something that makes him feel taken care of, e.g., timely reminders and alerts.

All features of an interface can make people feel one way or another.  For example, a simple fact like a lack of feedback on a system’s operation, combined with the use of technical vocabulary, can often cause people to feel discomfited and insecure and may cause them to hate the product – but often we overlook users’ feelings in strategy and design in favour of making sure we transmit the information and functionalities we intend.  Yet, learning and adoption often depend on the level of enjoyment and confidence a user experiences while engaged with the product.

Rhythmbox

The usability testing of Rhythmbox highlights the power of an interface to stimulate emotions by means of design. In this blog post I will only discuss the findings relating to usability and emotions.  A full description of the results of the test is available in the attached pdf.  This test was conducted in June 2010 at Canonical.

Many participants expressed feeling inadequate when interacting with Rhythmbox. That said, many of the usability problems participants experienced, some of them serious to the point of preventing them from completing their tasks, could have been easily avoided by:

1. offering well-crafted dialogues that anticipate users’ expectations and also provide immediate feedback whenever errors or an idiosyncratic system behaviour occurs.  The application should accompany its users through the process of obtaining, listening and organizing music.
2. using language that bridges users’ activities and experiences to the domain they are engaged in.  As a case in point, when participants are playing with music they are thinking of songs and albums, not of files and folders.

What was striking during the testing sessions was how participants expressed themselves at several junctures of their experience, not in terms of what they wanted to achieve but rather in terms of how they felt:

“I feel dumb right now.  It is not doing anything.” [Participant has entered the name of a radio station in the search box of radio, thinking the search box will allow her to find any station she wants.  She is not getting any feedback about what’s going on.]
“I cannot find a way to put it in the library.  I’m dying here, it is not going well, help!”  [Importing songs into the library.]
“My head is spinning.” [Trying to subscribe to a podcast.]
“It’s just frustrating because I don’t know what to do.” [Looking around to find where his music has been downloaded.]
“I cannot control where the piece will show up.”
“I feel like an idiot.  I don’t know why it’s not working.” [Trying to get a podcast and looking for a suitable url.]
“I feel stupid that I can’t find a podcast.”  [Trying to get a podcast.]
“I feel I am missing something.”

These strong feelings came from participants’ inability to predict Rhythmbox:

“I don’t know where this is putting everything.” [Trying to import music from MP3 player – trying to import music in the music sub-folder.]
“I presume the tracks I just played would appear here.  But they don’t. I have no idea why.  I would presume they would be there.”  [Recently played tracks that are not played fully don’t appear in ‘recently played’.]
“(…) it is not clear.  [I] would not know how to put it in my computer.  I expected a pop-up that tells me what to do.”  [Importing music from CD – no guidance from Rhythmbox about what to do.]
“I don’t know [if there is rock and roll music in radio] because there is nothing going on.”  [Participant is trying to find a radio station that plays rock and roll.  She hasn’t spelled ‘rock and roll’ in the same way it is spelled in Rhythmbox.  She gets no results, that is, all she gets is a blank screen without indication of why and what to do.]
“I don’t know what it wants me to do.” [Trying to connect to Last.fm and finding only an option to sign up or join Rhythmbox group.]
“The app is not giving me anything on what I should do to carry on.  Maybe I’m just stupid.” [Trying to enter a url for a podcast.]
“It doesn’t really tell you that it is working or not.” [Trying to get a proper url for a podcast.]
“I don’t understand.  I would have done it by now or something should be flashing.  Now, I am stuck.” [Importing music from a CD, participant doesn’t know if it is in the library already or not.]

This level of emotional discomfort is alarming to users and poses a serious challenge to adoption. Accordingly, it needs to be mitigated and managed.  Rhythmbox users should feel happy and entertained and not stressed out.  To create an environment that stimulates good emotional states, the application needs to anticipate what users want to accomplish, and it should give users a full understanding of how they can achieve it.
There are two strategies Rhythmbox could adopt to greatly change users’ feelings:  first, use language that resonate with users, that is, language that users would themselves use to name buttons and actions; and two, provide feedback to users to keep them aware of how the application is responding to their actions, and in addition provide general guidance through the process.
Let’s look at examples where such interventions are needed.

Unfamiliar or Decontextualised Language

Rhythmbox often uses language that, rather than describing what participants are doing from their point of view, describes what is going on from the application’s point of view.

Example 1:  When importing music from various devices.

From a USB memory key

“It said ‘open’ but in fact it is ‘import’.  I wasn’t sure [what to do].” [Importing a song from a memory stick.]
“What is a home folder? Why do I need a home folder?”  [Import music from a MP3 player.]

Participants did not understand the language used to refer to their songs, including such words as ‘folder’, ‘file’, ‘open’, ‘cancel’.  These words were not generally expected to be found in a music environment.  When one clicks on ‘move’, for example, the system offers to move the ‘file’ to a ‘home folder’, and this was very confusing to our participants.  Participants could not understand what was expected from them because of the language that was used.
Suggestion:  use words like album, song, rip-it.

From a CD

A second example of the use of unfamiliar or unintuitive terms can be found in the interaction when participants are looking for podcasts. A few participants, for example, who came across the button ‘Copy tracks to the library’ were not sure what it meant.

“It is not obvious, if it said “Copy music from CD”, it would be more obvious.  I don’t know where the library is.  I want to know where the tracks would go.”

Example 2:  Adding a podcast and a radio station

Participants did not understand many words used in the section on podcast, including ‘episodes’ and ‘feeds’.  They thought of a podcast as a single unit and not in the context of a series.
Another problem they encountered pertained to the language of the dialogue box requesting a URL.  One participant admitted that she didn’t even know what a url was, and she did not know how to obtain it.

Example 3:  Looking at missing files

One participant looked under ‘missing files’ and found a list of songs.  He had no idea what these ‘files’ were and why they would be missing.

Language was an important contributor to how people felt because when participants came upon words they didn’t understand, they felt that Rhythmbox was not meant for them. If the words used throughout Rhythmbox were chosen from users’ speak, users would feel that the application is friendlier and would be themselves friendlier towards it.

Lack of Feedback

Another important area of Rhythmbox that posed usability problems and created a feeling of being lost and inadequate can be found in a lack of feedback about what the system is doing in reaction to a user request.  Often, participants would do a search or make a request and Rhythmbox would display a blank screen.  Participants did not know if their request had been taken into account, if they did not do the right thing, or if there were no answer or data to be had.  Participants could not tell the difference between what was an error and what was a mistake.  Accordingly, they were not empowered to recover when something went wrong.  A few interactions where Rhythmbox provided no feedback early on sufficed to make participants generally pessimistic about their success in using Rhythmbox.

In the examples below, participants didn’t understand what the system was doing and what was expected from them to move forward.  A well-crafted dialogue box communicating what is happening or what to do next would solve many of these problems.

Example 1:  adding a radio station

Participants did not know the purpose of the search box and what sources it would search through.  When they tried to search for a radio station they would get a blank screen where results should appear and no message that the search had brought no results or a message that would let them know what type of research was possible.  Consequently, participants were stuck and couldn’t anticipate what to do next.
Suggestion:  Indicate the search has found no results and make suggestions for possible searches.

Example 2:  searching for a station

One participant tried to find a radio station that played rock and roll music.  She entered ‘rock and roll’ in the search box and got a blank screen in response to her request.  She didn’t know if there were no rock and roll stations or if it was not searching in the right place.  In fact, the problem was with the way she spelled ‘rock and roll’ which was different from how Rhythmbox spelled it.

Example 3:  looking for recently played songs

At the end of the usability session, participants were asked to find the songs they had played during the session.  When they went to ‘recently played’ they found a blank screen.  They didn’t know why their songs were not showing.   They needed to figure out  that only the songs they had listened to to the end would show up in that section.  Many concluded that Rhythmbox just didn’t work.

Every usability test uncovers specific issues.  I wrote, for example, on how, with Empathy, the main problem resided in a disconnect between how users assumed how the software would display information on the basis of being a social networking application and how Empathy itself had, rather, taken the model of an email server for historical reasons unknown to new users.  This disconnect perturbed the user experience and made it less fluid. With Rhythmbox, it was a use of technical and work-based language combined with a lack of feedback that caused the most problems to participants and illustrated how deeply an interaction design can affect users’ emotional states and their confidence in the software.