Sub-roles

For some work roles, there are obvious sub-roles distinguished by different subsets of the tasks the work role does. See the MUTTS example after the next section.

Mediated work roles

For many systems, your contextual data will show you that there are “users” in roles that do not use the system, at least not directly, but still play a major part in the usage context. These mediated users, whom Cooper (2004) calls “served users,” have true work roles in the enterprise and are true stakeholders in the system requirements and design and definitely play roles in contextual analysis, scenarios, user class definitions, and even personas.

The ticket-buyer role for MUTTS is a prime example of a user role whose interaction with the computer system is mediated; that is, someone else acts as an agent (the ticket seller) or intermediary between this kind of user and the computer system. It turns out, of course, that ticket buyers will become direct user roles in the envisioned Ticket Kiosk System. The ticket buyer is still a very important role and indirect user of MUTTS and is, therefore, important to interview in contextual inquiry.

The ticket buyer will be the main role considered in subsequent examples. These mediated roles are often customers and clients of the enterprise on whose behalf direct users such as clerks and agents conduct transactions with the computer system. They might be point-of-sale customers or clients needing services from a retail outlet, a government agency, a bank, or an insurance agency. They have needs that reflect on user tasks directly and that are mapped into the interaction design. The working relationship between the mediated users and the agent is critical.

Envisioned work roles

The basic work itself, what has to be done, usually does not change much from the old system to the new system. For example, for MUTTS, even with the introduction of kiosks, the goals of most work roles are still the same. Much of the change from old to new shows up in envisioned work roles and an envisioned flow model. For example, the responsibilities and tasks of some roles may change.

As we move from the existing system and existing work practice to the design of the new work process, work roles can be expanded and changed. Some old work roles are no longer necessary; for example, the ticket seller may no longer exist as a role. Some new roles are introduced and we now spotlight some roles that were previously only in the murky background. Along with new roles, we get new issues and concerns in the envisioned social model, new work activities and constraints. The new roles come alive in the new workflow of the envisioned flow model.

Because you might have some new roles in the new design, you may not have contextual data from them. If you have not already interviewed people who might serve in these roles, now is the time to do just a little bit more contextual inquiry to see if there are any new considerations for design arising from the new roles.

Relationship of work roles to other concepts

Work roles are distinguished by the kinds of work they use the system to accomplish. For example, the MUTTS ticket seller who helps customers buy tickets does entirely different tasks with the system than, say, the event manager who, behind the scenes, enters entertainment event information into the system so that tickets can be offered, printed, and purchased.

In Figure 6-2, we show the relationship of work roles to other key concepts. Work roles are central to flow models.

Knowledge- and skills-based characteristics

User class definitions can include background, experience, training, education, and/or skills expected in a user performing a work role. For example, a given class of users must be trained in X and must have Y years experience in Z.

User class characteristics can include user knowledge of computers—both in general and with respect to specific systems. Some knowledge- and skills-based characteristics of user class definitions can be mandated by organizational policies or even legal requirements, especially for work roles that affect the public.

For example, organizational policy might require a specific kind of training for anyone to take on a given role or no one is allowed to take on the role of an air traffic controller until they have met rather strict requirements for levels of experience and background training mandated by federal law.

In Figure 6-3 we show relationships among work roles, sub-roles, and user class characteristics.

User class characteristics can include user knowledge of the work domain—knowledge of and experience with the operations, procedures, and semantics of the various aspects of the application area the system being designed is trying to address.

For example, a medical doctor might be an expert in domain knowledge for an MRI system, but may have novice-to-intermittent knowledge in the area of related computer applications. In contrast, a secretary in the hospital may be a novice in the domain of MRI but may have more complete knowledge regarding the use of related computer applications.

Physiological characteristics

Physiological factors include impairments and limitations. Age can imply physiological factors in user class characteristics. If older adults are expected to take on a given work role, they may have known characteristics to be accommodated in design. Beyond the popular but often inaccurate characterization of having cognitive rigor mortis, older adults can be susceptible to sensory and motor limitations that come naturally with age.

The older adult population in our country is growing rapidly, mainly due to aging baby boomers. A study of potential usability barriers for older adults in 50 state and 50 federal e-government Websites (Becker, 2005) revealed a huge amount of easily correctable flaws in the form of distractions, poor use of color, nonstandard use of links, nonstandard search boxes and mechanisms, requirements for precise motor movements with the mouse, font size, and Web page lengths. Also, electronic voting machines, although not online, are certainly part of the concept of e-government.

