The Importance of Context

Lately I have been obsessed with jigsaw puzzles…. the digital kind mostly.  It offers a sense of accomplishment. Plus, every Friday a “mystery puzzle” is posted which adds another layer of accomplishment to your day!  They give you a hint, a fragment of the image to reference.  It might be something like this:

You start envisioning what the rest of the image might be: maybe it’s a construction worker’s shadow..?  Only when you put all the pieces together do you quite literally see the bigger picture and get perspective on the thumbnail image you were first exposed to.   A story begins to coalesce.

Sometimes in usability testing, we are not evaluating an entire product, or system but rather a component or subset of the whole.

Recently, I tested a product that was rather complex: it had several different components, applications, user groups, and accessories.  When one of the accessories didn’t hold up against the established acceptance criteria, the client reworked the part and we took it back out for testing.  The failure occurred during assembly of the product which must be done before it is used.  Not only did a component break during assembly, but there were no indications to the user that something was wrong preventing them from taking measures to fix it.

“It might be tempting to test only one part of the whole”

This failure occurred during one very specific step during assembly.  To use an analogy, let’s say the task is pulling your car out of a driveway.  First you open the car door, get seated, put on your seatbelt, depress the brake, put the keys in the ignition, turn the keys to start the car, put the car in gear, take your foot off the brake, move your foot to the gas pedal, and, finally, depress the gas pedal the required amount.  In this analogy, the problem would occur when the key was turned in the ignition.  It might be tempting to test only one part of the whole: have user seat themselves in a car and evaluate the key-turning step.  The concern here is that the sub-task is removed from the larger task of pulling a car out of a driveway.  To put a user in this artificial scenario, especially when they know they are being observed or “watched”, adds to their anxiety, and can adversely affect the results.

While we stress to our participants that we are there to test the product, not them, some still get a bit nervous.  Including the whole task allows the user to get into a flow and not be so self-conscious about their performance on any particular interaction.

“The memory of one interaction influenced a subsequent action.”

In our assembly task, I advocated for the specific step of concern to be nested into the larger assembly process to keep it more natural for the users.  While including the extra steps required more equipment, and a little more time, it was worth it.  In doing so, something else arose that was not initially anticipated, as yet another reason to extend the test beyond the area of immediate focus.  What we came to learn is that two steps before the step in question, the users were required to exert a certain amount of force; a force greater than one might expect.  This interaction carried over to the step in question.  Some users were exerting a similar force which contributed to the part breaking.  The memory of one interaction influenced a subsequent action.  Had the step in question been isolated, the carry-over effect would not have happened, and we would have missed a behavior that would happen in the real world.  Instead of focusing on a word, we zoomed out and read the sentence.

“context can paint a more comprehensive picture.”

Keeping a task in context not only helps put the user at ease but it can paint a more comprehensive picture for the Human Factors / Usability Practitioner.  After all, the question we strive to answer is not only what is really happening when people interact with your product or system but describing what those behaviors mean for the design and why.