The User Interaction Cycle

Download
A downloadable version of this paper is available in MS Word format, and will open in a new window.
Abstract

This paper proposes a framework for placing and organizing the various methods, tools and research that have been developed for User Centered Design (UCD). The framework is developed by examining users' behavior while interacting with software. I show how this framework, called the User Interaction Cycle, works with and supports the body of research that has already been developed in the UCD community, and how it has implications for further adding to the ideas of accessibility and designing for expert and na´ve users. I also show how the framework can be used as a guide or starting point for answering the question, "How?" How can we create a universal design methodology to help describe and guide the creative process of inventing a usable design that can be applied equally well to any piece of software. The purpose of this paper is to initiate a conversation around that question.

Introduction

One thing is certain: there are a lot of different tools and techniques available to help us when we try to address usability issues within software design. We've got GOMS models from Card, Moran, and Newell and Miller's Magic Number 7; we know about Norman's Gulf of Execution; we know about Fitts' law, affordances and heuristic evaluation and we can perform time motion studies; we know about readable fonts and color theory; and we know how to test software to see how usable it is. All of this research and these tools and techniques, and many more, should be applied in user centered design. But how, when and according to what pattern? We know lots of things about usability, but do we know how to do user-centered design - the part in between identifying target users and saying, "The design's done." Do we know how and when to apply the research as we create designs? When do we do GOMS modeling? When do we look at the Gulf of Execution? How does all the research fit together? Is there a universal design methodology - a general enough way to think about creating a usable design so it can be applied to any project? How?

Designing for Usability

The Usability Professionals' Association (UPA) begins to answer the question "what is usability"1 by referring to two ISO standards that can be applied to any project:

"[Usability refers to] the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of user." - ISO 9241-11

"Human centered design is characterized by: the active involvement of users and a clear understanding of user and task requirements; an appropriate allocation of function between users and technology; the iteration of design solutions; multi-disciplinary design." - ISO 13407

The first standard provides guidelines on how to test to see if a project is usable, and provides advice on how to measure its usability. The second describes the overall sense of user centered design and characterizes the types of questions to keep in mind when designing.

Both the UPA and UsabilityNet further use ISO 13407 as a guide2 for suggesting that we use a cycle of four iterative activities in the process of user-centered design:

  1. understand and specify the context of use
  2. specify the user and organizational requirements
  3. produce design solutions
  4. evaluate designs against requirements

Activities one, two and four are fairly straightforward - but activity 3 is not.

UsabilityNet talks about a standard (ISO TR 18529) and the seven base practices3 that have "...to be done in order to represent and include the users..." during design. These practices are:

  1. Ensure Human-Centered Design (HCD) content in system strategy
  2. Plan and manage the HCD process
  3. Specify the stakeholder and organizational requirements
  4. Understand and specify the context of use
  5. Produce design solutions
  6. Evaluate designs against requirements
  7. Introduce and operate the system

Practice five also says we should produce design solutions. But how? The standard further breaks practice five down into the following eight steps:

  1. Allocate functions
  2. Produce composite task model
  3. Explore system design
  4. Use existing knowledge to develop design solutions
  5. Specify system and use
  6. Develop prototypes
  7. Develop user training
  8. Develop user support

Practice 5 simply got deferred into practice 5.4 which says we should use our existing knowledge to "develop design solutions". The question again is, "How?" How does one produce usable design solutions? How does one move usability design from the realm of black art to that of a describable, repeatable process?

These questions are vitally important for a few reasons. First, an understanding would help us better educate new students in the practice of UCD. Second it will help veteran usability designers not to overlook any aspects of usability. Third, an understanding would help us organize and unify the wealth of tools, techniques and research that have been developed for UCD. And finally, the framework might even point out some holes in the current research or some other interesting areas of work.

The question is obviously huge, and I'm neither claiming that I can solve the entire problem nor that what I have developed is complete. But in this paper I make a start at answering the question.

What is "Any Project?"

