Contextual Inquiry - Additional Guidelines

From CS 160 Fall 2008

Contextual Inquiry

We will grade this based on the quality of your method in finding representative users and and how much you discover about any issues you might be able to resolve with an interactive system. For example, if you were designing a drag and drop scheduling application:

• Bad: You do a contextual inquiry with your dorm mates and they complain about how slow Telebears is and that navigation is difficult. The problem here is that you are not getting a good enough selection.
• Better: You do a contextual inquiry with a selection of undergrads from different years and majors (and they don't all live in your dorm)
• Great: You do a contextual inquiry with graduates, staff, and undergraduates. You discover that graduates only take two classes. Staff members don't take classes but only schedule meetings, which do not always meet at the same time every week. Undergraduates have too many classes, so drag and drop might clutter the interface.

Analysis of Tasks

You should choose good representative tasks that span a variety of different scenarios, instead of just being variations on a theme. Your project should not be trying to solve a problem that is too simple or too complicated. Suppose you are doing an auction website ala (ebay):

• Bad: Your tasks all revolve around making the checkout better. For example, an easy task is to checkout with one item, a medium task is to checkout with three items, and a hard task is to checkout with a different credit card then you normally use.
• Better: Your easy task is to find an item you are interested in purchasing. Your medium task is to place a bid on an item. Your difficult task is to set up a watchlist for a group of items you are interested in.

Interface Design

This is the first real glimpse we've seen of your interface, so we care about the amount of thought you've put into coming up with an interface paradigm which can realistically evolve into a useful final product. Of course, we also want to see a good spread of activities in the tasks that you choose. Back to the ebay example:

• Bad: Your storyboards involve a user logging into the auction site and choosing between two options: "change my password" and "search." Obviously, your final product will house a lot more complexity than just two options at the outset, so it would be wise to spend some more time thinking through the navigation.
• Also Bad: Two of your tasks involve changing your user password, and the third with setting other preferences. This is bad because not only are two of your tasks exploring one part of your interface, all three are presumably relatively unimportant to the larger idea of what your project will do.
• Better: One of the storyboards exhibits your auction site, after login, giving the user a well thought-out set of options about what to do next. The user clicks on one, and proceeds to perform some meaningful activity that you've designed, with the storyboard disclosing the decisions the user makes at each step. Here we have been given a good idea of how the larger framing of the interface will work, and seen the complexity involved with the task.