The_Book-_1__2.txt

4.1.1 You Are Here
We begin each process chapter with a "you are here" picture of the chapter topic in the context of the Wheel lifecycle template; see Figure 4-1. We have talked about eliciting work activity data (Chapter 3) and now we will analyze that data to understand the work context for the new system you are about to design.
  Our source for much of this material on contextual analysis comes from Beyer and Holtzblatt (1998). The credit for this is theirs; any errors of commission or omission are ours.
  Although the activities we describe for contextual inquiry and contextual analysis do occur somewhat in sequence, the sequence is not followed slavishly, allowing for reviewing or redoing a stage and, of course, for iteration.






Figure 4-1
You are here; in the contextual analysis chapter, within understanding user work and needs in the context of the Wheel lifecycle template.



4.1.2 Contextual Analysis Is Data Interpretation
Now that you have used contextual inquiry to observe and interview users about 
 the nature of their work in context and collected corresponding contextual 
 data, it is now time to analyze that data to understand the work domain. According to Beyer and Holtzblatt (1998), contextual analysis consists of user work activity data interpretation, consolidation, and communication.
Interpretation of raw work activity data is accomplished through:

� building a flow model and
� synthesizing work activity notes

Data consolidation and communication are accomplished by, respectively:

� building a work activity affinity diagram (WAAD) from the work activity notes
� walkthroughs of all these work products

In the next few sections we will detail the phases of this analysis.



4.1.3 Overview of Data Interpretation
In Figure 4-2 we depict an overview of data interpretation, driven by user researchers who are reporting back to the rest of the team as they review and discuss their raw work activity data. As the debriefing unfolds, some team members construct the flow model as others create work activity notes (described next).











Figure 4-2
Data interpretation in contextual analysis.



  We also get a few notes about insights and design ideas here, as well as notes about "data holes," missing data that need to be collected in the next visit. This stage involves individual and group brainstorming and analyses with the objective of understanding user work activities as much as possible.
Two important things about contextual analysis:

� Contextual analysis does not directly yield either requirements or design.
� You probably have to do much of your data interpretation separately for each of the work roles.

  The first point tells us that this data interpretation step is not an interpretation in terms of requirements or design. This step of contextual analysis is to pull meaning and depth of understanding from the raw user work activity data. Data interpretation allows the team to broaden the connections in raw data, which connect one or two team members with a few users, to connect all team members with all interviewees through sharing and discussion.
  The second point, about work roles, reflects the fact that there is little or no overlap of responsibilities, work activities, or user concerns between, say, the Middleburg University Ticket Transaction Service (MUTTS) ticket seller and the MUTTS database administrator. Each performs different work with different concerns and needs. Therefore,  much of the data interpretation and 
 consolidation must be done in parallel for each of the work roles. Some modeling, such as  creating the flow model, is used to integrate it all back 
 together. 
  The essence of data interpretation is reviewing, analyzing, and discussing the raw user work activity data. A flow model is constructed. Work activity notes are produced from raw user data and tagged by source and type.
 Your interpretation of data will be used in the next visits to the customer/ 
 users to check the accuracy of your understanding with the next interviews and 
 observations. Show your data to the customer and users to get their confirmation (or not) and discussion, and look for new data to fill holes.


4.2 ORGANIZING CONCEPTS: WORK ROLES AND FLOW MODEL
As you do your contextual inquiry and analysis, there are a couple of organizing concepts: the flow model sketch and user work roles. While these technically are the beginnings of work models (Chapter 6), we include their beginnings



here because they are major organizing factors that will help you maintain an understanding of the overall enterprise. Therefore, you should be aware of them throughout both contextual inquiry and contextual analysis processes.

4.2.1 Managing Complexity with Work Roles and Flow Models
We stand at the beginning of a process in which we will invest a lot of effort to understand the user's work domain for which the system is being designed and how the users of that system are best served in the design. When we are starting cold and just beginning this undertaking, the task seems enormous and daunting. We need two things to help control the complexity and wrap our heads around the problem:

� a big picture of the work domain, its components, and how information flows among them
� a way to divide the big picture into manageable pieces

  Because these two things are somewhat in opposition and cannot be done by one single means, we need two complementary concepts to solve the two parts of the problem, respectively:

� a flow model to provide the big picture
� the concept of work roles as a basis to divide and conquer

  We cannot overemphasize the importance of work roles and the flow model in almost everything else you do in contextual inquiry and analysis and modeling. These two notions influence almost all the UX activities that follow in this book, including contextual inquiry, contextual analysis, requirements, design, user experience goals, and UX evaluation. Because they are a major component of the flow model, we start with work roles in the next section.

4.2.2 Identify Work Roles as Early as Possible
The very first thing to start doing as you talk with customers and users is to identify work roles.  A work role is defined and distinguished by a 
 corresponding job title or work assignment representing an area of work 
 responsibility.
As Beyer and Holtzblatt (1998, p. 163) put it, a  work role is a "collection of 
 responsibilities that accomplish a coherent part of the work." The work activities of the enterprise are carried out by individual people who act in the work roles,



performing tasks to carry out the associated responsibilities. Sometimes for simplicity we will refer to a work role as a person instead of spelling out that it is a person in that work role.
  A given work role may or may not involve system usage and some roles can be external to the organization, for example, a parts vendor, as long as they participate in the work practice of the organization.

 Example: Initial Work Role Identification in MUTTS 
The two obvious work roles in MUTTS are the ticket seller and ticket buyer. Among the other roles we discovered early in contextual inquiry are
the event manager, the advertising manager, and the financial administrator. The event manager interacts with external event sponsors and venue managers to book events for which they sell tickets. The financial manager is responsible
for accounting and credit card issues. The advertising manager interacts with outside sponsors to arrange for advertising, for example, ads printed on the back of tickets, posted on bulletin boards, and on the Website. In addition we discovered a few more work roles that we will introduce in later sections.


4.2.3 Start Sketching an Initial Flow Model as Early as Possible
A flow model is your picture of the work domain, its components and interconnections among them, and how things get done in that domain.
 A flow model captures workflow relationships among key work roles. A flow model tells who does what and how different entities communicate to get work done.
  Even though your early contextual inquiry data will be incomplete and not entirely accurate, we recommend you start as early as possible acquiring an understanding of the work roles and a sketch of the flow model, refining as the picture of the work domain, the system, and its users slowly becomes clearer. You will be constantly updating this overview as you learn more via the interviews and observations. Because the flow model is a unifying representation of how the system fits into the workflow of the enterprise, it is important to understand it and get it established as early as possible.
  Even the sketchiest flow model will help guide the remaining contextual inquiry. You will want to use the flow model as a reference to keep everything else in perspective as you do the research of your contextual analysis. Within the work domain and within the system, work is done by the work roles described in the previous section, which play a central part in the flow model.



  Therefore, you should begin your flow model sketch by drawing icons, labeled with the work roles, which will be nodes in a connected graph that is the flow model. Include any roles external to the organization but involved in any way in the work practice. Add additional labeled nodes for any other entity, such as a database, into which and from which anything related to the work practice can flow.
We will soon refine flow models in more detail.

 Example: Sketching the Flow Model for MUTTS 
As we conducted contextual inquiry sessions for the MUTTS ticket-buying activity, we sketched out an initial flow model on flip charts, which we recreated here in Figure 4-3.


  Later, we give more details about how to create a final flow model (Chapter 6).



Figure 4-3
An initial flow model sketch of the MUTTS system.







4.3 CREATING AND MANAGING WORK ACTIVITY NOTES
The main point of contextual analysis has two basic parts:

� Converting raw contextual data into work activity notes
� Converting work activity notes into a work activity affinity diagram

  This section is about the former, using raw data to synthesize work activity notes.

4.3.1 Transcribing Interview and Observation Recordings
If you recorded your user and customer interviews in the contextual inquiry process, video and/or audio, you must begin contextual analysis with transcription, so you can see the raw observation and interview notes. The written notes or transcripts will of course still be just as raw as the recordings, meaning you still have to do the analysis to filter out noise and boil it down to the essentials.
  In our experience we have seen people use inexpensive overseas transcription services for audio recordings of their user interviews and observations from contextual inquiry. If you do decide to use an external transcription service, make sure that you are not violating any confidentiality and non-disclosure agreements you have with your customers by giving an outsider access to raw data.

4.3.2 Reviewing Raw User Work Activity Data
In one or more interpretation sessions, gather the "interpretation group" such as the interviewers, the note takers, and other core UX team members. In this session, the people who performed contextual inquiry are coming back and reporting to the rest of the team.
Recounting one interview at a time, researchers:

� review interview and observation notes and any recorded audio
� retell the events
� in discussion with the group, capture key points and issues, design ideas, missing data, and questions arising in the course of the discussion

  User researchers talk about what users said and what they observed that users did. This ensures that the team captures the real work practice and daily



activities of the people the system is to support, not just the self-reported practice or official job descriptions.

� Start with one big session to help everyone get going in the same direction, then break into groups to work in parallel. Choose groupings to give an approximate balance of group size, background and skills, and distributing the user researchers across the groups.
� A moderator in each group keeps things on track, while user researchers give accounts of each interview.
� In general, people may interrupt to ask questions to clarify issues or fill gaps.
� As the interviews are reviewed, two things happen more or less in parallel: Design- informing modelers create and refine sketches of the flow model, and note takers make work activity notes.
� After the group data interpretation sessions, the groups get back together for brainstorming to tie up loose ends on the data interpretation.
� Speakers representing each group summarize their flow models, while helpers update these models, on flip charts or laptops with screen projection, in real time per discussion.
� The initial flow models from each group are consolidated into a single flow model upon which all groups can agree.
� Work activity notes are shared, discussed, and adjusted as needed and new ones that come from this discussion are added.

  Finally the group engages in introspection about lessons learned. The group brainstorms to evaluate their process reflecting on what went well and what could be improved for next visit and how.
The outputs of this process of review and interpretation are:

� sets of work activity notes synthesized from raw data
� a work activity affinity diagram to organize the work activity notes

These two outputs are discussed in detail in this and the following sections.

4.3.3 Synthesizing Work Activity Notes
As each user researcher recounts interviews and observations from the transcripts of raw data, and during any subsequent discussion about these data, the group helps synthesize work activity note content from raw data and someone designated as the note taker types notes in a specific format.
  Because some application domains can be unfamiliar to some team members, the work activity note synthesis should be done by people who have already been immersed in the contextual data, probably the same people who did the



interviews and observations. The notes should be captured in some kind of computer-readable form, whether it is in a word processor, a spreadsheet, or directly into a database system. Ideally, the final set of synthesized work activity notes should represent raw data so well that the team never has to go back to the raw data to answer questions, fill in blanks, determine what the real point was, or to sort out context.
  The step of synthesizing work activity notes from raw data of interview transcripts and observation notes is an important one. We have found from experience that this step is easy to get wrong, so we spell the process out in detail here. Work activity notes that do not work will almost surely lead you to a frustrating, time-consuming, and unsuccessful activity for building the work activity affinity diagram (WAAD). As we proceed we will introduce guidelines for synthesizing work activity notes,
starting here. (NB: the special green font used in the next line denotes such a guideline.)

As you create each new work activity note, tag it with a source ID, a unique identifier of the person being observed and/or interviewed when the note was written.

  These tags are essential links to follow back to the source person in case further questions must be asked about missing data, unanswered questions, etc.
Unless it will be otherwise obvious, you should also tag each work activity
note with the work role with which the note is associated. Later, when we build the WAAD, we will need to know the work role referred to by each note because we often compartmentalize the WAAD by work roles.

Paraphrase and synthesize instead of quoting raw data text verbatim.

  It is perfectly acceptable and often advised to paraphrase and rephrase or to condense or summarize to make your own synthesized user "statements."
We want the user's perspective but not necessarily verbatim quotes of the
user's words, which can be verbose and indirect. For paraphrased statements, you should maintain the user's perspective and remain true to the user's intentions.
  You should not introduce any new content and keep the expression terse and to the point. It is the analyst's responsibility to abstract out a clear and concise statement conveying the substance of the issue in question.
For example:

Raw data: "I think of sports events as social events, so I like to go with my friends. The problem is that we often have to sit in different places, so it is not as much fun. It would be better if we could sit together."




In the user's perspective: "When I am looking to buy student tickets to MU basketball, I look for an option allowing several friends to sit together." (Note that this reference to basketball games was taken from elsewhere in the raw interview data gathered from that user.)

  Sometimes the paraphrasing and abstraction can lead to a simple neutral "factual" statement. For example, using the same raw data as in the previous example, we get this statement in a factual perspective: "Many students who buy MU basketball tickets want the option to sit with their friends."
  Regardless of whether you write your work activity notes in the user's perspective, you should still retain a work domain perspective. In other words, we want to stay with observed work practice and not start moving too quickly into needs and requirements and definitely not into design.

Make each work activity note a simple declarative point instead of quoting an interviewer's question plus the user's answer.

  Questions coming from the interviewer and confirmed by the user should be worded as if they came from the user.

Filter out all noise and fluff; make each note compact and concise, easily read and understood at a glance.

  Raw user data are usually too verbose. You must filter out the noise and irrelevant verbiage, boiling it down to the essence.

Be brief: Keep a note to one to three succinct sentences.

Embrace breviloquence; eschew grandiloquence.
  Example (how not to do it): Here is a work activity note that a student team made in a work activity note synthesis exercise for a real-world document management system. It is obviously a verbatim copy, grabbing words from raw data without any synthesis. The resulting "note" is full of noise and will require repeated readings to understand the key idea later:

U12-63 Ah, they just, they sign and mark, let me see if I have one that I can pull up, it's like that, they've changed it. But here they mark like satisfactory or unsatisfactory. It's like applied from the date that they sign. And mark satisfactory, unsatisfactory and then the date. And students can have one unsatisfactory and still pass the exam.



  Here are some examples of good work activity notes for the aforementioned excerpt of the interview transcript. Note that both of these work activity notes are about what the user perceives as "factual" rather than expressing user experience:

At the conclusion of a research defense exam each faculty member on the student's committee signs and dates an exam card to indicate if the student's performance was satisfactory or unsatisfactory.
A student is considered to pass a research defense exam if he or she earns an assessment of "satisfactory" from all or all-but-one of the research committee.


Each note should contain just one concept, idea, or fact, with possibly one rationale statement for it. Break a long work activity note into shorter work activity notes.

  An example of a rationale statement is "I do not ask for printed confirmations of my ticket transactions because I am afraid someone else might find it and use my credit card number." If there are two reasons in the rationale for the idea or concept in the note, split it into two notes.

Make each note complete and self-standing.

  Be sure that each note is complete enough to stand on its own, a note that everyone can understand independently of all the others. Always resolve ambiguities and missing information as you synthesize your notes. Because the notes will be shuffled, sorted, and mixed in various ways,
each note will get separated from its companions, losing any context it got from them.

Never use an indefinite pronoun, such as "this," "it," "they," or "them" unless its referent has already been identified in the same note.

State the work role that a person represents rather than using "he" or "she."

Add words to disambiguate and explain references to pronouns or other context dependencies.

  When the antecedent is in the same work activity note, it is not a problem. However, if you separate the two sentences into two notes, you probably have to



repeat the thought of the first sentence in the second note. Otherwise, the connection to the concept can be lost.
  As an example of good work activity notes, consider this rather short passage of raw data in the transcript:

U10: I think it should, I think it should go to the faculty advisor electronically because, you know, the campus mail could take a couple of days to reach.

  That passage can result in several individual points as captured in these work activity notes (again, in the factual perspective), filling in some details that were established in further questioning of the user.

Exam notecard goes to faculty advisor before exam.

Exam notecards are currently sent to faculty advisors via campus mail, but could take a couple of days to reach them.
Exam notecard should be sent to the faculty advisor electronically [design idea].



Avoid repetition of the same information in multiple places.

  In general, things that go into the flow model, such as naming the work roles, do not go into the work activity notes or the WAAD. Similarly, things that go into user class definitions do not go into work activity notes.

 Example: Work Activity Note Synthesis for MUTTS 
As inputs to this example of work activity note synthesis, we repeat
selected comments from the raw data transcripts in the previous example of data gathering to show the relationship to the synthesized work activity notes.
Each of these notes would be labeled with "ticket buyer" as the associated work role. Here we show potential work activity notes that could be synthesized; others could be just as plausible. Note the cases where we had to add text (in italics) to fill in context lost due to breaking a comment into pieces. These user comments
are perhaps more design oriented than typical, but that is what we got.
User comment:

It is too difficult to get enough information about events from a ticket seller at the ticket window. For example, sometimes I want to see information about popular





events that are showing downtown this week. I always get the feeling that there are other good events that I can choose from but I just do not know which ones are available and the ticket seller usually is not willing or able to help much, especially when the ticket window is busy. Also, it is hard to judge just from the information available at the ticket window whether it has been well received by others.

Synthesized work activity notes:

It is too difficult to get enough information about events from a ticket seller at the ticket window.
I want to know about current and popular events.

I would like to be able to find my own events and not depend on the ticket seller to do all the browsing and searching.
There are potential communication gaps because the ticket seller does not always understand my needs.
During peak times, the level of personal attention from the ticket seller is minimal.
It would be nice to get reviews and other feedback from people who have already seen the show.
[Design idea] Consider including capability for people to add reviews and to rate reviews. Question: Should this capability be located at the event venues rather than the kiosk?

User comment (in response to thinking ahead about including athletic events):

When I am looking to buy student tickets to MU basketball, I like to look at different seating options vs. prices; I sometimes look for an option allowing several friends to sit together.

Synthesized work activity notes:

When I am looking to buy student tickets to MU basketball, I like to look at different seating options vs. prices.
When I am looking to buy student tickets to MU basketball, I sometimes look for an option allowing several friends to sit together.




User comment:

Last Friday, several friends and I were planning a birthday outing for our friend,
Suzy. We decided to get tickets to Juxtaposition, the MU a cappella group's show, and I volunteered to pick up tickets on my way home. When I got to the ticket office there was a long line and when it was my turn I found out we
could not get eight seats next to each other. I did not know if I should get tickets that are not next to each other or try for a different event. I needed to call my friends on the phone but knew I would be holding up everyone else in the line. I finally got out of the line to make the call and it took a lot more time.

Synthesized work activity notes:

Sometimes I need to coordinate events and tickets with friends who are not with me. Sometimes I need to buy a set of tickets with adjacent seating.
[Design idea] Consider an option in the kiosk to "Find best n adjacent seats."

Taking time to coordinate ticket buying for groups potentially slows down everyone in the line.
[Design question] Can we add anything to the kiosk that would facilitate group collaboration and communication? How about, at least, sending confirmation of ticket purchase to group members?
4.3.4 Extending the Anticipated Data Bins to Accommodate Your Work Activity Note Categories
Here is where you capitalize on the data bins that you began to create in Chapter 3. Extend the set of existing bins to cover all the anticipated data categories for your work activity notes, as you synthesize them from the raw data.
  Keep the bins as labeled stacks of notes on your work table so that the whole team can see them. The labels will denote all the useful categories plus a few generic ones for "open questions to pursue" and "issues for further discussion or debate."
