LarryRoth.net

Excuse the headline. To be clear, I do think that usability tests are very valuable. But often times they provide little data beyond what you are testing—for instance, the labeling of the primary navigation. Yes, seasoned testers can often times extrapolate large amounts of observational data, but sometimes the really niche features of a Web site aren’t so easily discovered. Users seldom provide ancillary ideas for features they may need. Instead the idea for a feature usually only occurs to a user when they needs it. So, when a feature pops up for me at exactly the time I need it, in exactly the place I need it, to me it means somebody really thought the problem through, perhaps even cared about me a little. To me it says: “hey, we want to make your life easier”.

All usability experts focus on the user first. That is, quite simply, what we sign up to do. As such, we often refrain from  ”feature-itis”—defined as adding features for the sake of having more functionality. Additional features often times do little more than round out a sell-sheet of product benefits, hardly ever benefiting the user. But there are many times when a well conceived feature can pay off not only for the user, but for the service provider as well. And I must correct myself, when discussing this blog post with a colleague of mine, Ernie Bello, he rightfully pointed out that it’s not the feature itself, but the execution of the feature that makes it usable or not.

As an example, I had purchased a couple songs from the iTunes Music Store by Canadian artist Sass Jordan. I know, I know, it’s 2009, but I just have this thing for Canadian rock from 2 decades ago. After listening to the two songs I had purchased (about 10 times), I decided to get a couple more. Of course, now I was regretting that I hadn’t purchased the whole album and saved a little money. That’s when I discovered this:

Example from the iTune Music Store

Note how when returning to the album from which I have already bought a couple songs, I am prompted to complete my album. It’s clear, obvious, and exactly where it should be. I am sure that many of you will point out that this is also a benefit for Apple, and that may be the case. But the point is, the very feature I wanted, existed when I needed it, and where I needed it—even thought I didn’t expect it to be there.

My point is that I doubt a usability test would have found the need for this feature. If I were a test subject with a task to buy a song, I would not have thought to tell a usability tester that it would be great to have a feature to complete an album, just in case I change my mind in the future. I didn’t even think about it as a feature until I actually needed it. But somebody thought about it for me, and thought about how I could use it. And yes, with that feature in place, it can be tested and can be validated.

What little features have you noticed or even created that have really made a big difference? Leave me your comments…

The Digital Experience Group of the New York Public Libraries (NYPL) decided to try a bold experiment. Knowing that they wanted as much user feedback as possible and that they had willing participants—namely their web users, the Group created a trouble free survey tool to gather data. You may be saying, “Ohhhh, online surveys! What’s so bold about that?”. As usual, it’s the chosen implementation that helps to make the difference.

The Digital Experience Group created Infomaki, a system that provides a simple, one question survey asking a subject something as easy as “What would you click on to find events?”. After the subject answers that question, they are thanked, and simply asked if they would like to answer another question. Here’s what is so great about this approach: it’s very mindful of the subject’s time and very non-intrusive. The concept is that this will lead to more people willingly being repeat subjects. Also, more random questions will be answered. With a traditional survey, you may tend to get the same questions answered at the start of a survey, but have people drop out, thus not getting sufficient answers to the end questions.

There are a few bugs in the system, but it appears the team is actively working on fixing them. I gave it a try, and quickly got hooked. While obviously, my subjective opinion and observations do not constitute a usability test, I have observed most test subjects glad to answer a single question. But conversely, I have seen that grimace or shoulder slump when a subject can sense you are settling in for a multi-part questionnaire. My experience would point to Infomaki being a well received data collection methodology.

But don’t take my word for it, look at the results of the 48 hour pilot:

[a prior] survey received 7,341 individual answers to questions from 520 respondents, 60% of whom completed the whole survey. This totaled 7,341 individual answers over 14 days. Infomaki, on the other hand, garnered over 6,900 answers from 840 respondents in its initial 48-hour maiden voyage.

Seems like the concept works, but the real measure of success will be the continued interest of the subjects and the quality of data. Let’s hope we here more about how Infomaki works out.