Physiological characteristics are certainly one place where accessibility issues can be found. Within usage roles you may also find subclasses of users based on special characteristics such as special needs and disabilities, such as the woman voter mentioned in Chapter 3.

Experience-based characteristics

Experience-based characteristics can also contribute to user class or subclass definitions. Also, you should remember that experienced users for some systems are novices for others. Considerations include:

Identify active entities and represent as nodes

In the social model, different entities—especially work roles— with concerns or influences within the work practice are represented as nodes. The active entities can also include any non-individual agent or force that participates in, influences, or is impacted by the work practice, internal to or external to the immediate work environment.

Examples of external roles that interact with work roles include outside vendors, customers, “the government,” “the market,” or “the competition.” Perhaps the project team depends on an external vendor to supply a certain part in order to build a design prototype. Or an external regulatory agency may have put a rule in effect that limits the way a product can be marketed.

Alternatively, the enterprise may be limited by union policy regarding the number of people who can take on a given work role. Some workers in a large government agency may feel bound up by government rules and policies, by federal and state legislation, and by working in a union shop. Finally, generic roles in the broader business process model, such as “management,” “the government,” “the market,” and “the competition,” can be roles in a social model.

Groups and subgroups of roles. Work roles and other roles can be grouped into generalized roles that represent common concerns or influences. Group roles can be very informal with respect to the official organization chart. For example, you can refer to “those people in shipping” or “management” as groups.

System-related roles. There can be a number of different kinds of nonhuman roles in a social model, including databases, systems, external signals, and devices.

Workplace ambiance. The workplace ambiance is another nonhuman social model entity, one that represents the prevailing organizational identity and organizational attitudes, and any pervasive organizational personality. Ambiance includes the milieu, the atmosphere of the workplace, and the general “air” or “way of life” in the workplace.

Ambiance is part of the social model rather than a working environment model because of the psychological impact on users. Sometimes the ambiance of a workplace reflects stress and pressure.

As an example, consider a typical doctor’s office. The general mood or work climate is rushed, chronically overbooked, and behind schedule. Emergencies and walk-ins add to the already high workload. The receptionist is under pressure to make appointments correctly, efficiently, and without errors. Everyone feels the constant background fear of mistakes and the potential of resulting lawsuits.

Work domain. The work domain itself can be an entity in a social model, possibly containing constraints and influences on the work practice. Examples include conventions and traditions in the work domain and legal and business policy constraints.

Create nodes to represent social model entities. Each node in a social model diagram represents an entity in the work practice of the enterprise. Start with sketching a node, as a circle for example, for each of the entities, of the kinds described in previous sections, in your broadly viewed existing working environment. Label each node with the name of the entity. Use circles within circles, in a Venn diagram approach, to represent groups and subgroups.

Identify concerns and perspectives and represent as attributes of nodes

Often managers treat concerns of their employees as “intangibles,” yet they can have a very tangible effect on how people work. Workers often have concerns about other workers, issues connected to their work roles, work goals, and how things get done in the work domain. The concerns show what people care about in the work place and how they think about their work, the tools they use, the people they work with, and the organization they work for.

They may (and are likely to) share overall work goals with other work roles, but each work role has a different perspective on the work and the workplace and on the other work roles. Groups and subgroups can have their own set of common concerns, just as any other entity. Many concerns are hidden and must be teased out in contextual inquiry.

For example, while the primary intents of people in work roles are to get the job done, people also have secondary intents driven by their own personal and possibly tacit agenda or concerns. Those concerns in turn motivate user behavior in doing the work and, if a system is used to do the work, in using the system.

For example, a manager might be concerned with capturing very complete documentation of each business transaction, whereas the person in the work role that has to compile the documentation may have as a goal to minimize the work involved. If our analysis does not capture this secondary user goal, in design we may miss an opportunity to streamline that task and the two goals may remain in conflict.

Finally, there is another kind of concern, personal concerns that relate to the user as a person rather than to the work. For example, most workers want to do almost anything to avoid being embarrassed or being made to look stupid. It is natural not to want to lose face publicly. Designs that emphasize worker production can be broadened to take these more personal concerns into account. Satisfied workers are more productive.

The point here is that information about this kind of personal concerns cannot be obtained from any requirements document, task analysis, or other engineering method. You must do the contextual inquiry and analysis and social modeling.

Label nodes with associated concerns. Summaries of user concerns are represented as text in “thought bubbles” connected to human roles and expressed in the perspective of users. We are showing what goes on inside the head of the person in the role in the style of a cartoon.

