— 2 September 2003 —

Contextual Inquiry

There’s nothing like visiting the people who will be using the application you are designing to make you remember that there are real people out there who need actual help.

I don’t always get to do contextual inquiries (aka: site visits, user visits, et al.). There are many reasons I don’t get to go, and none of them are ever good reasons. But I recently got to go visit representatives of three of the eight user groups that will be impacted by the the new system. Right away we realized that it was a good idea to go because we identified a ninth user group that the business analyst (BA) did not know about.

And that’s one of the reasons that gets thrown around a lot, and why I don’t get to go: The BA used to do that job, so she knows what they need. Read this also as the BA represents the user. Um, no the BA should represent the business need. They should know what the user does currently, but I find more and more that the BA was “in the field” 6 years ago. Heard about that Web thing? Yep, it changed the way users completed their daily tasks, and you don’t have experience with that now do you? Small rant, sorry. My main point is that you cannot do an adequate job of designing without meeting the people for whom you design. It’s not impossible of course, we all have to do it at times.

The CI (got tired of typing it) I went on recently, was a high-interaction one. There are, of course, many levels in interaction depending on what you are looking for. For me, this time I was looking to get information on the current tasks performed by each user group I visited. This information will feed into my Current Task Analysis deliverable, which then becomes the basis for the Future Task Analysis deliverable.

As such, I sat with each person at their desk. I started off with telling them why I was there, and what I would be looking for. This is very important because, while it may bias their answers some, it allows them to understand the context in which I am observing (and in this case interacting) them. Using this high-level of interaction I am able to ask questions at any point, stop them in their task to clarify something, or even back them up a few steps. They still do actual work that is representative of what they usually do, but I get a very good, step-by-step account of the activities. And it allows me to write things down before they move on to the next step. I highly recommend bringing a scribe to copy down everything, but that isn’t always (usually ever:) possible.

It is important to note that the users often do their tasks differently than how the business prescribes them to do it (yeah, I know, duh!). They are sometimes more efficient, and sometimes not. But by observing you get a complete picture that would only be partly true if you took solely the word of the BA.

Another idea that I find helpful is to get screen shots from each user. This tells me how they organize their windows and in what order they do things (take screen shots at each stage on the process). A video camera might be better for this, but I find it is harder to get permission to do this, so I stick to screen shots. I also take copies of all the “job aids” on their desk. The ones specific to the completion of related tasks. These often include memos, sticky notes on the monitor (yes I see a lot of passwords on these!), user-made “manuals” and anything else they use to help them complete the tasks. Often this information can be embedded into the new application.

Overall, this process of observation is enlightening. This most recent visit we found that there really aren’t any problems with the application we are trying to “fix.” The big problems lie with the other two applications the users have to use each day, and the lack of integration between them. This lack of integration causes some double entry of data. But fixing that actual problem is “out of scope.” The only issues with the current application we are charged with fixing are purely presentation level. Line up some field captions, perhaps a renaming of one field. There are no big usability problems with the existing application.

So, thanks to my contextual inquiry, and seeing the application and users in action, it is going to be my recommendation to scrap the project. There is no point in continuing unless we radically change scope, and that isn’t going to happen. They probably won’t scrap the project either, but we’ll see. The point is, without a CI, I would have to take the work of the BAs and trust that the project was initiated for a real reason.

For more on Contextual Inquiry, and other concepts and practices related to the realm of user and task analysis, I highly recommend: User and Task Analysis by Hackos & Reddish.

One Response to Contextual Inquiry