In order to describe how to design usability into any project, we should define what "any project" means to help put bounds around the problem.

I'm going to start defining "any project" by focusing only on the interactions between humans and computer software, and not between humans and physical devices. Though this is limiting, if we can succeed in describing how to design any human computer interface, we might be able to use that knowledge to help look at the question of physical interfaces as well.

The next question is, what commonalities are there among all human computer interactions? At their most basic level, all computer programs revolve around input and output. A computer program gathers some input, does some black-box stuff, and then generates some output. Where does the input come from? For our purposes, let's say the input comes from a user's interactions - implying that we are now further constraining our definition of "any project" to include only user-controlled software and not software such as real-time monitoring and display software.

For our purposes, we can characterize "any project" by observing that all software use follows the same high-level process: users generate input and computers generate output. Can we refine this process any further? The mindset of user centered design, as described by the ISO standards, is one of helping users accomplish their goals. The user comes to the software with a goal in mind. She provides some input and the computer does its thing, whereupon the user verifies whether or not the original goal was complete. Then, based on an assessment of whether or how well her goal was accomplished, the user will pick another goal and start the cycle over again. Our user will continue iterating through this cycle until her primary goal is met.

I refer to this cycle as the User Interaction Cycle. At the highest level, the primary tasks in the User Interaction Cycle are:

  1. User thinks of what to do
  2. User does it
  3. User checks to see if it worked

If we say that this description of a user's behavior, the User Interaction Cycle, is common for all users across all software, and further, if we believe that all tasks must be easy for users to do, it therefore makes sense to say that in order to have fully usable software, we must design each task in the User Interaction Cycle for usability.

The User Interaction Cycle

These three tasks describe the sequence that any user goes through when using software to accomplish a goal. A complete interaction is made up of countless iterations through this cycle. The first task in the cycle is characterized by modeling the user work process. In the second task, the user engages the interface to provide input. In the third task, the user looks for feedback. Then we go back to the beginning.

We can already start to see some of the tools, techniques and research of user centered design at play. Task 1, for instance, relates to the work process - the user thinks about what she wants to do and creates a goal. This sounds like a perfect place to apply GOMS modeling.

There's also a pretty close correlation between task three, relating to verification, and the Gulf of Execution - the difference between what is expected and what really happens. In fact, it is the Gulf of Execution at the end of one iteration of the User Interaction Cycle that drives the goals for the next iteration.

Let's look more closely at each task in the cycle.

Task 1: Work Model

The first task in the cycle has to do with the work model - the user figuring out what he wants to do next. The user comes to a computer with a high level sense of what he wants to do and with personal experience with a work flow process of how to accomplish his goal - a GOMS sequence, if you will.

Any software product also has its own required work flow implicit in its design, which can be thought of as a finite state machine. Each interaction with the software changes the current state based on the work flow encoded within that finite state machine.

The problem is that the user's work sequence may or may not match the software's work sequence. This observation points out an implicit task that users must do. They must correlate and translate between the two work models - just as a native English speaker spends effort trying to convey a concept in French. As the user ponders what his next step would be in his own work model, he must also figure out what steps he must take in the software work model to approximate his goal. As the English speaker figures out what to say in English, he must figure out the French that would approximate his meaning. Thus the user must mentally juggle two work models: his own and the software's, and must translate between them.

As a user becomes more familiar with a particular piece of software, he may internalize parts of the software work model, and be able to approach the software with a personal work model much closer to the software's - effectively requiring less effort for translation, just as the English speaker above will internalize French over a period of time. It therefore makes sense that the closer the software's work model is to the user's in the first place, the better.

The user plans a set of interactions with a goal in mind. She expects that once the interaction is complete, the state of the software work model will match her translated goal, and the state of her personal work model will match her actual goal. In order to verify this later, the user takes note of the expected outcomes in both work models of the anticipated interaction.

Based on these observations, task 1 of the cycle can be broken down into the following three parts:

  • Determine the next step for the physical work model
  • Translate into the next step(s) for the software work model
  • Set expectations as to what should happen

