Another unnecessarily confusing interface

I checked in for a flight last week using a self-serve kiosk. When I first approached it said "Touch screen to begin," so I poked the screen. It beeped and displayed a second screen that said something like "Choose an option" and listed five methods for identifying myself—swipe a credit card, swipe my passport, scan a printed boarding pass, and two others I can't remember. Each of the five options was displayed inside a large square box that looked like a button or a three dimensional frame. I wanted to use my passport so I poked the screen inside the passport area. The screen beeped and nothing happened. I assumed it was just slow. I waited but still nothing happened. I poked the screen again. Nothing. I poked it again. Still nothing.

Eventually I decided to try swiping my passport. I opened it up and found a bar code type area and swiped that, but it didn't work. I swiped it a couple more times, varying the speed and direction, but still nothing.

I poked the screen again. Beep, and then nothing.

I studied the picture inside the button more closely and tried to orient my passport the same way as in the picture, and swiped it again. Finally the machine recognized my passport and a new screen was displayed. From there things went smoothly.

But that was needlessly frustrating. Why make the options look like targets if I wasn't supposed to touch them? Why hide the list of options behind a "Touch screen to begin" page, priming me with the idea that I interact with this device by poking the screen, instead of just listing the options on the front screen so I can swipe my passport before interacting with the screen? It was like the interface was designed to lead me astray.

Perhaps the best redesign would be to go with the perceived affordance of touching the option you want to use, and show a second page saying "Swipe your passport in the slot above." Then there would be enough room to show a video of a passport being swiped and a picture calling out the part of the passport that the machine wanted to read, so I wouldn't have had to try to guess from a tiny iconograph how I was supposed to do the swiping.

How do you test what someone doesn't expect to be able to do?

Interpreting the results of a usability test is tricky at the best of times, but in a study I recently conducted I found that it's even more difficult when the feature you're testing is something your users don't expect the software to be able to do. In this type of situation, the interface has to reveal the software's capabilities to the user in addition to making those capabilities easy to use. That's an additional constraint on the design. (Normally the user expects to be able to accomplish something with the software, and the interface's task is to match the user's mental model—their expectation of how the feature should—as well as possible, or to bridge the gap between their mental model and the system's implementation. In this case, the user has no mental model, or their mental model doesn't extend that far.)

So how do you test something the user doesn't expect to be able to do? And how do you interpret the results?

I can't discuss the details of my test but I can use a roughly parallel example. Imagine you were testing the Smart Playlist feature in iTunes (the ability to create a playlist that automatically fills with songs based on criteria you set, like genre, artist, rating, or any combination of attributes). Many iTunes users I know have never heard of this feature. If you were testing it, what would you do?

What we decided to do was give them a scenario that we thought would supply the expectation for them. In the iTunes example, this might be something like: "Create a playlist that automatically includes all of your Rock songs from the 1980s."

Now imagine that all of your test participants immediately tried searching for 1980s Rock songs in their music library and then looked for a way to add these to a playlist. And when you informed them that there was another way to complete the task, they tried creating a playlist and calling it "1980s Rock."

In this case, the scenario seemed to prompt the participants to imagine capabilities the software doesn't have (saving search results as a playlist, filling a playlist based on its name), instead of the one it does have that they didn't expect.

Does that mean the Smart Playlist feature is difficult to use?

I don't think so. It seems like anyone who discovered Smart Playlists would bypass the confusion that was uncovered during the tests, and discovering it in context would do a better job at setting their expectations about it than the scenario did.

In short, it seems like the scenario created the confusion, and thus the difficulties encountered in the task really tell us little to nothing about the usability of the feature we set out to measure.

I'll have to try something different next time.

A glimpse behind the walls at Cooper

This video shows how Cooper uses Adobe Fireworks to do their interface design. It also provides a glimpse into how they divide the design tasks between an interaction designer and a visual designer.



I don't know much about Fireworks, but it looks like it might allow you to prototype interactive designs. One of the things I find most difficult about designing in Visio is that the screens are all static; it's very difficult to document a more complex in-page interaction with a tool like this. It's also difficult to work out the interaction in the first place without a tool that lets you quickly build it and try it.

I also like how they've divided the work involved in designing and developing software into discrete specialties. I think the level of polish and sophistication they're able to obtain as a result is the best answer to 37signals' argument that Web designers should also be web developers.