Identify influences and represent as relationships among entities

Each entity type can exert different kinds of influences on other entities.

Personal and professional inter-role influences. Individuals in work roles have different kinds of influence on individuals in other work roles that affect behavior within the work practice. There are personal feelings about the work and about co-workers that influence how well people work together. The model may also reflect plain old interpersonal or inter-role frictions and animosities.

In an enterprise that counts on teamwork, there will be dependencies of people in certain roles on others in other roles—the ability to do one’s job well can depend on others doing theirs equally well. As an example, consider a case in which one person gathers data from machines in the field and someone else analyzes these data. The analyst depends on getting accurate and timely data from the data gatherer.

Power influences. There are many kinds of power within most organizations. Power relationships between roles can stem from having different official ranks. As an example of influence built into the professional hierarchy, in our consulting with the U.S. Navy we often encountered a strong professional imperative that sometimes put rank above reason. It often meant to those of lower rank that it is better (for your career, if not for the task at hand) to follow orders and keep your opinions to yourself, for example, opinions about what might be a better way to do things.

Alternatively, nonmilitary employees can “pull rank” based on official job titles. Influence stemming from this kind of power relationship can be exerted in many ways. However, in a social model, power influence is not always based on power that comes with a given job title in an organization chart; it can be leverage or clout that exists as a practical matter and often comes from people who proactively take on leadership roles.

Influence comes from the strength or authority a person exerts in a work role. In meetings, to whom does everyone listen the most? When the chips are down, who gets the job done, even it if means working outside the box?

For systems with complex work domains, territorial boundaries are important to some people and can have a profound effect on how work is done. Interaction designers must take all these influences into account if they are to come up with a design that works in the target environment.

System-related influences. People in various roles can feel influences, including pressure or stress, from system-related entities, including the computer system. For example, a slow server can frustrate a data entry clerk and cause job stress.

Influences from ambiance. The general atmosphere of the workplace can exert powerful influences on work practice and behavior, including the values on which daily work practice is based, and the implied expectations that underlie the “way of life” in an organization.

Influences from work domain constraints. Constraints imposed by legal requirements and regulations, as well as organizational policies and politics, can frustratingly tie your hands as barriers to accomplishing your work goals.

Another source of influence on enterprise work practice has to do with whether system usage is discretionary or captive. This parameter, dictated by work domain constraints, indicates whether users in a particular work role have a choice in deciding to adopt or use the system being designed or whether political or organizational policies or business needs mandate the use of the system.

Discretionary users can walk away from the system if they do not like it. If a discretionary user does choose to use the system, that user is usually a receptive user, one who is favorably inclined toward adopting the system being designed. In contrast, captive users may feel trapped and may see the new system merely as adding to their work.

Barriers as influences. Barriers to successful work practice are a type of influence in the social model. One of the most common kinds of barrier to consider when redesigning work practice within a complex-domain system is rooted in people’s attitude toward change.

Just because new ways of getting work done, new technology, and new systems may have obvious advantages to you, the designer, does not mean that they will not be upsetting to, and resisted by, the people whose jobs are affected. The attitude toward change can vary across an organization, from top management all the way down to the worker bees.

We have labored in organizations in which legacy systems thrive long beyond their useful lives because old-timers are bound up in a struggle to hang on to the old ways within an ancient “stove pipe” management structure. It is all but impossible to sell new ideas in these bastions of tradition.

It may sound like a trite observation, but the “we have never done it that way” mentality can be a huge and real barrier to creativity in a social work environment. Dissatisfied workers can also present real barriers within a work environment. In your contextual inquiry and analysis be sensitive to indicators of job dissatisfaction and do your best to glean insight on the underlying causes.

Be sure to include in your social model how people think and act negatively in response to dissatisfaction. Is the watercooler or the break room the center of subversive coordination? Is subversion or passive-aggressive behavior a common answer to power and authority? How strong is the “whistle-blower” mentality? Does the organization thrive on a culture of guerilla activity?

As in the other models, barriers, or potential barriers, in relationships between entities are represented as a red bolt of lightning (), in this case on influence arcs. See examples of these barriers in Figure 6-6.

Consequences of and reactions to influence. People react to pressures and influences. Backlash reactions to influences are what Beyer and Holtzblatt call “push-back.” For example, a person in a particular work role feels pressure to deliver but barriers to performing on the job have combined to produce frustration.