In other words, the user first figures out what he wants to do and then figures out how the software wants him to do it - and he knows what should happen as a result.

As an example, think of a home banking web site. The user might come to the site with a goal of paying the electric bill. Her personal work model might involve getting the bill, writing the amount on a check, putting the check in the envelope and mailing it. On the web site, the work flow might be: log in, go to payment section, browse list to find payee, enter amount, choose date for payment, confirm. The work flows are different - the way that the user must think about the chore is different. The first is developed through personal experience, the latter is dictated by the software publisher - and the user must be able to translate back and forth.

Phase 2: User Activity

After task 1, the user should know abstractly what the next step to do is within the software's work model. The next step is for the user to figure out exactly where to click the mouse, or specifically which keys to press. To do this, the user must explore the interface to find the appropriate button, menu or other widget to interact with, and then interact with it.

While the next step in the software work model may be an abstract concept, all elements of a user interface are marked with specific text, shapes, colors, and images. Our user now has another translation to do: from the abstract concept into the tangible and specific interface element. I refer to this translation as a cognitive mapping. As with Task 1, the more experience a user has with a particular package, the easier the cognitive mapping will become, until, hopefully, the effort involved is trivial.

Now that our user has chosen a specific interface element to interact with, she starts planning for the interaction. Assuming she is not using voice command, she will first eyeball the element, which is a target acquisition exercise. She may, for instance, find where the mouse is currently and her desired target point, while calculating the direction and speed of her upcoming interaction. Voice control users will not necessarily need to do target acquisition.

Finally our user is ready to make the physical muscle movements necessary to effect the interaction she desires. She moves her wrist, elbow and forearm in such a way that the mouse winds up in the proper place, and then pushes the button to indicate her choice.

Thus, the parts of task 2 can be described as:

  • Cognitive mapping
  • Target acquisition
  • Physical actions, or mechanics
Phase 3: User Validation

Once the user has performed his action - pushed his button, chosen his menu item or entered his text - he now looks at the screen to find out what actually happened, and if what happened matches the expectations that were set in task 1.

The first job is to isolate and identify what the feedback from the interaction was by scanning the screen or listening for sounds. The more subtle the feedback, obviously the more difficult it will be to isolate.

Once the user has the feedback, she must then process it to determine what it means for both the software work flow and her personal work flow. Just like the native English speaker mentioned earlier on must process the French response she gets both to figure out if the other person understood her comment and to understand what the comment means in her native English, so too must the user translate the new state of the software work model back into the personal work model.

Once our user has determined the new state of the software work model, and translated the feedback back into her personal work model, she must compare both to her original expectations. If the results in the software work model don't match, just like if the French person didn't understand the question, our user probably didn't do the original translation from personal work model to software work model in task 1 properly. Conversely, if the state of the personal work model doesn't match the original expectation, then our user's work model may be off.

The parts of task 3 can be summarized as:

  • Isolate and identify feedback
  • Process or interpret feedback
  • Compare feedback to original expectations
The User Interaction Cycle as a Framework

What we now have is a set of three high level tasks each broken into three discrete parts, that together form the User Interaction Cycle. Users go through the cycle - this same set of abstract steps - over and over again to achieve a specific goal. In order for the software as a whole to be easy to use, each of the constituent parts must also be easy. Therefore, each part of each task must be well designed.

What the cycle provides is a framework, or structure, within which to place individual techniques, tools and research. If we go back and look at the earlier list, we see that each of these can generally be associated with one part of the cycle.

The following chart presents the parts of the User Interaction Cycle along with a simple question users might associate with each part, and some of the tools, techniques and research that is appropriate to each part:

   User task User Says Design Tools
Phase I: Work Model
  Physical Work Model:
  User's mental model of work flow based on familiar model in the physical world. What do I want to do now? Work Design
Time Motion Studies
Expert Interviews
Knowledge Engineering
Work Flow Maps
  Software Work Model:
  User's translation from personal model to that presented in software How do I have to think about my next step? Na´ve User Interviews
