Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Putting Context Into Context

by Jared M. Spool
on January 4, 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?

  • Where is Margaret in the process of applying for mortgages? Is she just
    starting out or has she already applied for several? Is she already a customer
    of the bank? What does she know about the bank? What does she need to know
    to make a decision?
  • Is this first time she’s purchased a house? Does she understand how mortgages
    work? Is she clear on the differences between the different options?
  • Has she chosen the house she wants to buy? If not, does she know the price
    range of what she can afford?
  • Why is she getting a quote? Does she want to know if she can afford her
    dream house? Does she want to compare rates with other lending institutions?
  • After she gets the quote, what will she do with the information? Is she
    likely to apply for the mortgage right away? Does she need to speak with
    others first? Who else will she talk to? Her husband? Her parents? Her realtor?
    What information will she need to tell them?
  • What other online applications does she use regularly? Is she familiar
    with spreadsheets? E-mail? Word processors?
  • Does Margaret do her banking online? Does she use online bill payment?

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.

About the Author

Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems. You can follow Jared on Twitter at @jmspool.