kubitsky.net

I just read a really great article from Jared Spool’s latest newsletter. He talks about how interview-based tasks in usability tests are a great way for identifying problem areas with our internet-based products as well as providing more insight into the way our users approach and use these products.

One of the problems with traditional task-based usability tests are that they can yield misguided results simply because the tasks are not directly related to what real users wish to do. Using these traditional tasks certainly will help the usability team understand how their product works, but not really how people use it, which can make all the difference when it comes to offering a useful and profitable internet-based product.

Jared says that “passion on a subject changes how participants invest in usability test tasks.” If the user is interested in the subject matter that the task is based in, they will take a completely different approach to executing the tasks and determining when they are complete. Users that are interested in the subject will demand more from the product in order to get the desired result than someone who is not interested.

As usability test facilitators, it is our challenge to identify and control the passion in a test. Interviewing chosen test participants at the start of the session can help identify areas of “passion” by which to base tasks. Using light role-playing with easily imaginable situations can help structure the tasks. At this point, the facilitator now has a set of agreeable tasks created in conjunction with the participant. As a result, no two participants will have the same set of tasks.

Jared goes on to say that even though each participant’s tasks will be different, patterns will begin to emerge with their approaches. Facilitators will still begin to see the common problems and the experience that users have with the product.

Using interview-based tasks in usability tests not only improves provides more representative results, it also allows the facilitator to learn more about the users, their interests, and how they think of content. All of this information helps us to make better decisions and recommendations for improving our products.

This was a fantastic article that I truly encourage all of you interested in internet product design to read it on the UIE site. It opens to the door to another tool UX professionals can use to help make their products better. Unfortunately I have not yet had the opportunity to participate in the facilitation or witness of a usability test in my young IA career, but I hope to soon and will continue to push for the need to do so.

I used to think that wireframes were a great way to communicate abstract design decisions to the rest of the project team. Needless to say, I no longer feel this way. As a matter of fact, I think they are one of the worst ways to communicate these decisions. But, wireframes are not all bad. Each person should use the tool that works best for them and their environment.

Here are some of my frustrations…

Wireframes take a really long time to create and there really is NO good application out there for them. For interactive internat applications, which I mostly work on, it’s even more difficult. How do you document easily and concisely in a 2D space how to interact with an object in virtual 3D?

Most folks don’t want to read–EVER. IAs take a really long time creating accurate wireframes, annotating all the components, reviewing, tweaking, versioning, etc, only to have the stacks sit on someone’s desk gathering dust until there’s a meeting where the IA will essentially explain everything in person anyway. It’s not a negative comment on the folks who receive the wireframes, just an observation that IAs just might be wasting their time on these documents.

There must be a better way to communicate IA and UX decisions, but I believe that can only happen if the process by which these products are developed also changes.

But, wireframes have been helpful to me in brainstorming (minus the massive annotations) and in analyzind and identifying details of an interface that I may have missed. It’s a great exercise for me to catch issues ahead of time that I might not be able to find otherwise. Then again, isn’t that just a form of paper prototyping?

I really like that Google is offering a customized home page now, but they really need some major work on how they “display” information in their channels/modules.