Users can react to this kind of job frustration by “pulling in their wings” and hunkering down to “endure” the job or they can react by causing further stress for everyone. This kind of situation needs a solution that will restore everyone’s ability to contribute to the success of the enterprise while enjoying satisfaction on the job.

Create arcs to represent influences. Influences by one entity upon another are represented by an arrow, or directed arc, from the influencer to the influencee in the style of “influence: consequence/reaction”. An arc can be bidirectional, shown as a two-headed arrow, if, for example, the two entities depend on each other in the same way. Arcs are labeled to denote the specific influence being represented.

Social models in the commercial product perspective

Social Model for a SmartphoneSocial models about usage of a commercial product can be very illuminating to designers. What is the context of usage? When do people use it? Are other people around? What does the product look like—is the impression cool or is it dorky? What are the users’ feelings about having and using the product? Are they proud or embarrassed to own it? What does it say about them as individuals? What influenced them to buy it as opposed to a competing product?

The envisioned social model

As new work roles arise, so do concerns and influences experienced by people in those roles.

Creating a flow model diagram

Since early contextual analysis, you will have already been creating a flow model, representing workflow and other flow within the enterprise. We introduced this with a quick sketch in Chapter 4. Structurally, a flow model is a graph of nodes and directed arcs (arrows).

Nodes for entities. Labeled nodes represent entities in the enterprise workflow. Be sure you have represented as nodes all the work roles, including individuals or groups, direct or mediated users, potential users of all kinds, and all other entities that interact to get work done within the work practice.

“Other entities” include people outside the enterprise and entities such as systems, software, and devices. Most work domains in a domain-complex system context have a central database that users in all kinds of roles use to store, update, and retrieve work data. Draw entity nodes for information systems and databases that, like the work roles, are usually central in the workflow. Label each node with the corresponding entity name. Instead of using labeled circles for work role nodes, you can make your flow model more expressive by representing work roles as icons or stick figures depicting one or more people in those roles. You can make your flow model even more compelling by representing entity nodes with pictures of the corresponding personas labeled with their persona names, where they exist.

Having the user work roles visually in the center of a flow model also will help maintain user-centered thinking. Also, focusing on their workflow will help maintain usage-centered thinking.

Arcs for flow. Add labeled arcs or arrows to connect the entity nodes, showing who talks with whom and who gives what to whom, both internal to the enterprise and externally in the rest of the world. The arcs represent communication and coordination necessary to do the work of the enterprise—via email, phone calls, letters, memos, and meetings. Arrows show the flow of information, goods, services, workflow, work products, and artifacts during the execution of work practice.

If flow from one work role or piece of equipment in the system branches to more than one place, it can be helpful to know about how often it goes each way. Sellers (1994, p. 62, Figure 67) suggests labeling flow lines with percentages representing frequency of flow, if you have data to support it. Along with the label naming each arc, as much as possible, add a tag or identifier back to the relevant associated part of the raw data, using the tagging we did in Chapter 3.

If physical equipment contributes to flow, for example, information is communicated via telephones or email, label arcs accordingly. Flow model components should reveal how people get help in their work and make it clear where each artifact comes from and where it goes in the work process. Flow models also include non-UI software functionality, too, when it is part of the flow; for example, the payroll program must be run before printing and then issuing paychecks.

If you make a flow model of how a Website is used in work practice, do not use it as a flowchart of pages visited, but it should represent how information and command flow among the sites, pages, and users.

Flow models in the product perspective

In the perspective of a system with a complex work domain, the flow model is a complex enterprise representation. In the product perspective, the flow model can still be useful but is usually much simpler because there is usually no “organization” involved.

Flow models in the product perspective usually have fewer work roles than their domain-complex counterparts. The nature of work in the product perspective is different because of the fact that it does not happen in a fixed place. In an organization the workflow is somewhat fixed, although usually complex.

For a product, the workflow and context have much more variation from somewhat defined usage to connections with other users and devices for a large number of purposes. For example, in the case of a camera, most people just use it to take pictures, but if we expand the scope of consideration of workflow we get into how the pictures are downloaded, stored, and further processed and exchanged. Those parts of the photographic process could have implications for camera design.

For example, the need for easy physical access to the flash card, tethered-use picture transfer by cable, remote transfer by WiFi or infrared connections, sharing with friends and family, and streaming directly to printers or the Internet. The flow models of work in the product perspective tend to be much less connected than the typically established work patterns in an organization.

As another example, if the product being designed is a midrange laser printer, you need to model work activities in different types of homes, offices, and businesses, including all the activities for finding the right cartridge when one runs out and where to buy one.

