Posts tagged UX
Think Aloud
Jun 29th
The UX Group recently had a session in which fellow Grad Student Amy Gill (who was wonderful!) spoke about her research into the Think Aloud method and how we can use it as practitioners. Perhaps the first thing that came to mind was “isn’t it just a usability test method?” but really it’s a psychology method that we’ve taken and applied to our field. We often forget the origin of the methods we use, but the origins can provide us with a helpful refresher on when and how we should be using these methods.
The Think Aloud method was originally developed for use in Psychology to – surprise! – learn about thought patterns. Originated in 1980 by Simon and Ericsson [1], the theory was a new way of thinking about psychology, recognizing that thought patterns were important and that behaviourism wasn’t necessarily the right path to truly understanding the human brain (ask me about behaviourism another time…). In any case, they proposed that verbal reports can be taken as valid data as long as they are reports of a certain level. Level 1 reports require the least amount of processing – information that is already stored in the brain as verbal code is simply vocalized. Level 2 reports require some processing – information stored in a different format (visual, spatial) is recoded and articulated as verbal code. Level 3 reports require generation of new material that does not already exist in the brain, such as explanations of actions. Of these three levels, only the first two can really be assumed to be valid reports of brain thought patterns thought to interfere to a limited and negligible degree.
What does this mean for usability? Amy explained that perhaps the most distilled point that we can get from the psychological origin of our method is that we shouldn’t ask “Why?”. We should ask it afterwards if we want to really delve into the whys of our participants actions, but not during a Think Aloud task. We want the users to give us an honest and unfiltered stream of consciousness to better understand the mental models they are forming as they use our interfaces. We don’t want them to start analyzing what they’re doing, or giving us the first answer that seems plausible, or telling us what we want to hear.
There was a lot of confusion and some claims of “I ask Why, and it’s worked fine!”, but I think we should keep in mind that Think Aloud is really a method aimed at collecting a specific kind of data: mental models and thought processes. When we want to make sure that our understanding and view of the interface matches up with the user’s, we should use Think Aloud. When we want to see where a user becomes confused, or when the mental processing they have to accomplish in their head becomes overwhelming, we should use Think Aloud. However, when we want to gain an indepth understanding of how and why a user would use this interface, and how well it meets their specific process needs, we might not want to use Think Aloud – maybe consider contextual inquiry or one of the many other useful tools in a usability practitioner’s toolbox.
In either case, Amy’s talk made me think about two main lessons that often get lost in the day-to-day: 1) understanding the history and roots of a method can clarify how to really use it, and 2) pick the data you want, then the method – not vice-versa!
[1] Ericsson, K.A. and H.A. Simon, Verbal reports as data. Psychological Review, 1980. 87(3): p. 215-251.
What sport can teach us about user experience
Mar 22nd
Last night I went to my first ever Lacrosse game, courtesy of my Dad (thanks Dad!). I realized, as I sat there attempting to figure out what Lacrosse was and how it works, that I was in exactly the same position as users are when they use an application for the first time. I knew what it was supposed to be about, but I didn’t know how it worked or how things could be accomplished. By the end of the match I had a basic understanding of what it was about, but I didn’t have an understanding of all of the rules (especially the more complicated ones)… yet I was still happy with my experience! How did I figure out so much about the sport, and what can I learn about users through my own experiences last night?
The most confusing bit of sitting down to watch a game you don’t know is that you have no idea what can be accomplished, and how. I found myself employing a couple different methods to try to figure this out:
Relating it to other games that I did know – Whenever I observed something, like the shot clocks or a yellow flag, I related them to other sports that I was aware of. The scoring was like hockey, but there were shot clocks like basketball, reviews like football, and diving like soccer. Having an understanding of other sports gave me the ability to create a mental model about the sport by weaving together ideas about other sports.
What can we learn? Perhaps users do the same when they use a new program, and attempt to relate different aspects to other similar programs. If we make aspects of our programs function and look like more familiar applications, users may have an easier time guessing how to use it. On the other hand, if applications look like other applications but do not function in a similar manner, users might get very confused. Similarly, we have to make sure we don’t fall into the trap of creating applications with a similar look/feel of another application but slightly different outcomes because users may never notice the difference!
Trial and Error – I found myself making up rules that seemed plausible, and then testing them out. I made some guesses about when players were and weren’t allowed within the area areoundthe net, and then watched the game to see if my rule held true. If the rule held true I kept it, and if it was proven wrong I attempted to either edit it slightly, or completely rewrite it.
What can we learn? Users also make up rules about what different aspects of an application do, and use their interaction with the application to evaluate their rule. If we make sure that the outcome of an action is obvious, it will be easier for users to edit their rules.
The key is GOOD help
Asking Questions - When all else failed, I asked questions to people who seemed to know what was going on. Even though their explanations didn’t always make sense, this was a far faster way to generate a deeper understanding.
What can we learn? Users may just want to ask questions. Although the best design is one that every user can understand without any help, sometimes it’s just not possible. In the end, the quality of help can make a big difference in the experience that a user has with yo
Ultimate Understanding – I didn’t actually leave the game with a complete and in depth knowledge of the game of lacrosse, but I learned enough to be able to follow the game and enjoy watching it.
What can we learn? New users just need to be able to figure out how to do what they want to do. They don’t need to immediately understand all of the complex functions available to them, or all of the expert ways to do them. It is more important that the user can accomplish what they set out to do.
We can learn a lot about how users learn about designs just from knowing what strategies people employ while learning, in any setting. Really, we use the same methods no matter what we’re figuring out. Sports is just one example of how user experience can be seen in areas other than interface design.
The biggest take-home lesson? A fun experience can override confusion or misunderstanding. I don’t understand Lacrosse, but I’m now a fan… GO ROCK GO!