Examples of typical data categories you might encounter in your raw data are:

� User and user class information
� Social aspects of work practice (how people interact with and influence each other)
� Emotional impact and long-term phenomenological aspects
� Task-specific information




� Physical work environment
� Design inspiration ideas

4.3.5 Printing Work Activity Notes
Although you can use handwritten work activity notes, some prefer to print the notes. Beyer and Holtzblatt (1998) recommend printing the notes on yellow Post-it note stock, such as the kind that has six peel-off Post-it labels per page.
  Notes printed or handwritten on colored bond printer paper formatted, say, six to a page, also work fine. If your work activity notes come from a database, you can use the "mail-merge" feature of your word processor
to format each note into the table cells for either plain paper or Post-it printing.
  Whichever stock you choose, print your work activity notes on plain white or yellow paper or Post-it stock to distinguish from other colors that you might use later for labels in the WAAD.

4.4 CONSTRUCTING YOUR WORK ACTIVITY AFFINITY DIAGRAM (WAAD)
This is the second of the two basic parts of contextual analysis: using work activity notes to build the work activity affinity diagram.

4.4.1 Introduction to WAAD Building
 Affinity diagramming is a technique for organizing and grouping the issues 
 and insights across all users in your contextual data and showing it in a 
 visual display that can cover one or more walls of a room. By pulling together 
 work activity notes with similarities and common themes, a work activity 
 affinity diagram, guided by the emerging flow model, helps consolidate 
 contextual data and generalizes from instances of individual user activities and 
 issues to highlight common work patterns and shared strategies across 
 all users. 

4.4.2 What You Need to Get Started
You are going to build a hierarchical diagram of common issues and themes taken from the data. An affinity diagram is used to organize an enormous mound of individual work activity notes into a structure that yields sense, affords visualization of the user's work and, eventually, suggests ideas for designs to



support it. You will need a big room with plenty of wall space, dedicated for the duration of the project. You need to be able to leave the work up on the walls over an extended period of time; it will be difficult and disruptive to have to move to another room in mid-process.
  Just like having a room dedicated for user experience evaluation, having a room set aside, and labeled as such, for your contextual analysis raises awareness and gives legitimacy to your process. It establishes a real "presence" in the organization so that people might ask, "What is going on? It looks like something big here."
Here is how you should prepare the room:

� Tape up a large "belt" of butcher paper or similar around the walls of the room (Curtis et al., 1999) as a working space for posting work activity notes.
� We have found that blue "painter's tape" holds well but releases later without pulling off paint.

  Make sure you have in hand the huge stack of work activity notes. Line up the players, the WAAD team. You will need about two people per 100-150 work activity notes, as the goal will be to complete the WAAD in a short time (1 to 11/2 days).
  Look for diversity in the WAAD team members. Definitely include the original user researchers and note takers, include analysts, designers, and other members of your broader team, and include some who would not have ordinarily gotten involved until later. If there are still empty slots on the WAAD team, spread them around among other stakeholders and others whom you would like to be exposed to the process. However, you would typically not include the rest of the design team because you will use them in the WAAD walkthrough in the next step.
  Establish roles and responsibilities. Appoint one of the original interviewers or note takers as leader or moderator to manage the process and the people, and to keep the WAAD building on track. The larger the group, the more leadership and moderation needed. Sometimes other "natural" leaders emerge within the team doing the affinity diagram. This is acceptable as long as the others are allowed to take initiative and have an equal say in things. However, intervention may be required if a self-appointed leader becomes too dominating.

4.4.3 Set     Rules      of      the      Game The moderator explains how it works. Shuffle the work activity notes so that each player gets a variety and no person in your group gets the notes from just one interviewee. Deal out a limited number of notes to each team member.



  Sometimes handing out too many notes at the beginning can overwhelm novice practitioners, preventing them from getting a handle on where to start. In these cases, it can help to limit the number of notes each person gets initially, requiring them to deal with those before they get more. In our experience, 20 notes per person work well to get started.

� Allow time for each person to see what they have in their "hand."
� At the beginning, the process starts out slowly and sequentially, with the moderator explaining each step, so that everyone can see how it works and can be part of the discussion.
� Let the initial work activity notes themselves drive the organization process.
� Someone starts by "playing" one work activity note:
� reading the note aloud
� possibly characterizing it with some other descriptive terms
� possibly entertaining some discussion by the group about its meaning
� Then that person posts it somewhere at the bottom of the large butcher paper working space.

  Because you are just getting started, you will not know how the structure will turn out. Therefore, it is best to start as low on the butcher paper as possible, building upward and leaving room for more and more levels. It is, after all, literally a bottom-up process. When the initial "hand" is played by everyone, deal out more until all the notes are gone.


4.4.4 Avoid Inappropriate Mind-Sets in Dealing with Work Activity Notes
When your team is considering each work activity note as you build your work activity affinity diagram, having the right mind-set can help determine success. Here are some tips.

Sit on your designer and implementer instincts.

  When discussing and organizing work activity notes, try to avoid too many discussions about design and any discussions about implementation. In one of our sessions, a team member rejected a work activity note by saying, "This note has a good idea but it is about something that will not be implemented in this version." How could he possibly know this early whether it could be implemented in this version? It sounded to us like unwarranted developer bias.



Because these comments were so far off base, we paused the session to remind everyone of the goals of this activity.
  As an example, in one session we encountered a note about a comment from a potential Ticket Kiosk System user that it would help in transaction planning to know when the next bus is expected to arrive. Knowing that the technology for tracking buses would be out of reach, analysts rejected the note. But bus tracking is not the only way to address this still legitimate user need. At a minimum, for example, the kiosk could display information about the average arrival frequencies for buses on each route.

Do not make sweeping decisions involving technology solutions.

  For example, for a student forms management system, the team was working with the mind-set of all-electronic forms. For programs of study, graduate students currently need to visit each committee member to get a signature on paper forms, leading to issues of delays and tracking down people. So, electronic forms sent via the Internet make for a better solution. However, electronic forms do not turn out to be the best solution in all cases. Because graduate student thesis defense approval forms are typically signed by the thesis committee at the time and place of the defense, paper forms are the still the simplest approach for that case.
4.4.5 Growing Clusters
After notes begin to be posted:

� Each team member in turn looks through his or her pile of notes, looking for other notes that are topically similar, for example, about the same user concern or work activity, to ones that have been posted.
� Notes that seem similar are said to "have an affinity for each other" and are read aloud and posted together in a cluster or "cloud" on the wall.
� Neatness is not essential at this point; just get birds of a feather to flock together.
� If there are two or more of essentially the same note, derived from different users, include them all in the cluster to show the "weight" of that issue.
� When no more notes can be found immediately to match the affinity of an existing cluster, someone will pick a new note from their hand to start a new cluster, and so on.

4.4.6 Compartmentalizing Clusters by Work Roles
In cases where the user interfaces and subsystems for each work role are essentially mutually exclusive (except for flow connections to other work roles), it is helpful to compartmentalize the WAAD by using work roles as the high-level



group labels. This is tantamount to developing separate WAADs for each work role. You may still have to deal with an occasional work activity note that involves more than one work role, probably by splitting or duplicating the note.

4.4.7 Topical Labels for Clusters
Clusters will grow and morph like colonies of amoeba as they mature into more clearly defined bunches of notes, each related by affinity to a specific topic. This is the beginning of what Cox and Greenberg (2000) call emergence, "... a characteristic of the process by which the group interprets and transforms ... raw [data] fragments into rich final descriptions."
  As the number of clusters grows, we have found it difficult to remember by what criterion each cluster was formed (the topic of their affinity). Work activity notes are put into the same cluster because they have an "affinity" for
each other; that is, they share some common characteristic. But a quick glance at a cluster does not always reveal that characteristic.
As a solution, make a temporary label (before the cluster becomes a
group with an official WAAD label) to make the "topic" of each cluster explicit, to identify the "gestalt" of the whole group, the theme that brought them together.
  Temporary cluster labels allow analysts to consider the cluster as a candidate for posting further notes without having to look through the notes themselves every time. Shown in Figure 4-4 is one of the clusters for ticket-buying activities with MUTTS showing its temporary topical label.
  Topical labels are only to help you remember what each cluster is about. When you have a new work activity note and are looking at a cluster to attach it to, topical labels serve as a cognitive-offloading technique. By offloading descriptions of the clusters from your working memory to the environment, namely to these cluster labels in the affinity diagram, you (the analyst) get support for cognition.
  As clusters grow, evolve, expand, and merge, so do the topical labels. As you introduce more work activity notes, do not let topical labels determine or constrain the direction you take with a cluster; let data do the driving and change topical labels as needed to keep up. Figure 4-5 is a close-up of the topical label in Figure 4-4, again for our ticket-buying system, showing a couple of extra words added at different times to enlarge its scope during the affinity diagram- building process. Finally, a topical label is only temporary and will be removed when a real WAAD label is applied as the cluster evolves into a work activity note group.





Figure 4-4
Newly hatched cluster with temporary topical label.



4.4.8 Work Activity Note Groups
Soon clusters will mature into real affinity groups. As a cluster of work activity notes becomes a group, notes in the amorphous "cloud" of the cluster are posted in a vertical column and the group is labeled with a real group (affinity) label, in the user's perspective.
  A group, for our kiosk system, with a first-level label in the user's perspective is shown in Figure 4-6.




Figure 4-5
A topical label that has grown in scope during affinity diagram building.
4.4.9 
Speeding It Up
Later on, when everyone is up to speed, all the players can come up to the WAAD and move things along by "playing" their
work activity notes in parallel. Each one walks up to the growing WAAD and posts his or her work activity notes where appropriate, while trying to stay out of each other's way. Although each note need no longer be read aloud, talking or reading aloud is encouraged when useful to help others be aware of current thinking and new developments, such as new groups being created.
























Figure 4-6
Data note group with first- level affinity label.



4.4.10 Stay Loose
Clusters are to be considered putty in the hands of analysts. They are but embryonic aggregations on the way to becoming work activity note groups. On that journey, they must remain highly malleable. As the WAAD grows, it is common, and to be expected, that clusters will move and morph into different clusters, and clusters will be split and/or merged. Labels change; notes migrate.
  As work activity notes are handled, read, and posted, if a note needs explanation, clarification, or improved wording, edit it with handwriting on the spot. If needed, for example, to split a work activity note into two, handwritten notes can be added, but do not make up your own data at this point. If you think a note should or could be in more than one place in the WAAD, break it into more than one note by making copies of the note and indicating that other copies of the note exist using a label that says something like "Node-ID copy n" and place the new notes accordingly.

4.4.11 Do Not Get Invested in Data Ownership
No work activity note or group is "owned" by any team member; you just have to go with the flow and see how it develops. The success of the WAAD-building process is determined somewhat by the competence and experience of the analysts at organizing and classifying information, identifying common characteristics, and naming categories. However, there are some checks and balances. As multiple groups emerge, a work activity note may be perceived to be better placed in a different group. Anyone can place and/or move a note and make and/or change a label.
  Just make sure that other team members are aware of the rationale and the emergence of new group or cluster definitions. There is no single correct affinity diagram for the data; many different outcomes can be equally effective.

4.4.12 Monitoring Note Groups
The goal for groups is to keep them relatively small. Your team can decide the threshold size for your situation, but anywhere from 4-5 notes to 12-15 notes defines the ballpark. As groups get to this size, you should break the group into two or more smaller groups, again based on affinity or topical similarity. Look for distinguishers as the basis for splitting.
  When the work activity notes in each hand are used up, the WAAD team should look at the groups. If there are very small groups (one or two notes), review them together and see if anyone can find an existing group for those notes. Think briefly about how to handle any "mavericks" that seem hard to





















































Figure 4-7
Team studying clusters to form groups.

place, but do not spend too much time with these stragglers. They might fall into place later, especially when more work activity notes are made and posted.

4.4.13 Label Colors
The hierarchy of the WAAD has a small number of levels of labeling, usually about three. It is common practice to distinguish the levels by the color of labels. The colors are arbitrary; just be consistent.

4.4.14 Labeling                      Groups The team looks through the work activity notes of a cluster and "promotes" it to a group. In Figure 4-7 you can see a team studying clusters in preparation to form groups.
  The team invents a label for the group derived from the notes, representing the theme of the group, and often adapted from the cluster topical label. The label for each group is handwritten on a Post-it of the color chosen for group labels and posted at the top of the column of notes in the group.
The rules are that a group label:

� has its substance entirely derived from data in the notes, not a preconceived or predefined characterization
� is written in the customer/user perspective





� is written in a story-telling mode (the user talking to the team telling about their work activities and thoughts)
� is understandable without reading the work activity notes in the group
� captures the collective "meanings" of the notes in the group
� is as specific and precise as possible to avoid confusion in later interpretation
� avoids wordings with low descriptive power, such as "miscellaneous" or "general"

  The penultimate point above is, of course, a good guideline for almost any HCI situation. For example, ateaminoneofoursessions used thelabel "How wevalidate information" when they really needed the more precise label "How we validate forms." A subtle difference but important to the intended affinity for that group.

4.4.15 Grouping Groups
After all the groups have been labeled, build up the hierarchy to reduce the structure breadth and increase the depth by grouping the groups. Looking at the group labels, move them around into larger groupings (bringing the whole group with its label).
  When you get groups of, again, up to about a half dozen group labels, they are supergroups or second-level (going up from the group labels at bottom) groups, which are labeled in a different color, the second-level color. In Figure 4-8, showing part of the affinity diagram for MUTTS, you can see that we used blue for group labels and pink for the second level.
  Similarly, you group second-level labels to form a third level, labeled with yet another color.
  As with group labels, wording of successive levels of labels has to represent their groups and subgroups so well that you do not have to read the labels
or notes below them in the hierarchy to know what the group is about.
  Do not spin your wheels by trying to over-refine things. It is a bit like being an artist creating a painting: use minimal and quick strokes to get a crisp and fresh effect. Overworking it can make it heavy and muddy. Do not seek the one best WAAD; as the master says, there are many paths to climb the same WAAD. You get diminishing returns soon after you start fussing over it.

4.4.16 Number of Levels
Some of the literature recommends a fixed, small number of levels in the affinity diagram. We have found, however, that some categories have more depth than others and that our ability to understand the meanings of groups is sometimes improved by more decomposition into subcategories. We recommend you let data determine the number of levels needed.




Figure 4-8
Second-level labels for groups of groups shown in pink.




4.4.17 Representing Hierarchical and Nonhierarchical Relationships
The affinity diagram is inherently a hierarchical structure and you need to represent the arcs connecting the groups. In addition to hierarchical levels, we find occasional other relationships between categories that cut across the hierarchy. Things that happen with users or choices that users make in one part of the affinity



diagram can have strong effects on choices they make in other parts. When these relationships jump out at you strongly, you can draw arcs on the butcher paper or tack on colored ribbons to represent those connections.


4.4.18 Walkthrough of the WAAD: Consolidation and Communication
One of the purposes of doing a walkthrough of the WAAD is communication, to share an appreciation of user work activities and associated issues with all stakeholders. At the same time, you can review and unify your work activity notes within the structure of the WAAD and look for data holes, work activity notes you still need.
  Invite all stakeholders, including marketing, customers, potential users, engineering and development staff, and so on. Decide on a strategy for sharing and communicating the contextual inquiry and analysis results. Tell everyone upfront (before the meeting) how it will work, who is involved, what is needed, how long to plan for, etc. Explain your process in a nutshell.
  Your goals will be to garner more input and discussion to help unify WAAD data and the flow model and to achieve a shared understanding of user work issues. This can also be used to brainstorm and come up with key insights as headlines for the executive summary report that may be necessary in some organizations.

� For management, emphasize high-level issues, cost justification, data integrity, security, and such corporate goals.
� Highlight the most important points and issues discovered.
� Create interest with unexpected things learned.
� Show graphical representations; flow models can be the most effective, as they show your interpretation of the flow of information and materials within their business process.

  Get management engaged to show them the effectiveness of your process. Get developers engaged to obtain buy-in for the upcoming requirements and design activities.
  Try to fit your process into the established methodologies of your organization;  keep discussion user centered or usage centered with a user 
 perspective, and real user quotes. Use work activity data to keep things usage 
 centered and to deflect opinions and personal perspectives and to resolve 
 disagreements.  After you explain the overview of what the data represent and what you are hoping to accomplish,  let everyone walk around and inspect the 
 WAAD as they will.



  As people walk the wall individually, taking it all in and thinking about user work and design to support it, several things can come to mind and you should ask everyone to make their own notes about these items for discussion and possibly to add them to the WAAD:

� design ideas-capture them while you can by adding them as "design idea" notes, distinguishable from the work activity notes by using a different color and/or by adding them at a different angle on the wall
� questions-to be answered by the team or by further data collection; add as "question" note in a different color or orientation
� data "holes"-missing data that you have discovered as necessary to complete the picture, used to drive further data collection in the field and added as "hole" notes in a different color or orientation

  As an interesting aside, in Figure 4-9, we show a team at Virginia Tech using affinity diagram software on a high-resolution large-screen display as an alternative to paper-based work activity note shuffling (Judge et al., 2008).
Each analyst can select and manipulate work activity notes on a PDA before sending them to the wall for group consideration, where they can move them around by touching and dragging.






















Figure 4-9
Building a WAAD on a large touchscreen.



Example: WAAD Building for MUTTS
In Figure 4-10, you can see a photo of a large part of the overall WAAD we built for MUTTS.





  Figure 4-11 is a close-up photo of the MUTTS WAAD showing details for three groups having an overall label "The type of things I expect to use the kiosk for."

4.5 ABRIDGED CONTEXTUAL ANALYSIS PROCESS
4.5.1 Plan Ahead during Contextual Inquiry by Capturing One Idea per Note
The idea is to produce work activity notes without the laborious and voluminous intervening raw data transcripts. Experienced practitioners, skilled at note taking and abstracting the essence, can do some of this abstraction of detail from the real-time flow of raw data during the interviews themselves.

4.5.2 Focus on the Essence of WAAD Building
The WAAD-building process itself can also be abridged by creating clusters of all the work activity data notes without building a hierarchical abstraction of the different categories. As you get through the part of the process where you put all the work activity notes on the wall to represent the affinities as clusters, you get a

Figure 4-10
The WAAD that we built for the MUTTS example.









Figure 4-11
A close-up of the MUTTS WAAD.