Similarly, the amount of information exchanged among different work roles associated with a commercial product tends to be less structured and more opportunistic in nature. Also, given that the adoption of most end user products tends to be discretionary, it is much more important to capture and model a broad range of subjective and emotional impact factors than in domain-complex system contexts.

The envisioned flow model

Holtzblatt and colleagues (Beyer & Holtzblatt, 1998, pp. 275–285; Holtzblatt, Wendell, & Wood, 2005, Chapter 11) use the term “visioning” to describe their creation of an envisioned flow model. Through structured and focused brainstorming, the team creates a new design for work practice. The resulting vision is a story about the future, a new flow model of what the new work practice will be like and how the new system will support it.

To sketch out your envisioned flow model, you can start by reviewing, if necessary, relevant parts of your WAAD (Chapter 4) and any relevant design-informing models including, of course, your existing flow model. Brainstorm the flow of information and physical work artifacts among work roles and other parts of the system, such as external data sources and any central databases, as needed to carry out the high-level tasks in your HTI. Look for where work is handed off between roles, as these are places where things can fall through the cracks.

Tasks vs. functions

In order to understand task modeling, one must appreciate the distinction between a task and a function. Informally, we may use the terms more or less interchangeably when talking about the features of a system, but when we wish to avoid confusion, we use the term “task” to refer to things a user does and the term “function” to things the system does.

When the point of view is uncertain, we sometimes see a reference to both. For example, if we talk about a situation where information is “displayed/viewed,” the two terms represent two views of the same phenomenon. It is clear that “display” is something the system does and “view” is something the user does, as the user and system collaborate to perform the task/function. Within contextual analysis, of course, the user, or task, view is paramount.

Task inventories

A hierarchical task inventory, in which tasks are broken down into a series of subtasks and steps, is used:

Also, the accounting of the scope of tasks in hierarchical task inventory can serve as feedback about completeness in the contextual inquiry data, highlighting task-related areas of missing or inadequate contextual data to pursue in subsequent data-gathering activities. A hierarchical inventory of tasks is also a good source from which to select tasks for usage and design scenarios.

Task naming in hierarchical task inventories

In hierarchical task decomposition, each task is named and task names are usually of the form “action object,” such as “add appointment” or “configure parameters.” Task names require usage-centered wording rather than system-centered wording. For example, “view appointment” is a task name, but “display appointment” would be a system function name.

Hierarchical relationships are represented graphically by the usual tree-like structure, as in Figure 6-11. If task A is drawn above task B, it means A is a super-task of B, or B is a subtask of A. Exactly the same relationship exists between A and C. B and C are “sibling” tasks.

The litmus test characteristic for the meaning of this hierarchical relationship is that doing B is part of doing A. Another way to put it is: if the user is doing task B, then that user is also doing task A. As an example, if the user is filling out the name field in a form (task B), then that user is also filling out a form (task A).

Avoid temporal implications in hierarchical task inventories

The hierarchical relationship does not show temporal sequencing. So, in Figure 6-12 we depict an incorrect attempt at a hierarchical relationship because selecting a gear is not part of starting the engine.

The full HTI diagram for MUTTS is enormous. Because the work roles often represent mutually exclusive task sets, often leading to separate interaction designs, it is convenient to treat them in separate HTI diagrams. In this example, we focus on the ticket-seller role and the corresponding most obvious task: “sell tickets.”

How does this break down into subtasks? This is where our design-informing model notes about tasks come in. If we organize them in a hierarchical structure, we will see notes about big tasks at the top, subtasks in the middle, and individual user actions (if any) at the bottom. Looking at the top-level notes, we see that “sell tickets” involves a number of potential user activities to find and decide on an appropriate event before the actual ticket purchase is made.

We intend the “sell tickets” task to encompass all event searching and other subtasks that necessarily go into making a final ticket sale. In Figure 6-14, we show a few more details for under the “sell tickets.”

As we work with tasks we try to organize by adding logical structure. For example, there may not be task-related work activity notes explicitly about “finding information” in the contextual data, but there are references to work activities that imply the need for searching, browsing, and filtering event information. So we have pulled these together and synthesized the general heading of “find information.”

Envisioned task structure model

If the task structure changes in your new vision of work practice, then it is important to update the HTI representation to reflect your envisioned task structure. The HTI also shows the new vision of how all the subtasks fit together under the tasks.

Usage scenarios as narrative task interaction models