User role play
Heuristic evaluation
  Expectation Forming:
  User builds expectation of what should happen What should happen if I do this? User interviews
High-level paper Mockups
Phase II: User Activity
  Cognitive Mapping:
  User determines specifically what interaction to initiate. How do I do it here? Blocking, chunking, grouping
Creating activity structures
Millers Magic Number 7+/-2
  Target Acquisition:
  User identifies where all germane items are in the user interface. Where is it? Visual structure
Visual Language
Semantics of structure
Graphic Design
  Mechanics:
  Physical interaction Here I go... Fits's Laws
Kinesthetic memory
Typing
Phase III: User Check
  Verification:
  User examines result to see if it was the expected result Did it work? Feedback mechanisms
Breadcrumbs
Conclusion

When thinking about our target audiences, we often refer to expert users and na´ve users. But the first steps of the User Interaction Cycle beg another question: Is the user expert or na´ve at what? One user may be very knowledgeable about the physical work model (a traditional video editor using Avid, for instance), but completely new to software. Another might be a complete novice at the physical model but quite facile with software work models - (the non-accountant computer scientist using TurboTax, for instance).

Users may be more or less facile with each part of the User Interaction Cycle, though, not just the first two. Facility with some parts of the cycle, such as work models, may be increased by training. The more times someone goes through a set of menus, the easier it is to remember where they are. Facility with the mechanics involved in an interaction will get better as the user builds kinesthetic memory.

However, facility with some parts of the cycle, such as mechanics or cognitive mapping, may be a function of a particular user's body, and may not be learnable. People without full use of their limbs, for instance, may not be able to improve their facility with mechanics as much as a fully able person might. Color blind and severely myopic people may not be able to become expert at isolating feedback or at other parts of the cycle that rely on visual language.

Thinking about interactivity in terms of the User Interaction Cycle, therefore, also gives us further insight into designing for accessibility. Each handicap a person might have actually impairs their ability to be expert at one or several parts of the cycle. This observation should enable a designer to further focus on the issues associated with accessibility.

Toward a Universal Design Methodology

In the beginning of this paper, I tried to illustrate a problem by pointing out that in the ISO standards, the process for developing usable software includes the phrase, "develop design solutions," and I asked the question, "How?" When I teach software engineering, I like to show students that they can make a problem more tractable by breaking it up into smaller problems. We can apply that technique to this situation as well.

As I said at the outset, creating a universal design methodology is a huge and daunting task. What I hope to have shown in this paper, is that we can break this big problem down into smaller problems, and I'm further proposing that we break the big problem down into the steps of the User Interaction Cycle, recast here from Table 1:

  1. Usable Software Interface Design
    1. Usable Work Model Design
      1. Understand physical work model
      2. Create usable software work model
      3. Understand and support expectation forming
    2. Design for User Activity
      1. Design for simple cognitive mapping
      2. Make target acquisition simple
      3. Make mechanics easy
    3. Design for the user validation
      1. Make identifying and isolating feedback simple
      2. Design output so it can be easily interpreted
      3. Design outcomes of work model to match expectations
Conclusion

I noted earlier that we could "assign" the individual tools, techniques and research that have been developed in the UCD community to each part of the User Interaction Cycle. This isn't completely accurate terminology. Actually, each tool , technique, or piece of research is a solution, partial or complete, for one of the parts of the User Interaction Cycle.

As I said in the introduction, I am not attempting to solve the incredibly broad question of "How?" Rather, I'm trying to provide a framework within which to think about solving that question. I've shown how the User Interaction Cycle supports existing research, and how it can support and refine how we think about issues such as accessibility or facility with interface. I would like to encourage others to join in this conversation so that we can give UCD students a bit of an answer to the question, "How."

Notes:

phone: 617-697-7527 — e-mail: ben@dubrovsky.name — ©2007, 2008, 2009 Ben Dubrovsky