sense of the key themes and issues in the work domain. Using the temporary labels and walking through the clusters, you can immediately start creating a list of high-level requirements for the system.
4.5.3 Use Finer-Grained Iteration to Address Pressure for Early Deliverables
It is common for a whole project team to be under constant pressure to produce deliverables. Project managers want to keep track of the direction the project is going instead of being surprised after half the project schedule has expired. Many team members think only of designs in the context of deliverables, and most customers think the same way.
  Because designs do not materialize until later in the lifecycle, many people think there can be no deliverables in the early phases, such as contextual inquiry and analysis. If you set customer expectations properly for the kind of deliverables you can produce early, it can be a benefit to both of you to share your contextual inquiry and analysis results with others, including the customer. This is an important time to get feedback and reactions to your early analysis so that you can be sure you are on the right track.








  Doing a full contextual inquiry and requirements extraction process upfront (Figure 4-12) means a large investment in each stage before proceeding to the next and delayed design deliverables, causing conflict with an anxious manager or customer.
  An incremental investment in smaller and more frequent iterations is well suited for this common situation, as shown in Figure 4-13: Do a little contextual inquiry, a little contextual analysis, a little requirements extraction, and a little design and then get some feedback from users about whether you are on course.
  This could mean that for contextual inquiry you do limited initial interviews with only a few people in the most important work roles. Then you can try your hand at contextual analysis, building a limited WAAD, using it to extract some requirements (Chapter 5), and maybe even doing a little design and prototyping. Then go back and do additional data gathering for contextual inquiry (with perhaps another customer or user role) and make adjustments necessary to integrate the new findings.

4.6 HISTORY OF AFFINITY DIAGRAMS
Historically, affinity diagramming has been used as an effective method for generating hierarchical categories to organize large amounts of unstructured, far-ranging, and seemingly dissimilar qualitative data about almost anything.

Figure 4-12
Coarse-grained iteration of contextual inquiry, contextual analysis, requirements, and design.








Figure 4-13
Finer-grained iteration among contextual inquiry, contextual analysis, requirements, and design.



The technique is inductive in the sense that it is a purely bottom-up process within which terms used for category labels within the organizing structure come from data themselves and not from a predefined taxonomy or pre-established vocabulary as would be in a top-down deductive approach. As Wood (2007) says, "This process exposes and makes concrete common issues, distinctions, work patterns, and needs without losing individual variation." The process also shows up missing data, to drive additional data gathering.
  The affinity diagram has been called one of the most significant management and planning tools in business and has been used to organize many different kinds of ideas in brainstorming and qualitative data in studies. The original conception of affinity diagrams is attributed to Jiro Kawakita (1982) in the 1960s. Kawakita was a Japanese humanitarian who worked in areas of the ecology and rural revitalization and who received the 1984 Ramon Magsaysay Award for International Understanding. Sometimes called the KJ (Japanese people put what we call their last names first) method, the affinity diagram has become one of the most widely used of the management and planning tools coming from Japan. See Brassard (1989) for an early adaptation for business and system development.


Extracting Interaction Design Requirements





5.1 INTRODUCTION
5.1.1 You Are Here
We begin each process chapter in the book with a "you are here" picture of the chapter topic in the context of the overall Wheel lifecycle template; see Figure 5-1. This chapter and the next are about a bridge-the bridge between contextual inquiry/analysis (Chapters 3 and 4) and design (Chapters 7, 8, and 9).
  The bridge has two spans-one for needs and requirements and one for what we call design-informing models-each of which is extracted from the contextual data. This chapter is about extracting interaction design requirements within the activity of understanding user work and needs.

5.1.2 Now That We Have Done Contextual Analysis, We Have the Requirements, Right? Not
Except in those few work activity notes, perhaps, where users commented directly on a particular need or requirement, the work activity notes in your work activity affinity diagram (WAAD), not only do not represent designs, but they do not even yet represent requirements. Depending on how well you did them, the contextual inquiry and analysis you have performed so far give you an




Figure 5-1
You are here; the chapter on extracting interaction requirements, within understanding user work and needs in the context of the overall Wheel lifecycle template.




 accurate and complete picture of the users' work domain, including their 
 concerns and descriptions of their current usage.
  We now are going to attempt to identify the needs and design requirements for a proposed new system to optimize, support, and facilitate work in that domain. It is now our job to comb through the WAAD and any preliminary design-informing models, such as the flow model, and deductively extract those user needs and requirements and thereby construct the first span of the bridge.


5.1.3 Gap between Analysis and Design
Contextual inquiry and analysis are about understanding existing work practice and context. Then we move on to producing designs for a new system to support possibly new ways that work gets done. But what happens in between? The output of contextual inquiry and analysis does not speak directly to what is needed as inputs to design. There is a gap.

� Information coming from contextual studies describes the work domain but does not directly meet the information needs in design.
� There is a cognitive shift between analysis-oriented thinking on one side of the gap and design-oriented thinking on the other.









� The gap is the demarcation between the old and the new-between studying existing work practice and existing systems and envisioning a new work space and new system design space.

  This chapter is about how we begin to bridge this gap with requirements as shown in Figure 5-2.

5.2 NEEDS AND REQUIREMENTS: FIRST SPAN OF THE BRIDGE
5.2.1 What Are "Requirements"?
Almost everyone understands the basic meaning. The term refers to a statement of what is needed to design a system that will fulfill user and customer goals. But when you start getting specific, it is a term that can mean something different to just about everyone associated with developing interactive software systems. To one, it is about ascertaining all the functionality needed to do the job. To another it is a compilation of all the user tasks needed to do the job.
 In the UX domain, interaction design requirements describe what is required 
 to support user or customer work activity needs. To that end we are also concerned
 with functional requirements to ensure the usefulness component of the user
 experience. Finally, we will have requirements to fulfill the need for emotional 
 impact and long-term phenomenological aspects of the user experience.

5.2.2 Requirements "Specifications"
Before we get into extracting requirements from contextual data, let us look briefly at the forms interaction design requirements can take. One term we often think of when coupled with "requirements" is "specifications."
  In past software engineering traditions, a formal written requirements document was de rigueur and could even designate details about how the corresponding software is to be implemented, including such software stuff as

Figure 5-2
Overview of the bridge to design.



object models, pseudo-code, use cases, and software structure. However, currently in software engineering and software requirements engineering there is an increasing recognition that:

� Detailed formal requirements cannot ever be complete.
� Detailed formal requirements cannot ever be 100% correct.
� Detailed formal requirements cannot be prevented from changing throughout the lifecycle.

 As a result, there appears to be a trend toward abandoning the detailed 
 requirements specifications in favor of ascertaining the important features and 
 capabilities.
  Often people from a software engineering background expect a similar kind of requirements specification for the user interface. However, on the UX side we are talking about only interaction design requirements, nothing about software or implementation. Also, as we will see, it is not easy to lay down that same kind of requirements specification for the interaction design, nor is it particularly useful to try.
  However we specify our requirements, there is a broad range of acceptability for completeness and detail. For domain-complex systems, with many requirements for compliance and risk avoidance, you may need a rather complete specification of requirements.
  Our approach to interaction design requirements follows directly from the contextual data that we have gathered and analyzed. The result is not just a monolithic specification, but a variety of descriptions that, while not necessarily like software specifications, are each part of the whole that constitutes the interaction design requirements specification.
  Therefore, at the end of the day, or more likely the end of the week, requirements extraction produces an assortment of deliverables, each of which can be thought of as a kind of "specification"-for needs and requirements and for design-informing models such as personas, tasks, user experience goals, or usage scenarios. That is why all those activities and deliverables are brought together in this chapter and the next.

5.2.3 Software and Functional Implications of Interaction Design Requirements
User needs are really not just interaction needs. Usability and UX include usefulness that we get from functionality. Often an initial requirement extracted from contextual data first appears as a requirement for a broad



overall system capability-that is, it expresses a need for both functionality and user interface support.
  As an example, a Ticket Kiosk System requirement might state that a user should be able to buy tickets for up to 10 different events in one session or transaction. We recommend that you devise a way to record the functional needs 
 that correspond to user needs and requirements revealed in this process and 
 pass them on to your software engineering counterparts. It will help them be aware of needed functionality and will help you both stay on the same page during the project.

5.3 FORMAL REQUIREMENTS EXTRACTION
 This process of extracting needs and requirements is similar to data 
 interpretation and consolidation sessions of contextual analysis in that it involves a group sitting down together and going over a large amount of data, including the WAAD and evolving design-informing models. But here it is actually easier because much of the hard work is already done.

5.3.1 Walking the WAAD for Needs and Requirements
At the end of Chapter 4 we recommended doing a "wall walk," a walkthrough of contextual data in the WAAD. It is now time for your team to get re-immersed in work activity data; this time with the focus of the walkthrough on extracting needs and requirements rather than iteratively improving the data. The general
 idea is to traverse the hierarchical WAAD structure and focus on extracting
 requirement statements from work activity notes.

5.3.2 Switching from Inductive to Deductive Reasoning
 Extracting requirements from the WAAD calls for a deductive thinking 
 process. It is deductive because each work activity note in the WAAD is 
 treated as the major premise in a logical syllogism. The second "premise" 
 is everything you know about UX and interaction design. The conclusion 
 of this syllogism is a statement of user needs and requirements you 
 deduce from the work activity note, something we capture in a 
 "requirement statement." 
  To clarify with a small example from MUTTS and the Ticket Kiosk System, a WAAD note, say in node C19, that says "I am concerned about security and privacy of my transactions" can imply a design requirement (at a high level): "Shall protect security and privacy of ticket-buyer transactions." In the design,



this requirement might be at least partially met by a timeout feature to clear the screen between customers. Note that at this level, requirements can be a mix of interaction and functional requirements.

5.3.3 Preparation
Select a requirements team, including people you think will be best at deductive reasoning and creativity. You will need both UX and software people represented, plus possibly system architects and maybe managers.
  This team approach enhances SE-UX communication because the SE and UX roles are working together at a crucial point in their mutual lifecycles, describing and funneling the different kinds of requirements to the places they will be used. Choose a requirements team leader and a recorder, a person experienced in writing requirements.
  You may need a requirements "record" template in a word processing document, a spreadsheet, or a database schema to capture the requirement statements in a consistent and structured format in an interaction design requirements document (or requirements document, for short in this context). The requirements team will work in the room where the WAAD is posted on the wall.
  If there is a need for all to see each requirement statement, you can connect the recorder's computer to a screen projector and show the requirements document on an open part of the wall. The leader is responsible for walking the team through the WAAD, traversing its hierarchical structure systematically and keeping the team on track.

5.3.4 Systematic Deduction of Needs as "Hinges" to Get at Requirements
Start by letting everyone walk through the WAAD, individually and silently, to accommodate those who need to think quietly and to allow everyone to write notes about ideas for requirements. Then begin the main part of the process.
As the leader walks the team through the WAAD, one node and one note
at a time, the team works together to ask what user needs, if any, are reflected in this work activity note and the hierarchical labels above it.
  Such user needs are still expressed in the perspective of the user and in the work domain. Although the user need is not documented in the requirements document, it is an important "hinge" in the mental process of getting from work activity notes to requirements. This interim step will become almost automatic with only a little practice.



5.3.5 Terminology Consistency
 This pass through the contextual data is a chance to standardize terminology 
 and build consistency. Your contextual data will be full of user comments about an infinitude of usage and design concepts and issues. It is natural that they will not all use exactly the same terms for the same concepts.
  For example, users of a calendar system might use the terms "alarm," "reminder," "alert," and "notification" for essentially the same idea. Sometimes differences in terminology may reflect subtle differences in usage, too. So it
is your responsibility to sort out these differences and act to help standardize the terminology for consistency issues in the requirements document.

5.3.6 Requirement Statements
Next, the team translates each user need into one or more interaction design requirement statements. Each requirement statement describes a way that
you decide to support the user need by providing for it in the interaction design. Ask what new or more specific user interface feature you should see in the design to support the user needs implied by this WAAD note. There is
not necessarily a one-to-one correspondence between work activity notes in the WAAD and needs or requirements.
A given work activity note might not generate a need or requirement.
The ideas in some notes may no longer be relevant in the envisioned system design. Sometimes one work activity note can produce more than one need. A single need can also lead to more than one requirement. Examples of work activity notes, user needs, and corresponding requirements are coming soon.
  Now the recorder writes the requirement statement in the requirements document by first finding the appropriate headings and subheadings. If the necessary headings are not already in the requirements document, now is the time to add them and grow the document structure as the process continues.
  Interaction requirements often imply functional requirements for the system, which you may also capture here for communicating to your software people. For example:

Interaction requirement: "Ticket buyers shall be able to see a real-time preview of available seating for a venue."
Corresponding system requirement: "System shall have networked infrastructure to poll all kiosk transactions as they are happening and coordinate with the venue seating data to 'lock and release' selected seats."



  This is a good time for the software team members to work in parallel and capture those inputs to software requirements here so that they are not lost.
  These inputs will be transformed into software requirements specifications in the software requirements process, a separate process done only by the software team and not part of our scope here. Although software requirements gathering is not officially part of the interaction requirements extraction process, it is a shame to not take advantage of this opportunity to provide valuable software requirements inputs, based on real contextual data. This is also a good opportunity for you, the interaction designer, to coordinate with your software engineering teammates about your mutual requirements.
 In a requirement statement it is typical to use the phrase "Users shall 
 be able to .. ." and can be followed by a rationale statement explaining the 
 relationship of the requirement to the user need and how the requirement 
 was determined from that need. A "notes" statement can also be part of a requirement statement. Such notes are not always necessary but they document discussion points that may have come up within the extraction
process and need to be preserved for designers to consider in their process.



















Figure 5-3
Generic structure of a requirement statement.
5.3.7 
Requirement Statement Structure
A generic structure of a requirement statement that has worked for us is shown in Figure 5-3. A requirements document is essentially a set of requirement statements organized on headings at two or more levels.
  For systems where risk is high and traceability is important, each requirement is tagged with the WAAD source node ID, which serves as a link back to the source of this requirement statement within the WAAD. The WAAD in turn has a link back to its source in raw work activity data.
  Later, if a question arises about a particular need or requirement, the connection to original work activity data and the person who was its source can be traced to find the answers (sort of the UX lifecycle analog of a software requirements traceability matrix).
  Because we use the WAAD node ID as a link this way, someone should ensure that all WAAD nodes are labeled with some identification number before the
extraction process begins. We use A, B, C, ... for the highest-level nodes under the root node. Under node A, we use AA, AB, AC, ... , and for the work activity notes




themselves we use the group ID plus a number, such as AB1 and AB2; this is the identifier that goes in the "WAAD source node ID" part of a requirement.
  As an example, consider the work activity note that said "I am concerned about privacy and security of my transactions." In Figure 5-4 we show how the resulting requirement statement fits into the requirement statement structure of Figure 5-3.

5.3.8 Requirements Document Structure
We show two levels of headings, but you should use as many levels as necessary for your requirements.
  As an example of an extracted requirement for the Ticket Kiosk System, suppose in our contextual inquiry a user mentioned the occasional convenience of shopping recommendations from Amazon.com. The resulting requirement might look like what is shown in Figure 5-5.

 Example: Extracting a Requirement Statement 
 for the Ticket Kiosk System 
Note CA9 within the WAAD for MUTTS says "I sometimes want to find events that have to do with my own personal interests. For example, I really like ice skating and want to see what kinds of entertainment events in the nearby areas feature skating of any kind." This user work activity statement implies the user need, "Ticket buyers need to find various kinds of events."
  Labels on a group at a higher level imply a feature or topic of "Finding events" so we use that as the heading for this requirement in the requirements document. Lower-level labels in the WAAD narrow it down to
"Direct keyword search by event description"; we will use that for our subheading.
  We can then write the requirement in Figure 5-6.
  Note that this comment, also in the WAAD, "I sometimes want to find events that have to do with my own personal interests," could lead to consideration of a requirement to maintain personal profiles of users.








Figure 5-4
 Example requirement 
 statement.



























Figure 5-5
Sample requirement statement for the Ticket Kiosk System.











Figure 5-6
 Example requirement 
 statement for the Ticket 
 Kiosk System.
5.3.9 
Continue the Process for the Whole WAAD
In the Ticket Kiosk System example, you will also extract requirements for all the different ways you search and browse event
information, such as requirements to search by event category, venue, date range, and so on. Take the time here to pick all the fruits; it is too easy to neglect the connections of rationale to user work activities and lose much of the advantage gained from the contextual analysis work.
  After each requirement statement is written, it is very important for the whole team to see-for example, by projection display-or hear-for example, by the recorder reading it-the statement to ensure that the written statement represents their concept of what it was supposed to be.
  Later when reviewing and finalizing the requirements document, we may find that not every "requirement" extracted from the WAAD will eventually be
met because of cost, other constraints, and how our own knowledge and experience temper the process, but that kind of judgment comes later. For now, just keep cranking out the requirements.

5.3.10 Keep an Eye out for Emotional Impact Requirements and Other Ways to Enhance the Overall User Experience
When extracting requirements, most people will think of the functional requirements first, feeding usefulness. Most people might think of usability goals next, feeding UX targets. But do not forget that we are on a quest to design for a fabulous user experience and this is where you will find opportunities for that, too.
  In addition to getting at routine requirements for tasks, functions, and features, seek out those indefinable evolving characteristics essential
to a quality usage experience. Because factors related to emotional impact or phenomenological aspects may not be as clear-cut or explicit as functional or other interaction requirements, you have to be alert for the indicators.
  Work activity notes with user concerns, frustration, excitement, and likings offer opportunities to design a system to address emotional issues. Especially look out for work activity notes that make even an oblique reference to "fun" or "enjoyment" or to things like data entry being too boring or the use of colors being unattractive. Any of these could be a clue to ways to provide a more rewarding user experience. Also, be open minded and creative in this



phase; even if a note implies a need that is technologically difficult to address, record it. You can revisit these later to assess feasibility and constraints.

5.3.11 Extrapolation Requirements: Generalization of Contextual Data
User statements in a WAAD can be quite narrow and specific. You may need to generate extrapolation requirements to broaden existing contextual data to cover more general cases.
  For example, ticket buyers using MUTTS, in anticipation of a kiosk, might have expressed the need to search for events based on a predetermined criterion but said nothing about browsing events to see what is available. So you might write an extrapolation requirement about the obvious need also to browse events (as we did in Figure 5-6).
  As another example, in our WAAD for MUTTS, a ticket buyer speaks about the desirability of being able to post an MU football ticket for exchange with a ticket in another location in the stadium to be able to sit with their friends. In our extrapolation requirement statement we broadened this to "Ticket buyer shall be able to post, check status of, and exchange student tickets." And we added a relationship note: "Will require ticket-buyer user 'accounts' of some kind where they can login using their MU Passport IDs."
  In another work activity note a user mentioned it would be nice to be able to select seats from all available seats in a given price category. This translates to a requirement to display seating availability and to be able to filter that list of available seats (such as by price categories). Seat selection assumes the existence of a lock and release mechanism of some sort, something we perhaps did not yet have in the requirements document. This is a technical requirement to give the buyer a temporary option on the selected seats until the transaction is completed or abandoned. So we added an extrapolation requirement to cover it:

