Katie
Dear Ping…
Aug 13th
Dear Ping,
I love your golf clubs and all, but this online club fitter app is giving me a complex. It appears that, according to your scale, I’m about the height of an average woman’s thigh. If I was 4’11″, I’d be at her ankle! What gives? Why is there even an image of a woman at all?
Sometimes, a simple form is better…
Thanks
Katie
PS: Can I have some free golf clubs?
Can we talk about data visualization?
Jul 28th
This is a visualization done by IBM to visualize the World Factbook (or so I am told by UX Mag, can’t seem to find IBM’s name on it anywhere…). I have a couple constructive criticisms about this visualization that I think can help us learn about visualizations and data manipulation. Generally, data visualizations should help you to easily navigate great amounts of data with ease, but they are difficult to make and, with so much data, can be easily confusing or unwieldy. Here’s what the of the World Factbook interface looks like when you enter:
Essentially, you click on the top panel to change what the colours represent, and you can click on a country to view more about it in the left hand bar. Perhaps the first and most interesting thing that one would want to do is change the colours of the countries so that they can get a view of all the different overarching data chunks. I would say that the first thing 90% of us would do is click on a country, as the top panel with different data points fades into the background. Certainly I barely noticed it, but it’s the portal to 8 different sets of data about the world.
Now, I clicked on a country first since that seemed like the most obvious thing. This zoomed into the country, and displayed this bar on the left hand side.
I immediately tried to play with the sliders, but they don’t slide! I’ve used data representation in this way before (lines with circles to indicate data points) and thought nothing of it (see the Personas in my portfolio). But have we come to assume that balls on lines are sliders? Without thinking, I had tried to move the little circles. How easily I see they are data points when I made them, but how easily I forget when it’s not my creation. Perhaps something to consider next time?
Now, the meat. I think it’s important that, as a user, I understand what an interface element will do. What’s going to happen when I click on a button or move a slider? Here’s where this interface really fails me.
(Click for a larger image)
There are three controls that didn’t feel connected to their outputs. To start, the control at the top controls what the colours represent, changing the meaning of the legend at the bottom. There are words at the top describing the action (“Color shows”) but they didn’t quite tie together what the colour changes meant. The second control that I didn’t quite understand was the slider at the bottom (the “Dynamic Legend”). Dragging the markers around on the bar changed the meaning of the legend colours (and the colours on the map itself). This seemed oddly coupled, and somewhat redundant. Why not just put the numbers on the slider and use the single, dynamic legend? Why have a controller for the legend that showed the same information (visually, rather than in numbers – arguably better)? Finally, there is a checkbox in the bottom right corner called “Neighbourhood View”. It changes the map view slightly, but most noticeably changes the data presented on the left hand side of the screen – oddly far away.
Anyway, neat that they were able to pull all of this information together, but I think maybe a bit of usability testing might improve this interface dramatically.
Mobile First? Mobile First!
Jul 16th
I agree with Luke Wroblewski – Maybe we should be designing for mobile first. Especially if we’re aiming at the “youth” of today and tomorrow…
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.