Scenarios are a task description technique that offers powerful tools for gaining insight about user needs and activities, supporting almost every phase of the interaction design lifecycle. In this chapter the term “scenario” refers to a “usage scenario” because these scenarios are extracted from contextual data that reflect actual usage that stems from real work practice in the existing work domain. When we get to design, we will talk about “design scenarios” because those scenarios are stories of what usage will look like using the new design.

Like other design-informing models, scenarios are threads that link various interaction design process activities. Scenarios begin in contextual inquiry and requirements analysis and later will play an obviously important role in design. Real contextual data provide the necessary richness to avoid superficiality (Nardi, 1995). Even after transitioning to a product, scenarios can be updated and used for usability evaluation and in training to show users examples of how to do various tasks.

What are scenarios, how do they work? Usage scenarios are stories about specific people performing work activities in a specific existing work situation within a specific work context, told in a concrete narrative style, as if it were a transcript of a real usage occurrence. However, as Go and Carroll (2004) point out, scenarios are many things to many people. In addition to their obvious value in requirements and design, Go and Carroll (2004) demonstrate their use as a brainstorming tool for planning, a decision-making tool for stakeholders, requirements engineering support, and a tool for object-oriented analysis and design.

Scenarios describe key usage situations happening over time, being deliberately informal, open-ended, and fragmentary. Interaction designers use these scenarios to gain a better understanding of the system usage in the context of the user’s actual experience. Tasks defined in task modeling become the heart of each scenario, which attempts to capture a representative description of the actual task performance.

Because scenarios are work oriented, they focus on needs, goals, and concerns of users. Scenarios reveal and facilitate agreement on requirements and evoke thought and discussion about requirements, design, user experience goals, and testing strategy.

Elements of scenarios. Scenarios typically capture these kinds of elements:

Usage scenarios should be annotated, as meta-data, with comments about what you have observed that works and what does not, what the problems are with the way things are done currently. We represent a barrier or difficulty in a usage scenario with the usual red lightning bolt () added at a strategic place in the text.

Scenarios are not for everyone. The efficacy of scenarios as models to inform design is not universally lauded. In a CHI 2003 tutorial, Constantine and Lockwood (2003) claim that scenarios suffer from a few drawbacks, which we quote verbatim here:

Envisioned usage scenarios or design scenarios

One of the most effective kinds of design-informing model for facilitating connections between requirements and design is the design scenario. In the envisioned transition to design, these scenarios are stories of what usage will look like in the new design, stories that inform design in a detailed and concrete way.

Design scenarios are the best way to visualize early the consequences of design choices and to share and communicate design ideas at the task level. Scenarios are an excellent medium for discussion of design alternatives and are easy to change as the design evolves. Much of your early design can be informed by design scenarios, starting with the key task set you have chosen to lead the design effort.

In creating a design informed by a scenario, you do not want your design to be too specialized for just that one scenario, but you want to be general enough to cover the scenario. However, do not overgeneralize the design to cover every user’s needs in a big potpourri of functions, either. As your personas evolve (next section), you can feature them in design scenarios. This will help show clearly how your designs are aimed at particular personas. Soon you will also be extending your scenarios by interspersing the narrative with graphic presentations of storyboards.

Step-by-step task interaction models

A more direct and less story-oriented way to describe task interaction is by a step-by-step task interaction model. Beyer and Holtzblatt (1998) call this kind of model a “sequence” or a “sequence model.”

A step-by-step task interaction model contains a detailed description of task performance observed in users or as told by users. Remember that task interaction modeling is all about current work practice, not (yet) an envisioned way to do things with a new system. So, any references to specific systems or technology necessary in describing the task steps will always be to existing technology and existing task-supporting systems.

The task interaction model of work also shows the detailed steps of task performance, including temporal ordering of actions and activities. Like usage scenarios, task interaction models capture instances of possibilities (“go paths” or representative paths), not complete task specifications. At the beginning, individual task interaction models will be mostly linear paths without branching. Later you can add the most important branching or looping.

So, for example, an initial task interaction model for an online purchase might not show a decision point where the user can pay with either a credit card or PayPal. It would just be a linear set of steps for the task of buying a ticket with a credit card. Later, as task interaction models are consolidated, a separate linear path for the alternative of paying with PayPal is merged, introducing a decision-making point and branching (see sub-section later).

Task and step goals. A task or step goal is the purpose, reason, or rationale for doing the task or taking the step. Called the user “intent” by Beyer and Holtzblatt (1998), the goal is a user intention, in the sense of being “what the user wants to accomplish” by doing the task. Each task interaction model will include a goal statement at the top. Goals and subgoals, as well as multiple goals, are possible for the same task and for each step in a task.