Shall have a default time interval for locking available seating while the ticket buyer is making a choice.
Rationale: If a ticker buyer has not performed any actions with the interface in a certain amount of time, we assume the ticket buyer has left the kiosk or at least abandoned the current transaction.

  The timeout will release those seats back to an available pool for others to access from other kiosks.



  Another work activity note said, "I often plan to attend entertainment events with friends." At first, we thought this comment was just a passing remark about how he would use it. It did not seem to imply a requirement because it did not say anything directly about a feature.
  On reflection, however, we could easily broaden it slightly to imply a possible need to communicate with those friends and, with a bit more extrapolation, maybe facilitate sending tickets or event information to them via email. This extrapolation could well be beyond the scope of the user's intent and it could be beyond the scope of the current project, but it should be saved as an input about a potential future feature and, more importantly, as a chance to provide a great user experience.
  This example is a good one because it starts with a statement about usage. And that is what contextual data are about, so we should not have missed seeing an implied requirement because "it did not say anything about a feature." It is our job to come up with requirements implied by usage statements.
  In balance, while extrapolation requirement statements may be necessary and valuable, we should be careful with them. To be sure, we distinguish them by calling them (and tagging them as) extrapolation requirements, which must be taken back to users for confirmation as real needs or requirements. This validation can result in a thumbs up and you can include it in your requirements document or it can result in a thumbs down and you can eliminate that requirement.

5.3.12 Other Possible Outputs from the Requirements Extraction Process
In addition to requirement statements, a work activity note in a WAAD can lead to certain other outputs, discussed in the following subsections.

Questions about missing data
Sometimes, as you go deeper into the implications of contextual data, you realize there are still some open questions. For example, in our contextual inquiry for MUTTS, while we were putting together requirements for the accounting system to aggregate sales at the end of the day, we had to face the fact that the existing business manages tickets from two independent systems. One is the local ticket office sales and the other is from the national affiliate, Tickets4ever
.com. During our contextual inquiry and analysis we neglected to probe the interaction between those two and how they reconciled sales across those two systems.



System support needs
You may also occasionally encounter system requirements for issues outside the user experience or software domains, such as expandability, reliability,
security, and communications bandwidth. These are dealt with in a manner similar to that used for the software requirements inputs. A few examples from the MUTTS WAAD illustrate:

Work activity note: "Identity theft and credit card fraud are huge concerns for me."

System requirement: "System shall have specific features to address protecting ticket buyers from identity theft and credit card fraud." (This "requirement" is vague but it is really only a note for us to contact the systems people to figure out potential solutions to this problem.)
Work activity note: "When I am getting tickets for, say, a controversial political speaker, I do not want people in line behind me to know what I am doing."
System requirement: "Physical design of kiosk shall address protecting privacy of a ticket buyer from others nearby."

Marketing inputs
Sometimes a comment made by a user during contextual inquiry might make a good input to the marketing department as a candidate sound bite that can be adapted into advertising copy. This is a good opportunity to communicate with the marketing people and help cement your working relationship with them.

 Example: Requirements Extraction for the Ticket 
 Kiosk System 
Here are a few selected requirements extracted from the MUTTS WAAD that we are using to inform requirements for the Ticket Kiosk System.
Shopping cart Existence of feature

Ticket buyer shall have a shopping cart concept with which they can buy multiple items and pay only once [BBA1-4]
Accessibility of shopping cart

Ticket buyer shall be able to view and modify shopping cart at all times [BBA3]





Shopping cart versatility
Ticket buyer shall be able to add different kinds/types of items (example, different events, sets of tickets for the same event)[BBA4]
Note: This requirement is important because it has implications on how to display shopping cart contents with dissimilar types of objects in it.
Transaction flow Timeouts
Extrapolation: Ticket buyer shall be supported by a timeout feature [BCA] Rationale: To protect ticket buyer privacy
Extrapolation: Ticket buyer shall be made aware of the existence and status of timeout, including progress indicator showing remaining time and audible beep near the end of the timeout period [BCA] [BCA1]
Extrapolation: Ticket buyer shall have control to reset the timeout and keep the transaction alive
Extrapolation: Ticket buyer's need to keep transaction alive shall be supported by automation, timer reset triggered by ticket buyer activity
Immediate exit
Ticket buyer shall be able to make a quick exit and reset to the home screen [BCB1]

Rationale: Important for kiosks in bus stations where user may have to quit in the middle of a transaction and to protect their privacy
Ticket buyer shall have a way to quickly return to a specific item they were viewing just prior to an immediate exit [BCB1]
Note: Ticket buyer shall be able to use an event ID number for direct access next time or the system can potentially do it using an "account" and restore state.
Recommendations for buying
Extrapolation: Ticket buyer purchases shall be supported by recommendations for related items [BCB2]
Extrapolation: Ticket buyer shall be able to say no to recommendations easily [BCB2]
Transaction progress awareness
Ticket buyer shall be able to track the progress of the entire transaction
(what is done and what is left to do) using, for example, a "bread crumb" trail [BCB3-4]





Ticket buyer reminders
Ticket buyer shall receive reminders to take the ticket and MU Passport/credit card at the end of each transaction [BCC1-2]
Checkout
Ticket buyer shall have, before making a payment, a confirmation page showing exactly what is being purchased [BCD1]
Ticket buyer shall receive actual ticket and not just confirmation [BCD2] Rationale: For maintaining ticket buyer trust
Note: This is a huge issue involving marketing, high-level business decisions, and hardware (printer) reliability and kiosk maintenance
Ticket buyer shall be able to use cash, credit cart, debit card, or MU Passport for payment [BCD3]
Note: For cash transaction it is difficult to recognize and dispense change [BCD4], and attracts vandals and thieves [BCD5]
System requirements Performance
The system shall have a good response time to make transactions fast (so ticket buyers do not miss the bus)[BCB5]

5.3.13 Constraints as Requirements
Constraints, such as from legacy systems, implementation platforms, and system architecture, are a kind of requirements in real-world development projects. Although, as we have said, much of the interaction design can and should be done independently from concerns about software design and implementation, your interaction design must eventually be considered as an input to software requirements and design.
  Therefore, eventually, you and your interaction design must be reconciled with constraints coming from systems engineering, hardware engineering, software engineering, management, and marketing. Not the least of which includes development cost and schedule, and profitability in selling the product.
What restrictions will these constraints impose on product scope?
Are product, for example, a kiosk, size and/or weight to be taken into account if, for example, the product will be on portable or mobile equipment? Does your system have to be integrated with existing or other developing systems? Are there compliance issues that mandate certain



features? Constraints arise from the problems of legacy systems, limitations of implementation platforms, demands of hardware and software,
budgets, and schedules.

 Example: Constraints for MUTTS 
A hardware constraint for the existing working environment of MUTTS is the necessity of keeping the secure credit card server continuously operational.
An inability of the ticket office to process credit card transactions would essentially bring their business to a halt. They have only one "general purpose" technician on staff to care for this server plus all the other computers, network connections, printers, scanners, and so on.
In addition, the physical space of the MUTTS office is constrained,
a constraint that should also show up in the physical model (Chapter 6), and work areas can become cramped on busy days. Their office space is leased, a fact that is not likely to change in the near future, so a more efficient work flow is desirable. Sometimes the air conditioning is inadequate.
  The constraints will show significant differences in going from MUTTS to the Ticket Kiosk System. Here are some example constraints that might be anticipated in the Ticket Kiosk System, mostly about hardware (systems engineering people would probably add quantitative standards to be met in some cases):

� Special-purpose hardware for the kiosk
� Rugged, "hardened" vandal-proof outer shell
� All hardware to be durable, reliable
� Touchscreen interaction, no keyboard
� Network communications possibly specialized for efficiency and reliability
� If have a printer for tickets (likely), maintenance must be an extremely high priority; cannot have any customers pay and not get tickets (e.g., from paper or ink running out)
� Need a "hotline" communication feature as backup, a way for customers to contact company representatives in case this does happen


5.3.14 Prioritizing Requirements
A drawback of affinity diagrams is that they do not contain priority information, so every note has the same weight as any other note. A note about a major task has the same significance as a passing comment. As a result, the extracted requirements are also unprioritized. To remedy this, as part of



the validation process, ask your customer and users to prioritize the requirements.
  At a minimum they can point out the key requirements and the requirements that are "also-rans." These can be separated into different sections of a requirements document or distinguished by a color-coding scheme.
  With a bit more effort you can tag each requirement with an importance rating. Later, you will use these priority ratings to decide which design-informing models to focus on. For example, important tasks will be the ones chosen as the basis for representative scenarios.
  Often, as the result of prioritizing, you and your customer achieve a realization of, and mutual understanding about, the fact that some requirements cannot be met realistically in the current product version and must be set aside for consideration in the future.

5.3.15 Taking Requirements Back to Customers and Users for Validation
After your own review, it is time to take the requirements document or requirements WAAD back to the customer and users for validation. This is a critical step for them because it gives them a chance to offer inputs and correct misconceptions before you get into design. It also helps solidify your relationship as partners in the process.
 For each work role, schedule a meeting with the representative users, 
 preferably some from the ones you have interviewed or otherwise interacted 
 with before, and some new users. Walk them through the requirements to 
 make sure your interpretation of requirements from the work activity notes is 
 accurate. 
  Pay close attention to feedback from new users who are looking at the requirements for the first time. They may provide valuable feedback on anything you missed or new insights into the needs. Remember that these users are experts in the work domain, but probably not in the domains of interaction design or software development, so protect them from technical jargon.

5.3.16 Resolve Organizational, Sociological, and Personal Issues with the Customer
When you take your requirements to the customer for validation, it is also a good opportunity to resolve organizational, social, and personal issues. Because your requirements reflect what you intend to put into the design, if heeded, they can flash early warning signs to customers and users about issues of which your team



may be unaware, even after thorough contextual inquiry. Especially if your requirements are pointing toward a design that changes the work environment, the way work is done, or the job descriptions of workers, your requirements may give rise to issues of territoriality, fear, and control.
  Changes in the workflow may challenge established responsibilities and authorities. There may also be legal requirements or platform constraints for doing things in a certain way, a way you cannot change, regardless of your arguments for efficiency or better user experience. Organizational, social, and personal issues can catch your team by surprise because
they may well be thinking mostly about technical aspects and design at this point.


5.4 ABRIDGED METHODS FOR REQUIREMENTS EXTRACTION
5.4.1 Use the WAAD Directly as a Requirements Representation
To save time and cost, the WAAD itself can be taken as a set of implicit requirements, without formally extracting them. On the WAAD you created in contextual analysis, highlight (e.g., using a marker pen) all groups or individual work activity notes that imply requirements and design ideas directly or indirectly. The way a WAAD note can represent a requirement is: you must cover, include, or accommodate (in the interaction design) the issue, idea, or concept expressed in the note.
  To use the Ticket Kiosk System example of customer security and privacy again, the work activity note says, "I am concerned about the security and privacy of my transactions." Instead of rewriting this as a formal requirement statement in a requirements document as we did previously, you just interpret it directly as you read it to "shall protect security and privacy of ticket-buyer transactions."
  This requirement may immediately generate ideas about how to solve the problem in the design, such as by automatic timeout and and/or a limited viewing angle on the physical kiosk. You should also document these design ideas immediately, while you can, as notes directly on the WAAD.
  You will acquire the ability to look at the WAAD with an interpretative eye and see the work activity notes as more explicit requirements. Clear and crisply written work activity notes will help make this mental step of interpretation easier.



5.4.2 Anticipating Needs and Requirements in Contextual Analysis
In anticipation of the need to extract requirements here, we can introduce a shortcut in contextual analysis, adjusting the process for work activity note synthesis and saving some cost. The shortcut involves doing some interpretation of the raw data, on the fly, to move it more rapidly to reflect requirements.
  For example, consider a work activity note from the MUTTS interviews that says: "After the lottery results for an MU football game are out, students who won try to exchange tickets with others so they and their friends can sit together." From this, you can move more rapidly toward needs and requirements by restating it as: "Some MU football ticket lottery winners need an ability to go to a kiosk and trade tickets with other winners so they can sit with their friends."

5.4.3 Use Work Activity Notes as Requirements (Eliminate the WAAD Completely)
Another efficient abridgement technique, for experienced practitioners, is eliminating the WAAD altogether and using the bins of sorted work activity notes as requirements. Building a WAAD is about organizing large amounts of data to identify underlying themes and relationships.
  If your contextual inquiry did not result in a huge number of work activity notes (a likely case in an abridged approach), you can identify relationships by just manipulating the work activity notes themselves. But you still have to make the mental step of interpretation to deduce requirements on the fly.

Intentionally left as blank


Constructing Design- Informing Models






6.1 INTRODUCTION
6.1.1 You Are Here
We begin each process chapter in the book with a "you are here" picture of the chapter topic in the context of the overall Wheel lifecycle template; see Figure 6-1. We have now made it across the first of two spans of the bridge between contextual analysis and design. We have extracted requirements and are now on our way to constructing some design-informing models.


6.2 DESIGN-INFORMING MODELS: SECOND SPAN OF THE BRIDGE
In crossing the second span of our bridge on the way to design (Figure 5-2), we take what we learned in contextual analysis and build "design-informing models," evolving work products that we can use to bridge the rest of the gap toward design. Just as we did in the previous chapter for requirements




Figure 6-1
You are here; the chapter on constructing design- informing models, within understanding user work and needs in the context of the overall Wheel lifecycle template.






extraction,  in this chapter we introduce another kind of deductive data 
 extraction: from the work activity affinity diagram (WAAD) or your bins of sorted work activity notes and other contextual data to these design-informing models.
  We wish to acknowledge upfront the ample influence of Holtzblatt and colleagues (Beyer & Holtzblatt, 1998; Holtzblatt, Wendell, & Wood, 2005), who have led the way in bringing ethnographic studies of work practice into the human-computer interaction context, in this chapter. In their book, Contextual Design (Beyer & Holtzblatt, 1998), Beyer and Holtzblatt use five models: flow, physical, artifact, sequence, and cultural.
  In the book Rapid Contextual Design (Holtzblatt, Wendell, & Wood, 2005), the authors use mainly the physical, sequential, and artifact models. We have built on their work here, adapting and modifying it for our own needs. We also feature flow, artifact, and physical models. Their cultural model has been adapted to form our social model, and we have expanded their sequence model into a number of different task models.
  We also acknowledge the influence of Constantine and Lockwood (1999). Much of our model-driven approach is based loosely on their "use what you know" technique.



6.2.1 What Are Design-Informing Models and How Are They Used?
Design-informing models are not building blocks that appear directly in a design but are artifacts that embody, drive, inform, and inspire the design. They are design-oriented constructs, such as task descriptions or user personas, that turn raw data into actionable items as design ideas, as elements to consider or take into account in the design.
Like WAADs and requirements, design-informing models:

� help integrate and summarize the contextual data
� point back to the data, to maintain the "chain of custody" to ensure that the design is based on real contextual data
� provide a shared focus for analysis now and, later, design
� provide intermediate deliverables, which can be important to your working relationship with the customer

6.2.2 Envisioned Design-Informing Models
Even though this chapter is about modeling existing work practice, the purpose of the models is to inform design. So, as we get closer to design in Chapters 7, 8, and 9, we need to make a transition with our models from existing to envisioned work practice. To this end, after we construct each kind of model, we also look at the envisioned version of that model for the new design.
 Use these models as springboards to your design scenarios, sketches, and 
 storyboarding. Using the flow model and physical model as guides, look for 
 ways to make flows more efficient and to avoid redundant data entry and 
 unnecessary physical motions. From the task interaction models, try to 
 reduce and automate steps. 
  Using the social model as a guide, find ways to increase communication, reinforce positive values, address concerns of people in work roles, and accommodate influences. One important way to use each kind of model
to inform design is to look at all the barriers identified in the models and solve the problems they represent.
  When the new work practice and supporting system are quite different from the existing ones, the transition from modeling to design begins with a transition from the models of existing work practice by envisioning how each model will make the transition to the new work practice and supporting design.
Each model directly informs its envisioned counterpart. Envisioned
design-informing models are a step closer toward design from analysis. Most of



the envisioned design-informing models can be very brief, addressing only the differences from the existing models.
  In cases where the new work practice and new system are only incrementally improved versions of the old work practice and system, envisioned
design-informing models are probably of little value and usually can be skipped.

6.3 SOME GENERAL "HOW TO" SUGGESTIONS
6.3.1 Maintain Connections to Your Data
It is important to label everything you put in a model with an identifier tag that points directly back to the place in the raw data that was the source of this item in the model. This tag can be the line number in the raw data transcript, a time code in a recording, or a note number in your manually recorded notes. It can also be a node-ID in your WAAD, which indirectly takes you to raw data source tags. This tagging allows your analysis team to get back to the raw data immediately to resolve questions, disagreements, or interpretations of the data. If any element of a model has no pointer back to the data, it must then be considered an unsupported assumption and is subject to additional scrutiny.
6.3.2 Extract Inputs to Design-Informing Models
The business of extracting inputs for design-informing models is not the "next step" after requirements extraction, but you do this in conjunction with requirements extraction. We discuss it separately here for clarity, but usually you would not want to take the time and energy to make another pass through the contextual data at this point. As you "walk the wall" and traverse the WAAD for extracting requirements, take notes on design-informing models, too.
  References to design-informing models just come out naturally; you'll see references to task descriptions, references to user types, references to social concerns, and so on. In WAAD notes and other contextual data, references to design-informing models will often be indirect or implied and sometimes oblique. These work activity notes will seldom be complete descriptions of any component of a design-informing model, but will be hints and clues and pieces of the puzzle that you, the detective, will assemble as you compile each model deductively.

6.3.3 Use Your "Bins" of Sorted Work Activity Notes from Contextual Inquiry and Contextual Analysis
It is hoped, as a result of anticipating in contextual analysis your current needs for modeling, that you will have separate work activity note bins sorted out for each kind of model. For example, you might have bins of user-related notes for



user class definitions and personas. Separate your task-related work activity notes into sub-bins for hierarchical task inventory (HTI), task sequences, scenarios, and so on.
  These ordered and structured bins of notes for each resulting model type provide the inputs to drive your synthesis of the corresponding design-informing models. The user models bin will contain notes revealing
major work roles. The social models bin might contain notes (perhaps through a user concern) about how people in those roles relate. Similarly, the flow model bin may contain notes about and inputs to workflow-related descriptions. Task-related work activity notes in your task model bin are obvious sources of inputs to task descriptions for task modeling, storyboarding, and scenarios.

 Example: Bins of Inputs to Design-Informing 
 Models from MUTTS 
Here are a few examples of items found in the personas bin and the task descriptions bin, as inputs to corresponding design-informing models.
References in square brackets at the end of each input item are tags, tracing the input item back to the data. In this case, the combination of letters and numbers reflects a node within the hierarchical structure of a WAAD.

� Personas
� I usually work long hours in the lab, on the other side of campus [from BA1-4]
� I like classical music concerts, especially from local artists [from CE3-4]
� I love the sense of community in Middleburg [from BC2-1]
� Task descriptions
� Sometimes I need to buy a set of tickets with adjacent seating [from EB5-6]
� After the lottery results for an MU football game are out, students who won try to exchange tickets with others so that they and their friends can sit together [from EA3-14]

