Putting Context Into Context

By Jared M. Spool

Originally published: Jan 04, 2005

When purchasing a computer from Dell.com, you have the option to configure the machine and get exactly the options you want. Once you've reached a configuration you're satisfied with, you can save it, print it out, fax it to someone, or e-mail it.

When the designers at Dell added this functionality, they knew something other online computer retailers didn't know. They knew that computers were high ticket purchases and that people, when buying one, often need to seek the approval of a high authority (such as their boss or spouse). The design needed to provide an easy way for someone to stop the purchase process and go off to get that approval.

How did the designers at Dell realize this important requirement while virtually every other vendor missed it? They understood something the other vendors didn't. They understood the “context” of buying a computer.

The User, The Tool, and Their Context

Three underlying elements contribute to whether a user will succeed with a design:

  1. The attributes specific to the user - if you substituted a different user, you would get different results.
  2. The attributes specific to the interface - if you substituted a different interface, you'd also get different results.
  3. The attributes specific to the current context - attributes independent of the specific user and tool.

Often when we see usability problems in designs, it's because the design team didn't know something about the context that they should have. Teams with a strong awareness of the different contexts that will crop up are more likely to produce designs that will consistently delight users.

Imagine two different contexts for the same user and interface—Janice has to produce a presentation with a PowerPoint-like tool:

Context #1: Janice is creating a complex business chart in a presentation for the board of directors. The presentation is six weeks from now. She has never used the tool before.

She'll need to ensure the chart communicates the content very effectively. She'll spend time exploring the graphic editing options of the tool, making sure she has come up with just the right layout and formatting. Because she has six weeks until the presentation, she'll pay close attention to particular details, such as fonts, colors, and spacing, so she makes the best impression possible.

Context #2: Janice is creating a complex business chart in a presentation for the board of directors. The presentation is in 45 minutes. She's never used the tool before.

Janice will need to ensure the chart communicates the context as effectively as possible. She's going to rely on pre-made templates because she doesn't have time to come up with her layout. However, she needs to choose a template that will suit her needs quickly. She'll need to spend the bulk of her time making sure she got the data for the business chart accurate, so the layout needs to take care of itself.

In both of these contexts, Janice is exactly the same person. The tool is exactly the same tool. It's the context that will change the results of what Janice produces with the tool.

Buying a Mortgage

One of our clients, a regional bank, is responsible for building a web-based application to give homeowners a mortgage quote. They were recently preparing for a field visit to a potential mortgage customer, Margaret. What are the things that the design team should want to know about Margaret's context when using this application?

The list of questions the team put together was much longer than this, but you get the idea. Every question looked at a piece of Margaret's context. Every answer could have an impact on the design the team put together.

Breaking Down Context

Context is made up of a variety of elements. Over the years, we've come up with a basic way to organize these elements so we can think about them more easily:

  1. Goals: What is the user trying to accomplish? How do the user's actions fit into the objectives of the organization?
  2. Process: What are the steps the user will follow? How does information flow from one step to the next? What are the various roles (such as creator, contributor, editor, or approver) that are involved?
  3. Inputs & Outputs: What materials and information will the user need to successfully use the interface? What will they need from the interface to continue with their overarching goals?
  4. Experience: What similar things has the user done in their past? How has the organization survived without this design in the past?
  5. Constraints: What physical, temporal, or financial constraints are likely to impose themselves on the user's work?
  6. Physical Environment: How much room does the user have to work? What materials on their desk? What access do they have to necessary information (such as user manuals)? What is taped to their monitor?
  7. Tools In use: What hardware and software does the user currently use?
  8. Relationships: What are the interconnections between the primary user and other people who are affected by the tool?

By breaking down context into these different components, it helps us organize our questions and ensure we've covered all the important issues. However, we've found that every project has a slightly different breakdown.

Often, after we've done a couple of site visits, we'll take the information we've collected from the sites and perform the KJ-Method to categorize the results. This often shows us a better way to think about the various contextual elements, specific to the challenges the users are facing. 

Playing the Guessing Game

Before we go out on field study, we like to play a little game. We take each of the above categories and put it in the form of a couple of questions, much like the questions about Margaret, our home buyer. For example, we'll take “Inputs” and list it as “What personal information does the user need to apply for the mortgage?” and “Will the user have all the information at their fingertips when they start the application process?”

Then, right before our first field visit, we'll take what we know about the person we're visiting and guess at the answers to the questions. Even though these are just guesses, we make an honest attempt to think through each answer, often discussing them amongst ourselves. This process creates a painting in our heads, as it were, of who this user is and what we expect their context to be.

When we visit the user's site, any differences we see between the user's real environment and the painting in our head jumps right out at us. It becomes easy to collect the data we need during the visit.

Why not just brainstorm all the possible contextual elements, skip the visits altogether, and ensure your design meets every possible need? Because, unless you're extremely lucky, your team won't have the resources to build a design that can accommodate every possible combination of contextual elements.

By observing how your potential users interact in their environment, you'll have a good sense as to which contextual elements are most common and which ones can have the biggest impact on the usability of the design. Plus, you may actually see something that you never imagined could happen. (This happens far more often than we like to acknowledge.)

Accounting for Context

Design happens at the intersection of the user, the interface, and their context. It's essential for interface designers to understand the gamut of contexts that can occur, thereby ensuring they create designs that are usable no matter what's happening around the user.

 Share this article with a friend/colleague.

Subscribe to UIEtips, our free email newsletter


  • Read our research the moment we publish it
  • Learn about special events and happenings
  • Receive subscriber-only deals and incentives