The goal of a task, being the “what” of a task interaction model, is often more important to understanding work than the way a task is performed or the steps of the “how.” If the work stays the same in the transition to a new system, the task goal usually stays the same, regardless of the operational steps in the way of doing the task. In fact, a list of the goals can stand alone without the task steps, as a “to-do” list for the user.

Task triggers. A task trigger (Beyer & Holtzblatt, 1998) is an event or activation condition that leads that user to initiate a given task. For example, when a user makes a phone call, it might be because something came up that presented an information need that can be resolved by the call. If the user logs into a system, it is because a need arose, maybe from an incoming call, to access that system.

If a user sends a “heads-up” message to a user in another role, it is because of a desire or need to inform that user of something important to the work process. Triggers are easy to identify in your contextual inquiry observations. New work arrives in the user’s in-box, a new aircraft appears on the air traffic controller’s screen, an email request arrives, or the calendar says a report is due soon.

Information and other needs in tasks. One of the most important components of a task description is the identification of user information and other needs at any step. Unmet information needs constitute one of the largest sources of barriers in task performance. The contextual inquiry and analysis processes and modeling can help you identify these needs and eventually design to meet them.

Information and other needs of people in work roles at certain points within task performance are represented by specific annotations to the graphical diagram of a step-by-step task interaction model. Just before the step in which the need occurs, we add an indented line beginning with a red block “N,” like this, N, followed by a description of the need.

Barriers within task interaction models. These are things that happen or difficulties encountered that present impediments to task performance, including things that slow the user down and make a task more difficult than necessary. The symbol for a barrier in a task interaction model is, you guessed it, a red lightning bolt (), which you should put at the beginning of an indented line explaining the barrier.

Something that requires the user’s attention to be divided might be a task barrier or an intervening manual step that interrupts the flow of using the system. Task barriers also include interruptions and having to “stack” one task in the middle to go off and do something else before coming back and trying to remember where things were in the original task. For example, suppose a key input to a task is unavailable, delayed, or difficult to dig out. Perhaps the user has to stop in the middle of the task and go to a different system to get the needed information. That kind of task detour is a barrier.

If the user’s reaction or response to a barrier is known through the contextual data, add a brief description of that right after the barrier description among the task steps.

Creating a step-by-step task interaction model. Step-by-step task interaction models are mostly textual. Write the initial task interaction model as a linear task thread, as a model of one instance of how a task happened with a user, not a general model of how all users perform the task. Sequential steps can be written as an ordered list without the need for flowchart-style arrows to show the flow. Linear lines of text are less cluttered and easier to read.

Start with some structural components, a label for the task name and a contextual data identifier, a tag identifying the source of the specific data used for this instance of the model.

The task description is labeled at the top with one or more task goals and the task trigger, followed by the steps at whatever granularity of detail is needed to help everyone understand it. Lines describing breakdowns and information needs are indented to set them off, interspersed with the steps, and labeled, respectively with a or an N. Include responses or reactions to barriers, if known, and label as such. In addition, each task step can be labeled with its own step goal(s) and step trigger.

It can help analysis and discussion to number the steps so that you can refer to, for example, step 5 of the send email task interaction model. Note cases of multitasking, where the user is juggling more than one task thread at once. The increased cognitive load to keep track of multiple tasks can be a barrier to ease of use.

Branching and looping. Although step-by-step task interaction models are primarily for capturing linear sequences of representative task steps, sometimes you encounter a point in the work practice where there is a choice. You observe some doing A and other users B. You can generalize the task sequence representation by showing this choice in both observed paths using branching, as shown with arrows on the left-hand side of Figure 6-15. Note the conditions for branching on the diagram.

Similarly, if you observe iteration of a set of tasks or task steps, you can represent that as shown on the right-hand side of Figure 6-15. For sets of steps that are repeated or iterated, note the number of iterations or the condition for termination.

Essential use case task interaction models

By combining the best characteristics of step-by-step task descriptions and software use cases, Constantine and Lockwood (1999, p. 100 ff) created essential use cases as an alternative task interaction modeling technique. An essential use case is a structured narrative, in the language of users in the work domain, that describes a single user intention or goal, a complete, well-defined task description that is meaningful to a user in a role (Constantine & Lockwood, 2003).