6.3.4 Represent Barriers to Work Practice
In most of the models you will want to represent problems that interfere with normal operations of the users. These barriers to usage are of special interest because they point out where users have difficulties in the work practice. These barriers also represent key opportunities for improvement in the design.
  Barriers include what Beyer and Holtzblatt call "breakdowns," but are a bit more general. Anything that impedes user activities, interrupts workflow or



communications, or interferes with the performance of work responsibilities is a barrier to the work practice. Any time you observe users having difficulties at various steps in their work or experiencing confusion or awkwardness in the work role or task performance, even if it does not cause a full breakdown, is a candidate for being labeled as a barrier.
  Especially in the flow model, barriers can include problems with coordination, slips of communication, forgetting to do things, getting the timing of steps wrong, failure to pass along needed information, and
so on.  We will use the Beyer and Holtzblatt symbology of a graphical 

 design-informing models. 


6.4 A NEW EXAMPLE DOMAIN: SLIDESHOW PRESENTATIONS
In addition to our running MUTTS and Ticket Kiosk System example, in this chapter we will use examples from a contextual inquiry study of slideshow presentations performed at Carnegie Mellon University (Cross, Warmack, & Myers, 1999) to illustrate some of the models in this chapter. Many thanks to Brad Myers for permission to use it here.
  These examples about slideshow presentations were chosen because the domain is easy to understand, the models are relatively straightforward, and the models are supported with real contextual data. A small group of user researchers analyzed a set of pre-existing videotapes of nine academic presentations representing a variety of subject matter, audience sizes, audience location (some local and remote, some local only), presentation styles, and audience reaction styles (listen-only, questions, criticism). The objective of the study was to find design improvements to the slide presentation process, possibly through a technology solution.
  This example illustrates a creative adaptation of contextual inquiry to make use of available video data, unbiased data because it was not taken with contextual inquiry in mind but just to create a record of the presentations.
Although the existing videotapes allowed observation of work as it occurs in its own context, they did not permit interaction with users and questioning of users during the observations. Nonetheless, their adaptation of the contextual inquiry method did yield observational data, which did lead to some design-informing models; we use them here as real-world examples.





6.5 USER MODELS
User models are a set of models that define who the users are, including everything about work roles, sub-roles, user class definitions, and personas. Perhaps the most important of the design-informing models are the user models of this section and the usage models of the next.

6.5.1 Work Roles
A work role corresponds to the duties, functions, and work activities of a person with a certain job title or job responsibility. For Constantine and Lockwood (1999), a role is a set of responsibilities assumed by a human within an activity in relation to a focal system. In other words, work roles are "hats" that people wear when they take on the corresponding job responsibilities and perform the associated activities.
  As an integral part of contextual analysis, we got an early start at identifying work roles (Chapter 4). Now, in this section, we follow up on this step as part of the modeling.
A work role can involve:

� System usage or not (meaning the person in the role may or may not be a direct user)
� Internal or external to the organization, as long as the job entails participation in the work practice of the organization
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.

 Example: Work Roles and Sub-roles for MUTTS 
MUTTS work roles include:

� ticket buyer, with further sub-roles as described later, who interacts with the ticket seller to learn about event information and buy event tickets [from AA-3-6]
� ticket seller, who serves ticket buyers and uses the system to find and buy tickets on behalf of ticket buyers [from AL-11-16]
� event manager, who negotiates with event promoters about event information and tickets to be sold by the MUTTS ticket office [from AF-7-13]
� advertising manager, who negotiates advertising to be featured via MUTTS [from AB-5-18]
� maintenance technician, who maintains the MUTTS ticket office computers, Website, ticket printers, and network connections [from AC-3-10]
� database administrator, who tends the reliability and data integrity of the database [from AG-2-17]
� financial administrator, who is responsible for financial and accounting-related affairs [from AH-1-6]
� administrative supervisor, who oversees the entire MU services department [from AE-6-6]
� office manager, who is in charge of the daily MUTTS operation [from AF-2-15]
� assistant office manager, who assists the office manager [from AC-1-8]

  We also identified sub-roles for the ticket-buyer role: student, general public, faculty/staff, alumni, seniors, and children. People in the ticket-buyer role for MUTTS are associated with the main goal of ticket buying. However, a student of Middleburg University, in what we might call the MU-student sub-role, is




associated predominantly with the goal of picking up athletic tickets reserved for students.
  In contrast, nonstudent sports fans want to buy more publicly available sporting tickets. Similarly, town residents and Middleburg visitors, who may be more interested in buying concert and other event tickets, can comprise two other sub-roles. Finally, ticket buyers in the MU-alumni sub-role are buyers of tickets for university-hosted alumni events.
  The administrative supervisor has overall responsibility for daily operations, success of the program, and planning for the future. Because she is charged with responsibility for more than one such program, she is definitely not involved in the daily operation.
  There are also some work roles external to MUTTS, but who interact with people in MUTTS work roles, including:

� event promoters, who interact with the event manager to book events
� venue managers, who interact with the event manager to establish seat selection charts
� advertisers, who interact with the advertising manager to book advertising


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.



Example: Envisioned New Work Roles for Ticket Kiosk System
The major difference between the new Ticket Kiosk System and the old MUTTS is that public kiosks are being used instead of a computer in the ticket office to find and sell tickets. With ticket kiosks come changes in work roles.
  In the most significant role transformation, the ticket-seller role disappears and the ticket-buyer role becomes a direct user through the kiosk, now becoming what is perhaps the central role in the design. The ticket-buyer role includes all people who use the kiosk in a public manner, for example, for buying tickets and/or looking for information. The same sub-roles and user classes generally still apply.

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.







Figure 6-2
 Concepts defining and 
 related to work roles. 



6.5.2 User Classes
A user class is defined by a description of the relevant characteristics of people who might take on a particular work role. Every work role will have at least one accompanying description of potential user community who can perform that role. Sometimes a work role can have such a broad user population that it requires more than one user class definition to describe all the different kinds of people who can assume that role.
  User class definitions document the general characteristics of these groups of people who can take on a given role in terms of such characteristics as demographics, skills, knowledge, and special needs. Some specialized user classes, such as "soccer mom," "yuppie," "metrosexual," or "elderly citizen," may be dictated by marketing (Frank, 2006).
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.
























Figure 6-3
Relationships among work roles, sub-roles, and user class characteristics.

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.