An essential use case is a kind of step-by-step task description but, being more abstract and less specific than step-by-step task interaction models of the previous section, it is not a complete story, nor is it a scenario, but rather a task skeleton on which a scenario story could be woven. An essential use case is a simple, general, and abstract task description, independent of technology or implementation. Just as it does in task interaction models, the importance of the task goals underlying an interaction greatly overshadows that of specific steps or user actions to carry them out.

In the classic style of using columns, or “swim lanes,” to represent collaborative task performance between user and system, an essential use case has two columns: one for user interactions and one for corresponding system responsibilities. The inclusion of system responsibilities clearly connects user actions to requirements for what the system must do in response.

Each essential use case is named with a “continuing verb” to indicate an ongoing intention, plus a fully qualified object, for example, “buying a movie ticket.” Essential use cases capture what users intend to do and why, but not how, for example, searching for a particular entertainment event, but nothing about user actions, such as clicking on a button.

Because only the essence of the transaction is represented and nothing is said about how the transaction looks in the user interface, it is an easy description for users and customers to understand and confirm. Essential use cases help structure the interaction design around core tasks. These are efficient representations, getting at the essence of what the user wants to do and the corresponding part played by the system.

The term “essential” refers to abstraction. An essential use case contains only steps essential to the user and the task. The representation is a further abstraction in that it represents only one possible task thread, usually the simplest thread without all the alternatives or special cases. Each description is expressed as a pure work-domain representation, not a system domain or design-oriented expression.

To illustrate, in Constantine and Lockwood’s ATM example, the user’s first step is expressed as an abstract purpose, the “what” of the interaction: “identify self.” They do not express it in terms of a “how”; for example, they do not say the first step is to “insert bank card.” This is a deceptively simple example of a very important distinction.

The abstraction of essential use cases is the opposite of the concreteness of usage scenarios. Usage scenarios read like real stories because they contain specific names of people and specific details about the context. These concrete details make the story easy to read and easy to understand, but when they are generalized as essential use cases, they serve better as inputs to interaction design.

Many of the details, although they add interest, are not essential to the general understanding of a task and how users perceive and perform it. In usage scenarios, those names and details are placeholders for more general attributes and information. The user’s name is a stand-in for all such users. A specific usage scenario describes an instance of the task, an instance of an essential use case.

Task cases are simplified and technology and implementation independent, traits that bring them close to the essence of work activities. Essential use cases are descriptions of what users do, not about design.

Envisioned task interaction models

Individual task descriptions in your envisioned task interaction models are exactly what you need as inputs to scenario and storyboard content. Begin your envisioned task descriptions by selecting a set of key tasks that will serve to focus the initial design effort and help you control complexity. Remember that task triggers are pivotal and must be represented in the envisioned models, too; otherwise the same task will not get done when using the new design.

Also, do not forget to design for task threads. It is relatively easy to design for single user tasks isolated from the workflow. In fact, HTI can lead you to think that tasks can be boxed up and addressed separately.

But, of course, tasks are woven into a fabric of user workflow. Real work occurs as task threads, and you have to design for the continuity of likely next tasks within the workflow. Your contextual data are key for understanding where you find these “go paths” or “happy paths” that users like to slide through.

Analyzing scenarios to identify ontology

As usage stories, scenarios tie together many kinds of design-informing models. They help you identify information objects and how they are manipulated and by which work roles. To see links with other design-informing models, you can tag or highlight words and phrases occurring in scenarios with the type of design element they represent. You can identify and label the components of design scenarios, such as tasks, actions, user interface objects, user roles, user experience goals, user classes, user characteristics, application information objects, system data objects, and work context.

Constructing the artifact model

How do you make the model? Well, the artifact model is mainly a collection of artifacts, but you can organize it for analysis and use. In contextual inquiry you will have collected the artifacts, usually visual, by making a drawing, a copy, or a photograph or by having collected a real example of the artifact. An example of a tangible work artifact is a guest check from a restaurant. If an artifact is more aural than visual, a recording of the sound could be an artifact.

Next, the team should make “artifact posters.” Attach samples of each artifact to a separate flip chart page. Add annotation to your “exhibits” to provide more information about your observations of them in the work practice. Add explanations of how each artifact is used in the work practice and workflow.

Annotate artifacts with stick-on notes associating them with tasks, user goals, and task barriers. Each poster drives discussion to explain the artifact’s use while trying to tease out associated issues and user needs. As usual, the process can generate additional user work activity notes from what is learned about the artifacts and how they are used.

Envisioned physical model

As much as possible, try to describe the physical model of the new work practice and new system. In many cases, the physical model will not change that much in the transition. Our Ticket Kiosk System is an exception; the physical model will change completely.