of the book Web Usability: A User-Centered Design Approach, editor of the book Universal Usability: Designing Computer Interfaces for Diverse User Populations, and coauthor of the book Research Methods in Human-Computer Interaction.
I first became fascinated with this research question when the World Wide Web Consortium, and their
Web Accessibility Initiative, came out with the Web Content Accessibility Guidelines (WCAG) version 1.0 in May 1999, which provide guidance to developers on how to design Web pages that are accessible to people with motor and perceptual impairments. People with impairments often use alternative input or output devices, for instance, people with motor impairments (such as limited use of hands) may not use a pointing device or may use an alternative keyboard or speech recognition for input. People with visual impairment may use a screen reader (such as JAWS, Window-Eyes, or VoiceOver), which provides computer-synthesized speech output of what appears on the screen, as well as back-end textual equivalents and labels in the code. To make a Website accessible does not mean changing the visual appearance. Web accessibility means to make sure that the Web page uses appropriate coding standards, such as making sure that all graphics and forms have meaningful text labels (such as name, address, rather than form1, form2), making sure that links make sense when heard out of context ("information about the history of Wal-Mart" rather than "click here"), making sure that any scripts,
applets, or plug-ins have accessible equivalent content, and captioning and/or transcripts for any multimedia. And, of course, a Website is a living, breathing entity that changes on a daily basis. A Website that was accessible last week may be inaccessible this week, and accessible again next week. Accessibility must be maintained and monitored through organizational processes. A very common approach for this is for companies and government agencies to run a monthly report using automated accessibility tools (such as Deque WorldSpace or SSB Bart InFocus). While usability testing, involving users with disabilities, is the best way to evaluate Websites,
automated accessibility testing (using some of the tools described previously) is used commonly for ongoing evaluation.
  The WCAG 1.0 guidelines influenced laws around the world that were created that require that government information on the Web be accessible. Most laws are based on WCAG 1.0 or are strongly influenced by it. For instance, the Section 508 regulations in the United States, in subsection 1194.22 (the section addressing Websites), specifically notes that paragraphs a-k were based on WCAG 1.0. The Section 508 guidelines (which apply to both Websites and many other forms of technology) have been legally, in effect, since June 2001. However, there has been a gap between existing law and actual compliance. Most U.S. federal Websites are not currently accessible, and the Justice Department, which is in charge of reporting on Section 508 compliance to the U.S. Congress and the president every 2 years, has not done so since 2003. A July 2010 memo from the CIO of the U.S. federal government states that compliance activities will begin again soon. The Canadian national government has not fared any better. In November 2010, a Canadian federal court ruled that the Canadian national government has not followed their own laws related to Web accessibility and has set a 15-month deadline for the Canadian federal government to bring their Websites into compliance with the accessibility law.
  Not only is accessibility policy changing, but the accessibility guidelines themselves are changing as well. In December 2008, version 2.0 of the WCAG was approved. Governments around the world are working on updating their regulations to match more closely with the new WCAG 2.0. In the United States, the Section 508 regulations have already been under review, and a new draft of Section 508 regulations (which is still waiting final approval) was released in March 2010.






  Accessibility is not just important for government Websites, but also for Websites of companies, transportation providers, education, and nonprofit organizations. When Websites are inaccessible, it can lead to unemployment, discriminatory pricing, and lack of access to education. For instance, in one study from my research group, we determined that when Websites of airlines are not accessible, the airfares quoted to people who are calling the airlines on the phone are often higher, despite the callers noting that they have a disability and the law requires that they receive the same fares (and that they cannot be charged the call center fee). In November 2010, Pennsylvania State University was sued by the National Federation of the Blind, who claimed that the course management software, the department Websites, and even the online library catalog were inaccessible, prohibiting access to education. eBay has recently made their Website accessible, providing more employment and revenue opportunities for people with impairment. Currently, the U.S. Justice Department is working toward clarifying the Americans with Disabilities Act so that Websites of public accommodations (such as state government, education, and stores) would be addressed more clearly in the law.
  I urge everyone to learn more about Web accessibility. Some great suggestions: start by trying to navigate a Website using only a keyboard, without using a pointing device. Then either download a free demo version of the screen reader JAWS (http://www.freedomscientific.com/jaws-hq.asp) or use a free Web-based screen reader such as WebAnywhere (http://webanywhere.cs.washington.edu). Read up on the Web Content Accessibility Guidelines (http:// www.w3.org/TR/WCAG20) and check in to see what is currently happening in the public policy area related to Web accessibility. Web accessibility is a goal that can be achieved. As usability engineers, we play an important role in making this happen.
Suggested reading
Ebay. (2010). EBay for users with special needs access. Downloaded fromhttp://pages.ebay.com/help/account/ accessibility.html.
Lazar, J., Jaeger, P., & Adams, A., et al. (2010). Up in the air: Are airlines following the new DOT rules on equal pricing for people with disabilities when websites are inaccessible? Government Information Quarterly, 27(4), 329-336.
Loriggio, P. (2010). Court Orders Ottawa to Make Websites Accessible to the Blind. Downloaded fromhttp://www. theglobeandmail.com/news/national/ontario/court-orders-ottawa-to-make-websites-accessible-to-blind/ article1817535/?cmpid=rss1.
Parry, M. (2010). Penn State Accused of Discriminating Against Blind Students. Downloaded fromhttp://chronicle.com/ blogs/wiredcampus/penn-state-accused-of-discriminating-against-blind-students/28154.
Web Accessibility Initiative. (2010). Web Content Accessibility Guidelines 2.0. Downloaded from http://www.w3.org/TR/ WCAG20/.

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:

� novice or first-time user: may know application domain but not specifics of the application




� intermittent user: uses several systems from time to time; knows application domain but not details of different applications
� experienced user: "power" user, uses application frequently and knows both application and task domain very well


  Example:  User  Class  Definitions  for  MUTTS   Even though the ticket-seller role will be eliminated in the Ticket Kiosk System, it is instructive to look at user classes for the ticket seller work role for MUTTS. What characteristics are needed for this role? What training, background, or experience is required? Minimum requirements include point-and-click computer skills with typical Windows-based applications. Probably some simple training is called for. They had a manual explaining the job responsibilities, but over time it has become lost [from CJ2-17].
  Because ticket sellers are often hired as part-time student employees, there can be considerable turnover with time. So, as a practical matter, much of the ticket seller training is picked up as on-the-job training or while
"apprenticing" with someone more experienced in the role, with some mistakes occurring along the way [from DF1-9]. This variability of competence in the work role, which is the main interface with the public, is not always the best for customer satisfaction, but there does not seem to be a way around that [from HA2-12].
  Other roles, such as the event manager or advertising manager, require some specific training because the work involves some complexity and must be done consistently from one client to another. The event manager must have knowledge and experience with the general domain of entertainment, events, and ticket selling. The advertising manager must have a certain level of
knowledge and experience with promotions, sales, and the advertising aspects of business.
  As we move from MUTTS to the Ticket Kiosk System, we will see user class definitions that relate more directly to kiosk usage. For example, you might be expected to include inexperienced (first-time) users from the general public, as well as senior citizens with limited motor skills and some visual impairment.
Because the database administrator role includes tasks that involve technical issues, such as database structures and data integrity, a user class appropriate for the database administrator role would include requirements for professional training in database management functions. Finally, an additional work role, maintenance technician, is also introduced to maintain the kiosks. More new work roles will arise as they are encountered during the creation of the envisioned flow model and the envisioned social models.



6.5.3 Social Models
Work does not happen in a vacuum; it occurs within a social setting, in the broadest sense. The social model is a design-informing model that captures the 
 communal aspects of the users' organizational workplace, including the overall 
 flavor, philosophy, ambiance, and environmental factors.
  The social model highlights what is important to the organization. It characterizes the norms of behavior, influences, attitudes, and pressures that affect users within the work and usage context. Social models are about thought processes, mind-sets, policies, feelings, attitudes, and terminology that occur in the work environment. They include the concerns and influences of Beyer and Holtzblatt's cultural model. They include social ambiance and the social milieu, which define explicit or implicit social interaction in the workplace.
  We call it a social model because it is mainly about the feelings, issues, and concerns of people in the workplace and the forces that influence those feelings and concerns, which often have a significant influence on how people approach and do their work.
  Other factors involved include position or influence within the political structure of the organization, user goals, job-related factors, for example, job description, location, and level of responsibility, motivational factors, and attitudes toward the system such as "I hate this system because it will add to my work."
  The social model contains nodes connected with arcs. Nodes represent active roles and arcs represent social relationships, such as influence by role on another. We describe how to create a social model diagram in the following sections.
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.


















Figure 6-4
Depiction of entities in the slideshow presentation social model. Thanks to Brad Myers, Carnegie Mellon University, and
his colleagues for their case study (Cross, Warmack, & Myers, 1999) on which this example is based.

 Example: Entities in the Slideshow Presentation Social Model  In Figure 6-4 we show the beginnings of a social model. We start by identifying the entities. In the social models for the cases studied in contextual inquiry for the Slideshow Commander, there were two main roles: one or more people in the presenter role and a group called the audience. In turn, the audience was sometimes composed of subgroups, local audience and remote audience(s).
  To represent these entities as nodes in our diagram of Figure 6-4, we have drawn a circle labeled "Presenter" on the left and a large circle for "Audience" on the right. Two smaller circles inside the main audience circle are labeled for the subgroups "Local Audience" and "Remote Audience." We also added "Ambiance" as a nonhuman entity.
  Each presentation potentially included one or more other subsidiary roles in the social model (not shown in Figure 6-4 for the sake of readability), including technical support, the host (to welcome the audience and introduce the speaker), advisory committees (in the case of student presentations), and members of the presenter's immediate research team. All of the people filling







these roles worked toward making the communication between presenter and audience as smooth and as informative as possible.

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.

 Example: Concerns in the Slideshow Presentation 
 Social Model 
In Figure 6-5 we have added the concerns of several roles of Figure 6-4. Because a member of the local audience was selected to set up the software and equipment for the presentation, we added "Selected Member" as a subgroup of "Local Audience." Note the feelings and concerns of the presenter and those of the audiences.









Figure 6-5
Depiction of concerns in the slideshow presentation social model.

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.
 Example: Arcs Representing Influences in the Slideshow 
 Presentation Social Model 
In Figure 6-6, we have added arcs representing some selected influences in the slideshow presentation social model. Note that arrows to and from the outer "Audience" circle correspond to influences common to both kinds of audience.

Figure 6-6
Depiction of influences in the slideshow presentation social model.




Arrows to or from an inner circle, such as the "Local Audience" circle, represent influences pertinent to that type of audience only.
  In their studies, the team noted the mostly obvious observation that some stress due to speaking before a group in public is common to most people. So, we represent this influence of the general stress of public speaking on the presenter from the situational ambiance.
  The team noted that some presenters not used to public speaking, in reaction to this influence, will display a nervous demeanor to the local audience, talking too fast and sometimes mumbling. You can see this presenter behavior represented as an influence on the local audience in the lower left-hand portion of the diagram in Figure 6-6, with the added reaction by the audience in the form of reminders to slow down, speak up, and enunciate.
  Other barriers represented as influences include communication barriers between the presenter and remote audiences, as noted in the studies. In Figure 6-6, for example, we show the fact that the remote audience often cannot hear the presenter as a barrier, with a red lightning bolt, to the "influence" labeled "Tell me what you're doing."
  Similarly, another red lightning bolt shows that the presenter cannot always hear questions from remote audiences. As an example of another barrier, when source material references were given verbally, they could not be remembered by audience members; this caused a barrier to pursuing the topic further after the talk.
  Limited space in this one small figure precludes completeness, but you can imagine other influences. For example, the presenter desires feedback, support, and interesting questions from the audience. The audience desires clear and organized information. The presenter wants to impress everyone and wants to stimulate interesting discussion and help the audience understand the material. The audience wants clear and complete information.
  An additional influence related to work domain constraints might arise with hierarchical audiences, as opposed to peers only. Their studies found a strong element of influence (again, not shown in Figure 6-6, for
simplicity) due to the presence of faculty and thesis supervisors at a student presentation.
  Because it is their job to do so, this kind of audience often exhibited a more critical tone and a more "demanding" (of explanations and rationale) and stressful ambiance for the presenter as compared to the more collaborative, sharing, and supportive ambiance of peer audiences that usually offered suggestions in a two-way exchange.



 Example: A Social Model for MUTTS 
In the example social model for MUTTS shown in Figure 6-7, we present selected parts of what is an even larger model. Starting with the roles, we identify the ticket seller and ticket buyer as the main ones, represented as two nearby circles near the top. Almost always you will want to include the ambiance and work domain as nonhuman entities.
  The administrative supervisor, database administrator, and office manager are shown, and a full representation of the model would also show all other roles that appear in the upcoming flow model, such as the event manager, the advertising manager, and the financial administrator.
  The diagram shows a few examples of concerns, including mutual concerns between the ticket buyer and the ticket seller about possible negative consequences of going to a kiosk-based system. The administrative
supervisor is also shown as concerned about insufficient revenues from	Figure 6-7
Example social model for MUTTS.





tickets alone. Note for clarity of narrative reading that we have omitted tags to the data sources.
  The bulk of the diagram is devoted to influences. For example, the ticket seller wants to please ticket buyers and especially wants to avoid complaints from ticket buyers, complaints that could have a negative effect on the
ticket seller's job reviews. You can also see pressure, when the ticket window is busy, from other ticket buyers in line for the current ticket buyer to hurry up and not delay the rest of them.
  The ambiance exerts certain pressures on ticket buyers, too, because the environment is public and can be noisy, distracting the ticket buyer and impeding the ability to make event choices, seating choices, and other decisions needed to buy tickets.
  The database administrator works in a relatively quiet office but could be faced with daily pressure to maintain data integrity and to keep the systems up and running continuously. Because of sharing a fairly small office with the event manager, whose phone is ringing constantly, the database administrator can, at times, find it hard to concentrate. When faced with the pressure of things going wrong with the computer, the ringing phone and constant chatter on the phone can become enormously irritating.
  Problems with Tickets4ever.com are a negative influence on all internal work roles. There is concern that the poor quality usage experience users get on Tickets4ever.com will cast a shadow on MUTTS's reputation for reliability and service. Because ticket buyers do not necessarily make the distinction between Tickets4ever.com and MUTTS, they can all be painted with the same brush. For big concerts, a large online demand can sometimes overwhelm the Tickets4ever.com server and it goes down. If a transaction fails for any reason and the order does not go through and the ticket buyer starts over, he or she can sometimes get charged twice. If he or she does not start over, sometimes the order does not go through and the ticket buyer fails to get the expected tickets.
  The administrative supervisor has influence on all the internal work roles, out of proportion to her real role in the work practice. Because she is not involved directly in the day-to-day operations, employees perceive her as unfamiliar with the work practice and therefore unrealistic in her expectations for performance. The staff then feels obligated to explain
when the expectations are not met. And, when the workers have questions, it is hard for them to get answers from her.



  To make things worse, the administrative supervisor tends to show up occasionally, causing stress for everyone. So she has an impact on people in other work roles and makes all their jobs harder, producing more
on-the-job stress.
  As another example of her influence, because the administrative supervisor's concerns that the enterprise is not generating enough revenue on contracts, ticket sales, and advertising, she has aspirations to increase total revenues by selling many items in addition to tickets, including over-the- counter commodities such as candy, gum, and aspirin, plus merchandise souvenirs, T-shirts, hats, and banners. But the people currently in other work roles are resisting this kind of change, saying that these merchandising activities will distract their focus on actual ticket operations. Plus their main sales software, Event Pro, is not set up for event-independent merchandise sales.
  An example of work domain influence on both ticket buyers and ticket sellers is seen in the organizational policy not to give refunds for tickets. Tickets can be exchanged, but for a $3 fee. This policy causes a public relations problem because the staff has to deal with and console disappointed ticket buyers.
  Another influence from the work domain, this one on the office manager, stems from the fact that MUTTS uses up to three ticket sellers to operate their three ticket stations. They often have just one ticket seller but in periods of high demand they need to hire additional ticket sellers quickly, which they later lay off. However, university hiring policies make it difficult to hire and fire temporary ticket sellers on a timely basis to match workload demands.
  Ticket buyers exert various influences on the ticket seller. For example, many repeat customers want a "small-town" relationship with the ticket seller. They want them to remember the ticket buyer by name and, in some cases, provide recommendations based on what the ticket buyer likes.
  Among the influences from the work domain is pressure on the ticket buyer to buy tickets for popular events before all the good seats are gone. For season tickets, it is especially important to get good seats because you will have the same seats for the whole season.
  As an example of influence of the work domain on all roles, when the workload is high, over-the-counter sales get hectic and there is pressure on everyone to get things right. Errors and problems will upset ticket buyers.
  Finally, through contextual inquiry interviews, we discovered an influence on all work roles that can be traced indirectly to the administrative supervisor. In some cases there is a lack of a clear division of roles and responsibilities,



making it uncertain who is authorized to do what and who is not. This influence can lead to hand tying and, because of it, sometimes things do not get done.

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.

Example: An Envisioned Social Model for the Ticket Kiosk System
As we introduce the concept of ticket kiosks all around town, new roles, concerns, and influences arise in the social model. Venue managers may see the potential for greatly increased ticket sales but may wonder if they can handle the additional logistics. Advertisers might be thinking about how they can monitor the effects of the additional advertising. How can they determine
if their kiosk ads are cost-effective?
  The working environment for the ticket buyer now will be quite different. Instead of standing at the ticket office window, the ticket buyer will be at a kiosk in a public place that could be noisy and distracting. Also, now that the ticket seller is replaced with a kiosk, the ticket buyer interacts with a machine instead of a human; the issue of trust may become more important.
  The ticket buyer will still need to communicate with friends and other individuals to discuss event information-only now the ticket buyer is at the kiosk. A cellphone would still work, but also maybe this need to communicate might inspire designers to consider a possible future feature requirement
for including a way to send event information from the kiosk, via the Internet, to email addresses. This need for outside communication could also show
up in the flow model.
  Another example of a concern is that of a customer who uses the kiosk located at a bus stop: "If my bus arrives when I am only partway through a transaction to buy tickets, will I be able to get out quickly and safely and resume later, for



example, after work tomorrow, without losing too much progress in my search for entertainment events?"
  Because many of the kiosks will be placed near bus stops, the Middleburg Bus Authority, although not a direct user of the Ticket Kiosk System, becomes a stakeholder. And this new stakeholder has concerns about whether crowds at the kiosks will interfere with Middleburg Bus operations or introduce a safety hazard to bus riders.
  Also, if the kiosks are actually on Middleburg Bus property, how much income can be expected from leasing the space for the kiosk? Middleburg Bus may also be worried about the added exposure to public liability, whether bus stop lighting is adequate, and will there be any added public safety issues? By the same token, the local police may be concerned about the potential for vandalism and whether a kiosk poses an "attractive nuisance."

6.5.4 User Personas
Technically, personas are a type of user models, but they are tied so closely to design that we discuss them in Chapter 7.

6.6 USAGE MODELS
Usage models are a set of models that define how work gets done, including flow models, task structure models, and task interaction models.

6.6.1 Flow                        Model  Different authors place different relative values on different kinds of models, but we believe that if you had to pick the single most valuable design-informing model, the flow model is it.  The flow model is a picture of existing work 
 processes in the work domain being analyzed for a new design.1
 The flow model is like a plan view in architecture-it shows a bird's-eye view of 
 the entire workflow of the enterprise humming along below. It should show 
 territorial boundaries, especially the separation between enterprise and non- 
 enterprise work roles.
  Initial sketches of the enterprise flow model are begun from customer and user data early in contextual inquiry. Now we follow up on the flow model sketches and complete the flow model.


 turn has its roots in the Checkland's Soft Systems Methodology (Checkland & Scholes, 1990), which itself 
 connects to roots common to those of work activity theory, contextual design, and other ethnographic and 
 sociotechnical techniques in system design (Bjerknes, Ehn, & Kyng, 1987). 



  The focus of a flow model is on the issue of with whom and with what do the users in each work role interact. Specify whether the system supports inter-role communication or users must do it on their own, for example, via a shared database or through a telephone conversation. What information is exchanged when entities communicate? Describe the different types of information that are exchanged among work roles and other entities.
  For example, in a financial institution, a loan officer may need to speak with customers over the phone as part of a home loan application. Such details provide valuable insights to designing for their work activities. For instance, in this case, the user interface of the loan officer user class could have an option to dial the customer's primary phone number as and when required at the touch of a button.

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.

Example: A Flow Model for Slideshow Presentations Separate flow models for slideshow presentation cases showed that the flow of information was often interrupted, either briefly or significantly,
for almost 10 minutes during one presentation. The flow in some presentations, particularly ones with remote audiences, was overwhelmed with the need for the speaker and technicians to manipulate multiple electronic devices.
  Barriers to flow were revealed most frequently when information flow to the presenter or the audience was interrupted, such as when extraneous application windows blocked part of the presentation screen or when sound controls were not adjusted properly. In Figure 6-8 we show an example flow model for slideshow presentations. Note the red lightning bolts representing barriers to flow.

Example: A Flow Model for MUTTS
The early sketch of the ticket-buying flow model for MUTTS shown in Figure 4-3 evolved into the diagram shown in Figure 6-9.






 Figure 6-8 
 Example flow model 
 from the slideshow 
 presentation contextual 
 inquiry.  Thanks to Brad Myers, Carnegie Mellon University, and his colleagues for their case study (Cross, Warmack, & Myers, 1999) on which this is based.



  This flow model shows flow of goods, services, and significant internal flow of information, for example, tickets and event information for customer, for running the business of MUTTS. The flow model is also a model of the enterprise organization business process, as it includes information transformations that occur as part of the flow as a component of the work process.
  You may note that some of the important roles in the work process are within the MUTTS enterprise boundary (shown as an oval outline in Figure 6-9) and some are external. Some of the internal roles are, in fact, paired with external (to the MUTTS enterprise) roles in order to accomplish the flow
of work.
  For example, the internal role of event manager pairs up with the external role of the event promoter to carry out the work of booking and entering information for particular events. Note also interactions among roles not involved directly in ticket buying or selling, such as friends and/or family of








ticket buyer in the upper right-hand corner of the diagram, standing there with the ticket buyer or on the cell phone, communicating about choices of events, dates, seats, and prices.
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

 Figure 6-9 
 Flow model of our version of 
 MUTTS.





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.



Example: Envisioned Flow Model for the Ticket Kiosk System The early sketch of the ticket-buying flow model in Figure 4-3 evolved into the diagram shown in Figure 6-9, which captured the viewpoints of the ticket-buying customer of MUTTS and the internal and external work roles required to
run the business.
  This flow model evolved into the envisioned flow model of Figure 6-10, which captures the viewpoints of the ticket-buying customer of the kiosk and some of the roles internal to the kiosk enterprise organization required to run the business, including the marketing manager, the event information manager, the database administrator, the financial administrator, and kiosk maintenance.
This envisioned flow model shows several additional new work roles not
identified previously for the Ticket Kiosk System.	 Figure 6-10 
 Envisioned flow model for 
 the Ticket Kiosk System.




6.6.2 Task Models
 Task models represent what users do or need to do in the work practice and 
 work environment, using system or not. Task models include both task structure and task interaction models. The primary task structure model is the hierarchical task inventory, similar to the idea of hierarchical task analysis.
There are several different task interaction models, each with its own way to represent the interaction.
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.
6.6.3 Task Structure Models-Hierarchical Task Inventory Task structure modeling, such as hierarchical task inventory modeling, is the process of cataloguing the tasks and subtasks that must be supported in the system design. Like functional decompositions,  hierarchical task inventories 
 capture relationships among tasks that need to be supported in a new 
 system design.

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

� to show what user tasks and actions are possible
� to guide overall design
� as a checklist for keeping track of task coverage in your design (Constantine & Lockwood, 1999, p. 99)
� for matching that coverage to your inventory of scenarios and other task representations



  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.

Example: Hierarchical Task Inventory for MUTTS
Starting at the very highest level of tasks for MUTTS, you have the major task sets performed by each of the work roles, such as the financial administrator, the database administrator, the event manager, the advertising manager, and the ticker buyer. Using an "action-object" approach to task naming, these major task sets might be called "manage finances," "manage database," and so on, as shown in Figure 6-13.
  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,



Figure 6-11
Hierarchical relationship of task A, the super-task, and tasks B and C, subtasks.















Figure 6-12
An incorrect hierarchical relationship attempting to show temporal sequencing.














 Figure 6-13 
 Sketch of the top levels of a 
 possible hierarchical task 
 inventory diagram for 
 MUTTS. 




Figure 6-14
Partial HTI for MUTTS "sell tickets" task.

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.

Example: Envisioned Hierarchical Task Inventory for the Ticket Kiosk System
The envisioned HTI diagram for the Ticket Kiosk System is very similar to the HTI diagram of MUTTS. The essential difference is that finding and ticket buying tasks are now done by the ticket buyer instead of the ticket seller, and they are done on a kiosk instead of a computer. New work roles and corresponding tasks will be added for kiosk monitoring and maintenance.

6.6.4 Task Interaction Models
In addition to modeling task structure, and much more important for 
 understanding user work, we must model the interaction part of tasks, steps, and 
 user actions required to perform 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:

� Agents (users, people in work roles, often in personas, system, sensors)
� User goals and intentions
� User background, training, needs, etc.
� Reflections on work practice, including user planning, thoughts, feelings, and reactions to system
� User actions and user interface artifacts
� System responses, feedback
� User tasks, task threads, workflows, including common, representative, mission critical, and error and recovery situations
� Environmental and work context (e.g., phone ringing)
� Barriers, difficulties encountered in usage
� And, of course, a narrative, a story that plays out over time

 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:

� coarse-grained model muddles distinct tasks
� rarely feasible to model entire task domain
� superfluous details distract from essentials
� exceptional, uncommon, or unimportant actions can assume undue prominence in story line
� concreteness does not facilitate innovative thinking


 Example: Usage Scenario for MUTTS 
Here is a fairly detailed usage scenario about a group of students using MUTTS.
  On cellphone and email over a day or two, Priya and a group of her friends plan an evening out together on the coming weekend. They agree to meet at the MUTTS ticket window on Friday afternoon. Some walk to MUTTS, while others take the bus.
  With the work week behind them, the group is in a festive mood, looking for entertainment over the weekend. They decide to check out events for Saturday night. After waiting in line, Priya asks the ticket seller what kinds of events have tickets available for Saturday night. The agent looks through her computer listings of movies, concerts, plays, fairs, carnivals, and special events and tells the group about their options. After talking among themselves, they decide they want to go to a concert. The agent asks, "Which kind, classical or pop?" They choose to go with a pop concert. Again, she tells them their options. They finally decide on a concert playing at The Presidium.
  There is some unease within the group, though, because they feel that the agent did not give them enough information to make the best choice () and they felt some pressure to decide in a hurry (), as the agent was standing there and waiting.
  They ask about what seats are available and the agent goes back to her computer and brings up a graphical seating map of the hall. However, the tickets the agent has on hand are for only a subset of the seats actually available, forcing the group to pick from these, knowing they had not seen all the real




options (). They choose their seats based on price and seat location and the agent requests an option to buy the tickets, locking out others until the transaction is either completed or given up. The group agrees on the purchase and then discusses the matter of paying. They decide to give Priya cash and she will pay on her credit card, so Priya swipes her credit card through the slot on the counter. The transaction is authorized by the credit card company, the sale is committed, and the agent gives them the tickets. The group is happy, but they leave with a nagging feeling that there must be a better way to buy tickets.

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.

 Example: Design Scenario for the Ticket Kiosk System 
A local movie theater, The Bijou, has a standing contract with the Ticket Kiosk System Company, and every time a new movie comes up, all of the information about showings, trailers, and advertising blurbs get sent automatically to the kiosk event manager in the right format so that most of it can be posted automatically.
  Many different local and other advertisers have contacted the marketing manager and sent graphics and text advertising for their products and companies. For example, the Back Country Provisions has a beautiful advertisement about tents, backpacks, hiking boots, and so on. Plus, they have




an agreement to associate their advertisement with any event, for example, a movie about Alaska, that has to do with hiking, camping, or traveling into any kind of wilderness or camping situation.
  On a Friday night, Joe drives his pickup into the parking lot next to a bus stop with a Ticket Kiosk System kiosk. Joe is looking for some entertainment for the evening, something to take his mind off the busy past week. He is thinking about a fun sporting event on this Friday night, maybe basketball game or a hockey game.
  At the "Welcome" screen Joe, touches the button labeled "Sports" from the main menu and looks under the current date. But the ones that are available that night really do not appeal to him, so he starts browsing for other events. He touches the "Main menu" button and returns to the "Welcome" screen.
  Joe is tired after a hard week of work, and he does not think he has the energy to go to a concert, so he thinks he might like to just sit back and see a movie. He touches the "Movies" button and browses casually through some of the movies that are currently showing and sees Into the Wild and gets excited. He has never been to Alaska and he has always wanted to go. In fact, this would be a great movie for him to take a date.
  Joe has been secretly dating a woman named Jane, who lived in Alaska before moving to this area. Joe calls Jane on his cellphone and, although she too would prefer to attend a hockey game, she agrees to meet him at The Bijou.
  While Joe is standing there on the phone in front of the kiosk, he sees an advertisement for Back Country Provisions, which is showing on the far
right-hand side of the screen, as it is automatically associated with this movie. As he looks at it, he imagines himself off in the wilderness, escaping his busy work life. He dreams of himself on this nice trip to Alaska. He makes a note to stop by at Back Country Provisions and see what kinds of hiking boots they have.
  Joe then pays for the tickets with a credit card, and the transaction goes by wire to the financial company. The transaction is approved and the tickets are printed. The printer ink is getting a little low, which triggers a sensor, and a warning is sent to the kiosk maintenance person. Joe is so excited about pulling this all off (the transaction and the date) that he almost forgets to take the tickets from the slot, but he sees the reminder message on the screen that says "Thank you. Do not forget to take your credit card and your tickets."
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 increasedcognitiveloadtokeeptrackofmultipletasks canbeabarriertoeaseofuse.

 Example: Step-by-Step Task Interaction Model for MUTTS  This is an example of a step-by-step task interaction model for the task of ticket buying by the ticket seller work role. People often have something specific in mind when they go to buy tickets but, to illustrate a rich step-by-step interaction model, we are using an example in which the ticket buyer starts by wanting to know what is available.

Task name: Finding entertainment for a given date (performed by ticket seller on behalf of ticket buyer)
Task goal: Helping a ticket buyer choose and buy a ticket for entertainment for this coming Friday night
Task trigger: Ticket buyer arrives at the MUTTS ticket window on the way home from work on a Thursday evening, thinking ahead to the weekend

Step goal: Consider examples of entertainment events





Barrier: Agent sees that the number of results is too large to sort through or tell the customer about
Response to barrier:

Task continues:

: It is difficult to think about specific events while remembering all the others given orally on the list
Response to barrier:

Trigger: Movies seem attractive to ticket buyer
Goal: Find a movie to see


11. Tells agent about switching focus to just movies
12. Tells agent to use the same criterion about being within reasonable walking distance downtown or near a Middleburg bus stop
14. Considers possibilities and finds a few he likes
15. Writes choices down on paper




13. Tells about possibilities


Trigger for interrupt to embedded task: Thinks a friend might also like these movies
N: Needs to know friend's opinion of the selections
Goal: Contact a friend to help narrow these last few choices down and pick something together




Trigger: Choice made, ready to buy two tickets
Goal: To buy tickets


19. Tells agent to buy two tickets to selected movie
20. 
Sets up transaction in computer

21. Cash or credit card?

22. Gives agent credit card	23. Swipes card
24. Signs credit transaction	25. Prints tickets and receipt
26. Gives printed tickets and returns credit card and receipt


  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.

Example: Task Interaction Branching and Looping for MUTTS
In Figure 6-16 we show a sketch of task interaction representation for selling tickets with MUTTS. Note several instances of looping to iterate parts of the task and, in the bottom box, branching to accommodate two different cases.

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,

Figure 6-15
Branching and looping structures within step-by- step task interaction models.











































Figure 6-16 Task interaction
branching and looping for
MUTTS.

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.

Example: Essential Use Case for MUTTS
Table 6-1 contains an example, cast in the same fashion as Constantine and Lockwood (2003). This is a task that the ticket seller does with the computer using the ticket buyer's credit card.
  Your contextual data can indicate focal points for expanding and elaborating task details. As an example, there are some possible alternative cases following step 6, when the system reads the credit card. Perhaps the system could not read the card successfully or maybe there is a problem with the credit or debit account associated with the card-the card has been reported stolen, the account has been cancelled, or payment is overdue.
  While these detailed alternative task paths are important to capture, they are not usually put directly in the task description, as they would interfere with its abstract simplicity. You can create new essential use cases for these ancillary





1. Ticket seller to computer: Express intention to pay




2. Request to insert card

Table 6-1
Example essential use case: Paying for a ticket purchase transaction (with a credit or debit card)

3. Ticket seller or ticket buyer: Insert card	4. Request to remove card quickly

5. Withdraw card	6. Read card information

7. Summarize transaction and cost

8. Request signature (on touch pad)

9. Ticket buyer: Write signature	10. Conclude transaction

11. Issue receipt

12. Take receipt




task threads or you can put the alternate cases and exceptions in a list that goes with the basic task description to remind designers that these special cases have to be dealt with in the 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.

6.6.5 Information Object Model
 Information objects are work domain objects shared by users and the system. 
 As internally stored application objects, information objects are hugely 
 important in the operation and design of a system. These are mainly the entities that move through the workflow in the flow model. These are the entities within an application that are operated on by users; they are searched and browsed for, accessed and displayed, modified and manipulated, and stored back again.
  In action-object task names, such as "add appointment," the object (appointment) is often an information object. They are connected directly to the design ontology that drives the bread and butter of most domain- complex system designs. They show up as objects of user actions in usage scenarios and other task descriptions and drive design questions such as how
will users access the objects and how will we represent them to users in displays, as well as how will users do the operations to manipulate these application objects?
  In a calendar application, for example, appointments will be objects that are created and manipulated by users. As another simple example, suppose a user draws a circle with a graphics-drawing package. Data representing the circle



are stored by the system, the user can call it up and the system will display it, and the user can manipulate and modify it and save it back in the system.
  Most information objects have defining attributes. A calendar appointment has date, time, subject, and so on; a graphical circle has a radius, location, color, and so on. Start the information object model by compiling information objects identified in the contextual data. Sketch an outline or list of information objects, their attributes, and the relationships among them.

Example: Identifying Information Objects and Attributes in MUTTS
The two-word goal of the main task of the ticket seller work roles is "sell tickets." Within this goal, the term "tickets" identifies a principal information object in the system. We know that a ticket is associated with an event, another information object, which in turn is linked to attributes, such as event date, time, venue, and so on. We also know that each event object is associated with descriptive attributes, such as genre, to support customer user searching and browsing.

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.

Example: Scenario Analysis to Help Identify Ontological Elements of the Ticket Kiosk System
We have highlighted (with italics and color) some of the ontological elements of the example scenario for the Ticket Kiosk System given earlier.
  On cellphone and email over a day or two, Priya and a group of her friends agree to take in some entertainment together on the coming weekend. They agree to meet at the Ticket Kiosk System kiosk at the library bus stop at 5:30 PM on Friday. Some walk to the kiosk from nearby, while others avail themselves of the convenience of the bus. The group is in a festive mood, looking forward to sharing some fun over the weekend.




  Priya steps up to the kiosk and sees a "Welcome" screen with an advertisement for a movie scrolling at the top and text that says "What kind of even information would you like to see?," followed by several touchscreen buttons with labels on the left-hand side such as "Browse by event type," "Browse by venue/location," and "Event calendar: Browse by date." On the right-hand side there are buttons for specific types of events, such as "Sports," "Concerts," "Movies," "Special features," etc.
  Because they are looking for something specifically for the next night, she touches the "Event calendar" button, looking for events such as movies, concerts, plays, fairs, or even a carnival for Saturday night. After browsing for a while and talking among themselves, they want to go to a concert. Priya touches the "Concerts" button, and they are presented with the subcategories Rock, Classical, Folk, and Pop. They choose to go with pop concerts and Priya touches that button. From among several choices, they finally decide on a concert called "Saturday Night at the Pops" playing at The Presidium.

� Cellphone and email refer to methods of communicating with family and friends outside the system
� Priya is the name of a person in the customer/user role
� a group of her friends refers to other roles, customers who are probably not direct users
� library bus stop refers to a location of use (of a kiosk), part of the work context
� 5:30 PM on Friday refers to a time of use (a time when the kiosk is open but the old MUTTS would not have been open), also part of the work context
� festive mood, looking forward to sharing some fun over the weekend refers to an emotional state of mind of the users, expressing an expectation to be met by the product, a subtle part of the work context
� "Welcome" screen with an advertisement for a movie scrolling at the top is a design idea for user interface objects
� touchscreen buttons are possible user interface objects
� "Browse by venue/location" is a suggested button label, which also indicates a user task
� looking for something specifically for the next night is a user task
� looking for events such as movies, concerts, plays, fairs, or even a carnival for Saturday night is a combination of user tasks
� "Concerts," Rock, Classical, Folk, and Pop are names of categories of information/ application objects

  And so on. Can you identify others? The idea of identifying these different entities within scenarios is that they help pick out types and instances of




design-informing models and help identify ontological objects and tie them together in the threads of design scenarios in ways that directly inform designing.


6.7 WORK ENVIRONMENT MODELS
 Working environment models are a set of models that define the milieu in which 
 work gets done, including constraints, artifact models, and physical models.
  These models capture how the related work environment factors affect tasks in real usage. Of the work environment models, the physical model is probably the most important. Factors such as the layout of work space, proximity of printers or scanners, and the inability to hold a device with a keyboard while standing up will have a direct impact on UX and work practice.
  In the slideshow presentation example presented earlier, the physical model indicates where people in the different roles will be standing or seated, the presentation room layout, and the ability to control light from windows and to control selectively the artificial lighting in the room.
Sound and other attributes of the space will contribute to the physical model, as do the availability and locations of electrical outlets and Internet connections.

6.7.1 Artifact Model
 An artifact model shows how tangible elements (physical or electronic) are 
 used and structured in the business process flow of doing the work. Work artifacts are one of the most important entities that get passed from one work role to another within the flow model. Examples include paper memos, email messages, correspondence templates, product change orders, and other things people create and use while working. Sometimes artifacts are work products, information objects used in daily operation of the enterprise, for example, an order form being filled out, that reveal traces of people's work practices. The contextual inquiry team must pay close attention to how these artifacts are created, communicated, and used. What are those notes scribbled on those forms? Why are some fields in this form left blank? Why is there a sticky note on this form? Perhaps a signature is required for approval on other kinds of documents. This model is one reason why observers and interviewers must collect as many artifacts as possible during their contextual inquiry field visits to users.





















Figure 6-17
Part of a restaurant flow model with focus on work artifacts derived from the artifact model.

Example: Artifact Model from a Restaurant
It is easy to think of artifacts associated with a restaurant. In Chapter 3 we mentioned collecting artifacts from a restaurant, examples of which are shown in Figure 3-3. The first artifact encountered by a person in the customer work role, delivered by the person in the wait-staff work role, is a menu, used by the customer work role to decide on something to order.
  Other usual restaurant work artifacts include the order form on which the wait-staff person writes the original order and the guest check, which can be the same artifact or a printed check if the order is entered into a system. Finally, there might be a regular receipt and, if a credit card is used, a credit card signature form and a credit card receipt. Artifacts in restaurants, as they do in most enterprises, are the basis for at least part of the flow model. In Figure 6-17 you can see how restaurant artifacts help show the workflow from order to serving to concluding payment.







  The artifacts, especially when arranged as part of a flow model, can help make a connection from contextual data to thinking ahead about design. For example, the waiting and boredom shown in Figure 6-17 pose a "barrier" to the customer.
  This leads us to ask questions such as: How can we make that experience for the customer placing the order more fun, engaging, and informed? This kind of question posed now will later provide a great starting point for design brainstorming later: Would not it be cool if each dining table contained an embedded interactive touch tablet. Users could pass time by playing games, doing email, or surfing the Web.
  Another barrier shown in Figure 6-17 is the difficulty of ordering food from a textual description in a paper menu. Interviewing restaurant customers about their experiences, you find that many people, when they order a dish and then see something else someone has ordered, wish to get that dish instead.
  Paper menus do not leverage this rich human sensual connection to the food! However, this discussion of restaurant artifacts does help us ask questions that will later inspire design: If the table contained an interactive display, then why not let the customer use it to interact with the kitchen, ask questions about ingredients, and see images of the dish being served? In fact, why not let the customers place their orders themselves?

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.



Example: Artifact Model for Slideshow Presentations
The artifact model for slideshow presentations did not turn up anything unexpected, but it is informative. It includes physical devices such as laser pointers for pointing to the screen and a timer or watch for keeping track of time, bottled water for the speaker and/or the audience members, possible paper handouts with copies of the slides, and a PC and mouse. Because the artifacts, especially the various pieces of equipment, are physical, there is some overlap with the physical model.

6.7.2 Physical Model
 The physical model gives the roles, activities, and artifacts of other models 
 a physical setting, showing the physical environment as it supports (or not) 
 the work. The physical model shows physical dimensions of the work spaces, buildings, walls, rooms, workstations, all physical equipment, and collaboration spaces, but does not have to be an exact to-scale floor plan. The physical model includes computing and communications and other work devices, for example, copy machines, telephones, FAX machines, printers, and network connections.
  Because a physical model shows the placement and paths of movement of people and objects within this work space layout diagram, it can be used to assess the proximities of task-related equipment and artifacts and task barriers due to distances, awkward layouts, and physical interference among roles in a shared work space.
  The latter is helped by showing movement lines of each user role within the space, including multiple lines for multiuser movement in doing a collaborative task. If the physical locations or devices associated closely with the same tasks or related tasks are located at a distance from each other, it can result in wasted time and effort for workers.
  For example, in the design for her house, a friend did this kind of physical model and workflow analysis and found that the traditional American proclivity for putting the clothes washer and dryer in the basement gave a very poor proximity-to-task-association ratio for the task of doing laundry. Enlarging the dressing room and putting the washer and dryer in there improved this ratio enormously.
  Similarly, the flow of fresh vegetables from the car to the kitchen led to moving the garage from the basement level to the living floor level (aided by a steep grade). In both cases, the changes brought the physical model elements much closer to their location of use in the design.



  Looking further at the veggie flow in the physical model led to an efficient design of a kitchen island as a shared food preparation and cooking area- cleaning at the veggie sink, flowing over to slicing and dicing, and then flowing to saute�ing under a bright light and a vent hood.
  When creating physical models, also think of all the physical characteristics of a workplace that can affect work activities and add them as annotations. For example, a steel mill floor is about noise, dust, hot temperatures, and safety concerns, making it more difficult to think. A system with a terminal on a factory floor means dirty conditions and no place to hold manuals or blueprints. This may result in designs where the use of audio could be a problem, needing more prominent visual design elements, such as blinking lights.
  Other concerns by people in the physical working environment might include room lighting, air quality and ventilation, room temperature, and how to set all these parameters to suit everyone. Note the red lightning bolts representing barriers to work practice in the physical model.
Example: Physical Model for Slideshow Presentations
The physical model of the presentation room described the arrangement of physical structures that limit or define the work space and usage and movement within the space. These physical models showed the room, equipment and other artifacts used, positioning of the presenter and audience within the environment, and barriers that arose due to limitations of these physical layouts.
  The physical models fell into two cases: presentations that included remote audience members required a different physical arrangement than for local- only presentations. In particular, remote presentations used more devices, including cameras, screens, and sound control boards.
  All presentations, however, used a seated local audience, a standing presenter, and at least one screen that showed the slides to the audience and served as a display for some of the interaction used to control the slideshow.
  Most physical barriers in the social models occurred when the desires of the presenter to give information, and the audience to receive information, were obstructed. For example, the behavior of several presenters indicated a desire to be near the audience physically, but their movement toward and among the audience often blocked the audience's view of the slides on the screen. Also, presentations with multiple presenters had difficulty with transitions between presenters because of physical barriers to handing off the presentation.
  Otherbarrierstosmoothtaskperformanceincludedcordsoverwhichpresenters sometimes trippedand difficult-to-reachcontrols for videos and slideadvancement. In Figure 6-18 we show a physical model for one of the presentation cases.


Figure 6-18
Physical model for one slideshow presentation case. Thanks to Brad Myers, Carnegie Mellon University, and his colleagues for their example (Cross, Warmack, & Myers, 1999) on which this is based.



  As an aside, you might think that this physical model would not be very useful since it is very specific to one presentation room and one work space in one presentation case. Surely other presentation rooms will be quite different in size and layout.
  But it is exactly the point of contextual inquiry: that you can take work practice data from a very specific existing working environment and learn things that apply to the more general case. This team was able to do just that in discovering the problem of presenters having to stay near the computer during the presentation, needing to lean awkwardly across tables to use the PC mouse to change slides. This is a barrier to quality presentations and could be true in most settings, regardless of room layout details.


Example: Physical Model for MUTTS
In Figure 6-19 we show the physical model for MUTTS. The center of workflow is the ticket counter, containing up to three active ticket seller terminals. On the back wall, relative to ticket sellers, are the credit card and MU Passport swiping stations. This central ticket-selling area is flanked with the manager's and assistant manager's administrative offices.
  Barriers not shown in Figure 6-19 include a barrier to the ticket buyer lines: At peak times, customers may have to wait in long lines outside the ticket window.









Figure 6-19
A physical model for MUTTS.







The scanner in the manager's office, used to digitize graphical material such as posters or advertisements for Website content, presents barriers to usage: It is very slow and is not in a convenient location for all to share.
  The ticket printers can also introduce barriers to workflow. Because they are specialized printers for ticket stock, when one goes down or runs out of paper or ink, the employees cannot just substitute another printer. They have to wait until the technician can get it serviced or, worse, until it can be sent out for service.

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.


6.8 BARRIER SUMMARIES
Many of the models tell partial stories from different perspectives, but no one model highlights all the barriers discovered in contextual inquiry and analysis. Yet it is the barriers to work practice and user performance that most directly inform design ideas for the new system. So it can be helpful and informative to
 extract barrier-related information from the models and summarize the barriers 
 in one place.

Example: Barrier Summaries for the Slideshow Presentation System
The team that did the slideshow presentation contextual inquiry summarized some selected barriers found in their step-by-step task interaction model as follows, in Table 6-2.
  Further, in Table 6-3 the team summarized the most frequently encountered barriers. The "% of talks" column is the percentage of presentations in which the barrier occurred at least once. "Count" is the total number of instances of the barrier observed across all presentation cases. "Severity" is the average severity rating across all instances of the barriers. "Average duration" is the average length of time of a single instance of the interruption due to the barrier.
  The single most frequent barrier to slide presentation was the physical awkwardness of changing slides. Six out of nine presenters walked to one spot to talk, but then had to turn and walk to a location typically 3 feet away, position themselves, advance the slides using the mouse on their PC, and then return to their original location to talk.




Table 6-2
Summary of selected barriers discovered within the step-by-step task interaction models for slideshow presentationsa


18 Question from remote audience member

Answer questions	Audio unintelligible. Local members instruct remote members to adjust audio setting.



19 Comment from remote member

Respond to comment	Audio unintelligible. Local members instruct
remote members to reconnect.



20 Comments from local members

Respond to comments by referring to slide from earlier in presentation

Presenter tries to return to slide. Presenter searches through slides rapidly but cannot find it.



21 Question from local member

Answer question	Presenter tries again and eventually finds slide.



22 Local member asks presenter to bring up previous slide.

Go backward one slide	Presenter tries to go back one slide but goes
forward one slide instead.



23 Remote audience reconnected

Continue discussion



24 Question from remote member

Answer question



25 Comment from local member

Respond to question	Presenter flips through slides searching for "system architecture" slide.



aThanks to Brad Myers, Carnegie Mellon University, and his colleagues for their case study (Cross, Warmack, & Myers, 1999) on which
this is based.

Table 6-3
Summary of most frequent barriers observed in presentation casesa


1. Changing slides is difficult and awkward because of the placement of the mouse or laptop.

Physical	67	166	1.2	2 sec



2. Presenter loses track of time, must ask for verbal update.

Sequence	44	6	1.5	55 sec



3. Reference provided is incomplete or skimmed over, audience members would be unable to find it after the talk.

Cultural	44	6	1	19 sec



4. Camera view is unclear or pointed at wrong information.

Flow	33	3	1.7	60 sec

5. Audio level for demos is not set correctly.	Flow	33	3	2	46 sec

aThanks to Brad Myers, Carnegie Mellon University, and his colleagues for their case study (Cross, Warmack, & Myers, 1999) on which
this is based.



  Often, the PC was on a low table, or otherwise difficult to reach, further compounding the problem. This behavior wasted a significant amount of time during presentations. One presenter found a solution that wasted less time: stay next to the slide control throughout the lecture part of the presentation, but move to a spot away from behind the podium and closer to the audience for the duration of the discussion period.
  The second-most frequent barrier to a smooth presentation was an inability of presenters to keep track of time or be aware of how much time they had remaining. Six of the presenters asked an audience member for a time check at some point during their lectures.
  None of the barriers reached the highest severity rating used by the study group-causing a permanent and premature end to the presentation. However, three different presentations did encounter barriers with major severity, requiring significant portions of the talk to be skipped. One had a demo that could not be shown because the PC lacked Shockwave software. Two of the presentations with remote audiences contained significant periods of time when the remote audience could not read the presentation slides because of an unfocused camera and problems with the settings of the NetMeeting software.

6.9 MODEL CONSOLIDATION
If you constructed your models with multiple subteams working in parallel, you will get multiple models of the same type. Now is the time to consolidate the model versions by merging, uniting, and combining them into one model. The 
 key idea is to induce generalizations, that is, a bottom-up process to build a 
 general model from pieces of specific data. 
  It is a little like eliminating the unimportant details and taking the union of the important ones over all the versions of the model.
  As an example, start with representations of single user stories of task steps in the existing work practice. Merge the description of essentially the same task created with data from several users, and factor out the differences in details. The result is a more abstract or more general representation of the interaction, representing how most or all users do the task.

Example: Flow Model Consolidation for MUTTS
When flow modeling that was begun in contextual inquiry is continued during contextual analysis by different subteams, each may model things differently; for example, the same work role might get modeled in different ways, yielding different work role descriptions and work role names. Because these various versions of the flow model are about the same workflow, they can be consolidated essentially by merging them.








  For example, Figures 6-20, 6-21, and 6-22 are partial flow models constructed by groups who observed and interviewed different parts of the overall organization and work practice.
  See, in Figure 6-9, how the three parts of the overall flow model came together in model consolidation.

Figure 6-20
Flow model from a group who observed and interviewed the event manager, event sponsors, the financial manager, and the database administrator.




















Figure 6-21
Flow model from a group who mainly observed and interviewed ticket buyers and ticket sellers.




Figure 6-22
Flow model from a group who observed and interviewed the office manager, the advertising manager, and external advertisers.




6.10 PROTECTING YOUR SOURCES
One of the things to watch out for throughout the process, especially when dealing with design-informing models, is confidentiality. This is important in all cases where you have observed, synthesized, deduced, or were given insights that were about problems and breakdowns arising due to social and political issues in the work practice.
  Situations involving breakdowns due to bad management or flawed work practices (modeled in social models) are especially dangerous if there is a chance the sources will be revealed. Make this your unbreakable rule: When you take data and models back to anyone, users or management, everything must be anonymous.

6.11 ABRIDGED METHODS FOR DESIGN-INFORMING MODELS EXTRACTION
6.11.1 Be Selective about the Modeling You Need to Do
Do not be bound by the exact models we discuss in this chapter. Depending on the work domain and your design goals, some kinds of models will not be important, while others will take on much more importance.



6.11.2 Designer-Ability-Driven Modeling
In the real world, designers use design-informing modeling to understand and control the complexity of the work domain in the context of designing the next generation of system support. To be efficient, each designer chooses the amount of modeling necessary to meet his or her own needs, which in turn depend on the designer's individual skills, knowledge, and experience.
  Less experienced designers will need to work out models in more detail to manage complexity and be sure that all the complexity of the work domain is accounted for. Expert designers, who perhaps have experience in a similar kind of system or a similar work domain, already know things that will propel their process forward more rapidly. Often it is not necessary to develop all the models fully and formally along the way. Experienced analysts or designers
do not build models that will tell them something they already know.
  The models are a way of cognitively off-loading details so that there is room in the analyst's head for other analysis. Experienced designers have abstractions for some of the models mentally built in, leaving room for further analysis. Of course such ability-driven approaches run the risk of missed details and issues falling through the cracks, but the practical bottom line is that, in most real- world projects, designers rarely develop a complete set of full models, but just the key aspects of the models they feel they need the most.
  So, students entering the professional workforce and novice practitioners should make all the complete models but should also be aware of this reality and not come across as impractical to the more experienced analysts by insisting on constructing every model in full before moving on to design.

6.11.3 Use a Hybrid of WAAD and Relevant Models
Mix and match the modeling best suited for your needs. Add different models of your own creation. Combine simple models into a hybrid model, for example, combine workflow superimposed upon a physical model.
  Another effective way of abridging the process for creating design-informing models is by creating a hybrid of a WAAD and relevant models on the same wall. We recommended using large strips of butcher paper to create your WAAD; you can capture the essence of the different models right next to the clusters of work activity notes on the WAAD. This canvas affords a fluid medium to represent relationships among the different themes in the work domain; you can draw on the WAAD and annotate it with ideas that you would otherwise capture in different formal models while using a full rigorous process.
  For example, any interpersonal concerns that you would usually capture in a social model will now just become annotations on the cluster of notes



organized under the corresponding work roles. In our experience we found a hybrid of a WAAD and flow model to be the most useful.

6.11.4 Create Design-Informing Models on the Fly during Interviews
Another abridged technique we have used in the field with great success is
on-the-fly modeling during the actual contextual inquiry process. Experienced practitioners can create or add to models as they are interviewing and observing users during contextual inquiry.
  Any information that can be captured as a model is done so as rough sketches, and the remaining information is captured as regular work activity notes. For example, during our interview with a MUTTS ticket seller, she mentioned
the need for all ticket sellers to enter the amount of money taken from the safe into a ledger at the start of a shift, a need for recording the total deposit at the end of the shift, and to attach a printout of all sales in that shift generated by the ticketing software system. Instead of capturing this information as a series of work activity notes, we can capture this in a flow model diagram on the fly.

6.12 ROOTS OF ESSENTIAL USE CASES IN SOFTWARE USE CASES
A use case is not a user experience lifecycle artifact, but a software engineering and systems engineering artifact for documenting functional requirements, especially for object-oriented development, of a system. "Use-cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful" (Bittner & Spence, 2003). They include outside roles-end users and external entities such as database servers or bank authorization modules-and internal system responses to outside actions.
  Although a use case can represent the user view, the bottom-line focus is on functional, not interaction, requirements. Sometimes use cases are thought of as an object-oriented approach to user modeling, but in practice they are usually created by developers and systems analysts without any contextual data from users.
 Use cases are formalized usage scenarios, narratives of "black box" 
 functionality in the context of user-system interaction (Constantine & 
 Lockwood, 1999, p. 101).  Use cases are often used as a component of software requirements. Their strong software orientation means that use cases lean in the direction of software implementation and away from user interaction design.



As Meads says (2010), in use cases, the user is an external object, not a person with human needs and limitations. This view leads to system requirements, but not to usage or UX requirements.
  Use cases describe the major business requirements, features, and functions that the envisioned system must support. A use case "describes a sequence of actions that are performed by a human in work roles or other entities such as a machine or another system as they interact with the software" (Pressman, 2009);
 "use cases help to identify the scope of the project and provide a basis for project 
 planning" (Pressman, 2009).
 In answer to the need for something more effective than use cases in 
 identifying interaction design requirements, Constantine (1994a, 1995) created 
 a variation he calls "essential use cases." 

Intentionally left as blank


Design Thinking, Ideation, and Sketching





A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
- Douglas Adams



7.1 INTRODUCTION
7.1.1 You Are Here
We begin each process chapter with a "you are here" picture of the chapter topic in the context of the overall Wheel lifecycle template; see Figure 7-1. We have noted that contextual inquiry (Chapter 3) is empirical, contextual analysis (Chapter 4) is inductive, requirements extraction (Chapter 5) is deductive, and design is integrative.
  Chapters 3 and 4 are about existing work practice and any existing system. Chapters 5 and 6 are the bridge connecting analysis and design. This chapter and the next two are about designing the new work practice and the new system.

7.1.2 Design vs. Development
The entire field of system development uses the term "design" in a very broad sense, often connoting the entire lifecycle process. People refer to the "system design lifecycle" or "the interaction design process." People say "you cannot do design without including evaluation." And, of course, we agree.






Figure 7-1
You are here; the first of three chapters on creating an interaction design in the context of the overall Wheel lifecycle template.



The problem is that "design" is also used narrowly to refer to the creative 
 human activity by which new ideas are synthesized and put together to make 
 up parts of an interaction design, that is, to the box labeled "Design" in Figure 7-1, the topic of this chapter. In this usage, design is just one process activity and does not include the others; it specifically does not include analysis or evaluation.
  There is really no effective term to distinguish the overall process from just synthesis activity. We would love to use the terms "develop" and "development" for the entire lifecycle process, calling it a "development lifecycle process." However, "develop," "development," and "developer" are terms used almost universally to denote software engineering concepts tied strongly to programming and coding. A developer is someone who writes or develops implementation code.
  Our path to happiness regarding this terminology trap is to follow the loose conventions of the field and use "design" with both narrow and broad meanings, hoping that context will provide clarity. In addition, weavoid "develop," "developer," or "development" as much as possible unless we are talking about software implementation. Instead, we will refer to the entire UX lifecycle process as a process for creating and refining interaction designs and will refer to activities in the lifecycle as process activities. On a rare occasion, we might lapse into using

DESIGN THINKING, IDE ATION, A ND SKETCHING  253


"development" to mean the creation and refinement of something, such as the development of a flow model. In those cases we are counting on context to avoid ambiguity.

7.2 DESIGN PARADIGMS
In a seminal paper that we think should have received more exposure, Harrison, Tatar, and Sengers (2007) paint the history of the focus of design in human- computer interaction (HCI) as a series of paradigms: engineering, human information processing (HIP), and phenomenological. They get credit for identifying the phenomenological perspective as a major design paradigm within the three major intellectual waves that have formed the field of HCI:

� Engineering and human factors: deconstruct work with the objective of designing the machine for optimum human performance.
� Cognitive science: the theory of what is happening in the human mind during and with respect to interaction by treating human minds as information processors.
� The phenomenological paradigm (they call it the phenomenological matrix): emphasis in interaction is about making meaning (more on this later).

  The increasing importance of social and situated actions in HCI was at odds with both the usability-oriented engineering paradigm and the cognitive
logic of the human information processor approach. The initial reluctance of HCI as a field to recognize and embrace the phenomenological paradigm spawned a parallel exploration in computer-supported cooperative work.
  Activity theory helped explain the situated actions in work practice but did not do much to help design and evaluation. The paper by Harrison, Tatar, and Sengers (2007) is an evangelical wake-up call to include the phenomenological paradigm in mainstream HCI.
7.2.1 Engineering Paradigm
With some of its roots in software engineering, the HCI engineering paradigm prescribed starting with an inventory of the functionality envisioned for a
new system and proceeding to build an interaction design of the best quality possible given available resources.
  With recognition that user interaction deserved attention on its own, usability engineering emerged as a practical approach to usability with a focus on improving user performance, mainly through evaluation and iteration. The engineering approach casts design as just another lifecycle phase, a systematic approach that often works well for building systems with complex work domains.



  The engineering paradigm also had strong roots in human factors, where work was studied, deconstructed, and modeled. Here, the goal was user productivity and eliminating user errors. An example is the study of an assembly line where each action required to do work efficiently was described carefully. These descriptions were then more or less translated into requirements.
  Designs focused on how to support these requirements and to automate where desirable. It was a purely utilitarian and requirements-driven approach. Success was measured by how much the user could accomplish, and alternative methods and designs were compared with statistical summative studies.

7.2.2 Human Information Processing (HIP) Paradigm
The human information processing approach to HCI is based on the metaphor of "mind and computer as symmetrically coupled information processors" (Tatar, Harrison, & Sengers, 2007). This paradigm, which at its base is about models of how information is sensed, accessed, and transformed in the human mind and, in turn, how those models reflect requirements for the computer side of the information processing, was defined by Card, Moran, and Newell (1983) and well explained by Williges (1982).
  The HIP paradigm has its roots in psychology and human factors, from which it gets an element of cognitive theory. Especially as psychology is used in the discipline of human factors, it is about human mental states and processes;
it is about modeling human sensing, cognition, memory, information understanding, decision making, and physical performance in task execution. The idea was that once these human parameters were codified, it is possible to design a product that "matches" them. Guidelines, such as not having more than seven plus or minus two items on transient lists on a user interface because of limits on human short-term memory, were a result of this type of thinking.

Human-Computer Interaction Design and the Three Paradigms
Deborah Tatar, Department of Computer Science, and, by courtesy, Psychology; Member, Center for Human-Computer Interaction; Member, Program for Women and Gender Studies; Virginia Tech Steve Harrison, Department of Computer Science and School of Visual Arts, Virginia Tech.
Methods are like toothbrushes. Everyone uses them, but nobody wants to use somebody else's. John Zimmerman
  As you learn the methods in this book, you will adopt them for your own, and as you adopt them, you will adapt them to the situation that you are working in. Learning this well will allow you to design how you design.

However, some changes are particularly difficult to understand and encompass. These are shifts across paradigms. You are unlikely to do this often, but sometimes it may be important to know when a shift is important or to recognize that someone else is working in a different paradigm.
  In this sidebar, we define design as making something new that fits with reality. A design idea is a proposal for action in the world, burdened with the responsibility to solve problems or create delight. These definitions are cross- cutting. But the outcomes of design work are not as general as these definitions because any given design problem is approached within the particular way of seeing the world held by the designers. Such world views consist of a set of practices, expectations, and values sometimes called paradigms. Some world views value "thinking outside the box." In fact, they may value this so much that one criterion for success is to break out of whatever assumptions are seen to be in place! Others may value the most refined interface that perfectly fits a heavily researched user. Paradigms suggest the kinds of questions that the designer should care about, what factors are important to consider, and what factors are outside the scope of the endeavor. The notion of paradigms differs a bit in its use in linguistics, in science, and in computation. What is really important here is that, in design, there is no absolute best for all circumstances. It depends on the paradigm. Identifying the paradigms in design helps us understand the intended value of the work more clearly.
  The three paradigms we identify in human-computer interaction (HCI) are human factors, classical cognitivism/ information processing, and the third/phenomenologically situated paradigm. Each of these paradigms represents a world view. Each encompasses a set of practices and expectations for the value and contribution of research. Each contributes to HCI, but in different ways. Some people might argue that there are more than three paradigms, whereas some might argue that there are fewer. But these have substantial claim to both history and utility. Human factors focus on optimizing man-machine fit. Classical cognitivism/information processing emphasizes (ideally predictive) models and theories about the relationship between what is in the computer and in the human mind. The third paradigm, with its base in phenomenology, focuses on the experiential quality of interaction, primarily the ways that users experience meaning in the artifact and its use. The third paradigm, unlike the other two, emphasizes the ways in which individuals and individual experiences in the moment may differ from one another.
  To orient you, we will cartoon the nature of each of the paradigms through a simple and well-known interface example.
In the 1960s, the U.S. Air Force developed automated cockpit warning systems to alert pilots to hazardous conditions.
The systems used recorded voices to tell pilots to turn, climb, or dive to avoid head-on collisions, among other things. Each of the three paradigms contributes a different kind of thinking to the formulation of the problem and the range of solutions.

1. Situations that drove the initial system design were classic examples of human factors "critical incidents" (Flanagan, 1954). That is, pilots were crashing more often than they needed to. The Air Force realized that they needed to gain the pilots' attention quickly to avert these problems. At the time, all pilots and flight controllers were male, so someone had the bright idea of using a woman's voice so that it would be immediately identified as the "emergency voice." This was
clever and worked well to reduce pilot errors.
2. The use of women's voices was a particular design solution. However, it worked for reasons of interest to the classical cognitivism/ information processing paradigm; women's voices effectively differentiated signal from noise in the system interface's interaction

256  THE U X BOOK: PROCESS AND GUIDELINES FO R E NSURING A QUALITY U SER E XPERIENC E




with the pilot. They allowed the efficient transmission of information, an important factor in any model of (i) human, (ii) computer, and
(iii) interaction. Instead of simply saying "we are using women's voices because they are different from men's voices," in this paradigm, we describe a model in which women's voices vs men's voices is an instance of the critical, generalizable parameter of signal/noise differentiation. This description suggests other design solutions. For example, a taxonomy of voice types, based on cognitive load and desired response times, could be created. Indeed, experimentation using this approach revealed that familiar women's voices (i.e., wives, girlfriends) further improved pilot performance over nonspecific women's voices. This approach optimized communication and pilot mental workload. This kind of characterization also continued to be useful once women became pilots and flight controllers. It predicted that their voices would no longer have the crucial properties and that another design solution needed to be sought.
3. However, starting with the first paradigm finding, there is still more to be said. A pilot's wife's voice might be most familiar, but might lead to unpredictable pilot response when the couple was on the verge of divorce. In the third/phenomenologically situated paradigm, we include construction of meaning in our description of the situation, including social and emotional meaning. This leads to different design implications and explorations than those that emerge in the design solutions of the other two approaches. In fact, the original female voice was reputed to have been selected for its sultry and seductive tone.1 This
quality reinforced the idea of the space of the cockpit being "male," echoed in movies such as Top Gun. However this appeared originally to pilots, it became palpably inappropriate in creating a comfortable workplace as women became pilots and flight controllers. An important aspect of the third paradigm is that it is as concerned with the variety of human behaviors as with their prevalence. That is, suppose you find that voices with certain properties work well for 98% of pilots. In the third paradigm, you might decide that you have to account for what makes the other 2% different, whereas in the first two paradigms, one is more likely to dismiss these as statistical aberrations or error.
   We picked this example because the boundaries to generalizability have changed so palpably that it is relatively easy to perceive all three paradigms. Most of the time that is not the case, even retrospectively. People make arguments based on unarticulated positions, allegiances, and values, often dismissing thinking in other paradigms as uninteresting, unimportant, dull, or frivolous.
  We advance the idea of the three paradigms not as an absolute truth to last for the ages, but as an important heuristic that helps explain important differences of opinion about what constitutes good design in HCI. This perspective is useful in understanding what is happening in contemporary HCI. It may also be helpful in scoping particular design problems, in understanding the concerns of a particular client, and in working across organizational and institutional team boundaries.

1One interesting side effect was to gender popular media representations of flight control automata as female. Particularly notable is the original StarTrek computer.




7.2.3 Design-Thinking Paradigm
Harrison, Tatar, and Sengers (2007) propose a third HCI design paradigm that they call the "phenomenological matrix."  We call it the design-thinking 
 paradigm because our use of that concept goes a bit beyond their description of 



 a "pure" phenomenological approach. This third design paradigm brings a vision of the desired user experience and product appeal and how the design of a product can induce that experience and appeal.
  For B0dker and Buur (2002), the third paradigm for HCI design is motivated by a desire to "reframe usability practice." The heavy priority for usability testing in traditional usability methods meant that usability concerns were being brought into the process too late and that emphasis was on refining a design but not on getting the right design in the first place [as Buxton (2007b) would say it]. They used participatory design techniques to experiment with and explore design through early prototypes as design sketches.
  Another of their reasons for reframing usability practice is the fact that the usual usability techniques focused on snapshots of usage, user performance evaluated during single tasks. But they wanted to include emergence of use. They also wanted to overlap the four basic process activities-analysis, design, implementation, and evaluation-instead of "pipelining" them in an iterative process.
  As a contrast to the other two paradigms, the third one is not about the utilitarian aspects but more about the emotional and phenomenological ones. The design-thinking paradigm is about social and cultural aspects of interaction and the design of "embodied interaction" because it is about interaction involving our whole bodies and spirit, not just our fingertips on a keyboard. It is also about "situated" design because it is about the notion of "place" with respect to our interaction with technology.
  Malcolm McCullough (2004) espoused this idea in the context of pervasive, embedded, and ubiquitous computing surrounding us in our lives and in
our architecture, connecting interaction design with psychology, cultural anthropology, and technology.  A primary characteristic of the design-thinking