![THE USER VIEW
As stated above, factors that affect an end user’s experience
are not just those that determine the efficiency of the interface
in enabling task completion. Functionality is, of course, critical
to the continued product viability—it needs actually to do
something—but viability is more than functionality. We all will-
ingly enter into experiences (buy products, use services, etc.)
that are far from functionally optimal, and yet we leave satis-
fied. Agarwal and Karahanna (2000) defined the concept of
“cognitive absorption,” which seems like a good way to de-
scribe the main goal of product designers and developers, as
“A state of deep involvement . . . exhibited through temporal
dissociation, focused immersion, heightened enjoyment, con-
trol, and curiosity.”
Few products regularly produce cognitive absorption. In or-
der to understand why, it is valuable to define some other terms
describing important aspects of the user experience from the
user’s perspective.
Ortony, Norman, and Revelle (2005, p. 174) proposed a
model that describes “an organism’s” (e.g., a person’s) psycho-
logical function in the world. The model’s four (continually in-
terrelating) parts are:
• Affect—what the organism feels
• Motivation—what the organism needs and wants
• Cognition—what the organism knows, thinks, and believes
• Behavior—what the organism does
Product design implicitly takes all of these factors3
into con-
sideration, but explicit examination of them is rare. Marketing
researchers investigate motivation; interaction designers use
their knowledge of cognition; usability research focuses on be-
havior; and visual or identity designers and advertising agen-
cies try to influence motivation through affect. However, that is
an ideal situation. In reality, the practice of understanding and
structuring a unified experience is so new that design generally
runs on gut-level intuition, and everyone is guessing at every-
thing. Gut-level decision making is not necessarily bad. Humans
are often good at predicting other humans’ reactions—except
when intuition totally fails.
The User Experience of Products
Affect. According to Ortony et al. (2005), emotional re-
sponse, or affect, is a complex interaction of immediate reac-
tions modulated by experience with previous situations and
cognitive predictions of future states, all of which happens
rapidly and simultaneously. Immediate feelings, emotions, and
moods are different states operating at different levels of gran-
ularity. They are also critical to people’s experiences of a product.
When people fall in love at first sight with a product or a place,
their successive experiences will not be moderate. The emo-
tions may lead them to overlook interaction problems or poor
functionality. Later, the emotional state may wear off, the hon-
eymoon ends, and the inadequacies of the product turn joy into
disillusionment.
Davis (1989, p. 320) showed that “both perceived usefulness
and perceived ease of use were significantly correlated with self-
reported indicants of system use.” People’s emotional relation-
ships to products before they had the opportunities to use
them affected how they used them later. Zhang and Li (2005,
p. 106) extended Davis’ research by applying a more primal con-
cept, affective quality. They investigated the perceived affective
quality of software products and concluded, “a user’s immedi-
ate and reflexive affective reaction to [information technology] has
a positive impact on his or her consequent cognition-oriented
evaluations of the [technology].”
Furthermore, Nass and Reeves (1996) described in detail
how people exhibited many of the same emotional responses to
computers, televisions, and films as they did to other humans,
significantly changing their expectations and behaviors toward
the technology as a result.
What constitutes affective quality (which is measured in
terms of valence and activation; e.g., the direction and magni-
tude of the emotional response) in terms of technological prod-
ucts is still under investigation. However, evaluating and de-
signing the complete user experience clearly requires close
consideration of the experience’s affective aspects.
Value. People act for a reason. They engage with products
or experiences for some reason (or reasons), they keep using
them for other reasons, and they stop for others still. In the
largest context, Maslow’s (1943) hierarchy of needs serves as
one model of how what people value in their lives motivates
their actions. Norman et al. (2005) described how one kind of
motivation, curiosity, could arise from an emotional response to
an environment. “Animals’ motivation systems [let] the resting
point of affect be slightly positive so that when there is nothing
that needs to be done, the animal is led to explore the environ-
ment” (Ortony et al., 2005, p. 194).
However, pure curiosity rarely leads people to have new ex-
periences or to continue well-known experiences. When using a
household appliance, for example, curiosity rarely drives peo-
ple’s behavior. From a product developer’s perspective, a good
approximation of motivation is what creates value for the end
user. Value consists of two elements:
• The product’s perceived potential for changing a customer/
user’s life
• How well it satisfies that potential
Perceived potential consists of three elements: functional,
economic, and psychological (Sawhney, 2003). The functional
aspect is the prospective user’s expectation about whether the
product will be able to solve a real-world problem the person
1. User Experience and HCI • 7
3
These terms are a framework for the subsequent discussion. They are not defined in the same rigorous, technical way that Norman et al. (2005)
defined them in their work. The definitions provided here are the more common dictionary definitions, which are a superset of how Norman et al.
defined them.](https://image.slidesharecdn.com/2323845-250519204738-65f60c7f/85/Humancomputer-Interaction-Development-Process-Sears-Andrew-28-320.jpg)
![outside the context of their daily routine, critical details such as
spatial placement, time of day, materials used, or triggering event
can be lost.
Direct observation identifies emotional reactions that would
be otherwise difficult to capture. For example, Vrendenburg,
Righi, and Isensee (2001) described a situation where a t-shirt
included in the packing material of an IBM RS/6000 computer
led to surprise and delight from users—signs of a good user ex-
perience—just unpacking the box:
Users opened the product box to find a t-shirt, a mouse pad, a copy of
Wired magazine, and games that showcased the 3D graphics capabilities
of the system such as Quake. This approach to design worked beauti-
fully. It became cool to have an RS/6000. One of the most common ques-
tions asked by customers in the feedback survey was “Where can I get
another t-shirt”? (p. 34)
This was an unexpected observation that was not part of a
focused program of focused ethnographic observation of peo-
ple’s experiences unpacking RS/6000 computers, but it is repre-
sentative of the kinds of things such observation produces. In an-
other instance, Berg, Taylor, and Harper (2003) observed the
following relationships between UK teenagers and their mobile
phones:
[The] text messages that were exchanged were sometimes described
as objects that evoked particular memories. The messages were the
embodiment of something personal that could be stored, retrieved,
reread and shared, becoming tangible mementos for individuals and
groups. Thus, the phone appeared to provide a means to participate
in social exchange in so far as it enabled particular objects to take on
symbolic meaning and for the objects to be seen as meaningful be-
tween people. (p. 434)
Such insights map directly to user experience design (as the
authors then proceeded to do). They allow technology to en-
able specific, observed behaviors in the context they occur,
rather than hypothetical behaviors and assumed needs.
Field research methods for user-experience design are typi-
cally neither as detailed, data-heavy, or analytically rigorous as
formal ethnography (Bentley et al., 1992). These techniques fo-
cus on pragmatic on the ground observation and interpretation
within the context of a development and production process.
They use standardized methods and seek to identify contact
points, activity sequences, artifacts, and values in the context of
work practices. Beyer and Holzblatt’s (1998) contextual inquiry
is probably the most prevalent of these techniques. Generalized
from rapid ethnography (Millen, 2000), Table 1.6 lists a set of
steps for conducting field research.
Find key informants, schedule research. Millen
(2000) recommended identifying informants and asking them
to serve as guides through a field observation. He suggested
that guides should be “people with access to a broad range of
people and activities and be able to discuss in advance where in-
teresting behaviors are most likely to be observed or where ac-
tivities that reveal social tension are most likely to be found”
(Millen, 2000, p. 282). For example, when observing technol-
ogy in a hospital, it pays to talk to a nurse who works there, or
if investigating hobbyist PC case modification (casemod) cul-
ture, it’s valuable to have a member of a club of modders intro-
duce you to the hobby and the players in it.
When choosing informants, you should pick at least five peo-
ple or groups who resemble the people who will use your prod-
uct or who will provide key insights. Overall, they should have
the same profile as the eventual target audience, though fringe
members of a group may be good informants and provide in-
formation or exhibit behavior that typical group members will
have internalized.
The breadth and depth of research will determine the extent
of the study undertaken: long-term planning generally requires
deeper insight and, thus, more and longer observation than
short-term problem solving, for example. A typical month-long
research schedule (Table 1.7) generally involves two to five
hours per observation or interview period, followed by two to
three hours of group analysis per hour of observation.
Narrow the focus. The goal of traditional ethnographies
is to understand as much as possible about the entire context
in which a group of individuals acts, without judgment. In con-
trast, most commercial research projects begin with an idea
about what problems need solving and an idea about how to
solve them. Field observation clarifies and focuses these ideas
by discovering the situations in which these problems occur and
how people deal with them. In addition, unlike an evaluative
technique such as usability testing, it is observational and typi-
cally uncovers unexpected directions. Thus, it is best done be-
fore the process of creating solutions has begun when there is
still time to iterate on research. This is usually at the beginning
of the development cycle.
However, in the interest of maximizing immediate results,
the project typically concentrates on the fields of activity that
will likely produce results that designers can incorporate into
the user experience. Narrowing focus means identifying the im-
portant aspects of your audience’s work or life practice, while
leaving open the option to challenge assumptions. One tech-
nique is for researchers to familiarize themselves closely with
the terminology, tools, and techniques their audiences are likely
14 • KUNIAVSKY
TABLE 1.6. Steps for Conducting Field Research,
Adapted from Millen (2000)
1. Find key informants
2. Narrow the focus
3. Use interactive observation
4. Use multiple researchers and analyze collaboratively
5. Validate conclusions
TABLE 1.7. Typical Field Research Schedule
Timing Activity
t 2 weeks Organize and schedule participants.
t Begin observation. Begin analysis-scheduling process
for development team.
t 1 week Complete observation. Review videotapes and notes.
Complete analysis scheduling.
t 2 weeks Begin analysis.
t 3 weeks Complete analysis.](https://image.slidesharecdn.com/2323845-250519204738-65f60c7f/85/Humancomputer-Interaction-Development-Process-Sears-Andrew-35-320.jpg)
![to use. An informant can walk the researchers through some
concepts before formalizing the research goals. The sports-
caster method, where one informant explains what another one
is doing, is another useful technique. For example, walking
through a shopping district with a fashion-conscious teenage
commentator can reveal a lot about where to look for interest-
ing behaviors, rather than starting from scratch.
With this information in mind, it’s possible to narrowly de-
fine the aspect of the practice that you can ask questions about
and observe.
User interactive observation. This is the key to the
technique, and it requires going to where people are engaged
in the kind of activity the experience for which you are designing
and asking them to teach you about their activities. Most of the
time should be spent observing what the participants are doing,
what tools they are using, and how they are using them. One
effective technique is to take on the role of an apprentice and
ask them to give a running description of what they are do-
ing. As in an expert-apprentice relationship, this should be
enough to describe the practice to the apprentice but not
enough to interrupt the flow of the work. As an apprentice, you
may occasionally ask for explanations, clarifications, or walk-
throughs of actions, but do not let it drive the discussion.
Observations can be in the form of structured interviews,
with prewritten discussion guides. This is useful in answering
specific questions, but risks missing key challenges to assump-
tions. Other kinds of tools can elicit specific kinds of information
(Beyer Holzlbatt, 1998; Millen, 2000), or aid in construct-
ing models later (Wixon et al., 2002). An informant can use a pa-
per model of a shop floor, for example, to describe activity in a
factory than would be possible in the loud environment of the
factory itself.
Collect as much documentation of the practice as possible.
Digital and video cameras, liberally used, provide both material
for analysis and illustrations for presentation. Collect physical
artifacts, when possible. For example, a group of researchers
studying patterns of technology use in urban German areas took
400 photographs in a span of three hours and brought back
posters, local handicrafts, and a pipe from a construction site.
Use multiple researchers and analyze collabora-
tively. Collecting and analyzing data simultaneously can pro-
vide efficiency, though it introduces more potential biases to the
interpretation of the observations (Madison, 2005). Techniques
for group qualitative data analysis range from traditional tran-
script coding methods (U.S. General Accounting Office, 1996)
to contextual inquiry’s formal methods (Beyer Holzblatt,
1998) for constructing multifaceted models of users’ work prac-
tices. Affinity diagrams are a particularly popular method. Table 1.8
describes the steps in the construction of an affinity diagram. It
takes about one day.
This rather mechanistic process yields good first-cut results
about the breadth of the user experience, and frames subse-
quent investigation.
Validation. A key part of modeling is to evaluate the qual-
ity of the model with the people whose lives it models. An im-
mediate follow-up interview with in-depth questions can clarify
a lot. Certain situations may not have been appropriate to in-
terrupt (e.g., if you are observing a surgeon or a stock trader,
that may apply to the whole observation period), whereas oth-
ers may have brought up questions that would have interrupted
the task flow. Conducting this interview while the participant’s
memory of the event is still fresh will produce best results.
“You’ll never understand what’s really going on until you’ve
talked to people about what they are doing. The [follow-up] in-
terview . . . gives you the rationale to make sense of things that
might otherwise seem odd or insignificant” (Bellotti, 1999).
Focus Groups5
People’s affective responses and values are hard to observe ob-
jectively, and getting a subjective read is often all that is possible.
Focus groups are structured group interviews that quickly and
inexpensively reveal a target audience’s desires, experiences,
priorities, and values. Sometimes vilified by their associations
with dishonest marketing, they do not deserve their notoriety.
They are neither the panacea for curing bad products nor pseu-
doscientific voodoo to justify irrational decision making. When
moderated well, carefully analyzed, and appropriately presented,
they are an excellent technique for uncovering what people
think about a given topic and, especially, how they think about
it. A focus group reveals people’s perceptions of their values:
what they feel right now and how they see that in relation to
themselves. Those are crucial in understanding how an experi-
ence will affect them.
1. User Experience and HCI • 15
TABLE 1.8. Affinity Diagram Construction,
Adapted from Beyer and Holzblatt (1998)
1. Extract 50–100 notes from each interview. Notes are singular
observations about tools, sequences, interactions—anything.
Randomize them.
2. Get a group of people together in a room with a blank wall or a big
whiteboard. Have them block out the whole day for the work.
3. Divide the group into pairs of analysts. Give each pair an equal
number of notes.
4. Write one note on a Post-it and put it on the wall/window/board.
5. Tell the group to put notes that relate to that note around it one at
a time. It does not matter how the notes relate as long as the group
feels they relate.
6. If no more notes relate to a given note cluster, write a label
summarizing and naming the cluster (use a different color so it’s
easy to identify the labels).
7. Repeat the process with the other notes, labeling groups as they occur.
8. Generally, it is useful to break up groups of more than four notes into
smaller clusters. However, there is no upper bound on how many
notes may be in a group if there is no obvious way to break it up.
9. As the groups accumulate, Beyer and Holzblatt (1998) recommended
using pink notes to label groups of blue notes and green notes to
label groups of pink notes.
5
Much of this chapter is adapted from Kuniavsky, M. (2003).](https://image.slidesharecdn.com/2323845-250519204738-65f60c7f/85/Humancomputer-Interaction-Development-Process-Sears-Andrew-36-320.jpg)
![Develop discussion topics. For an average focus group,
you should have three to five main topics to investigate. You
should phrase topics in terms of the project as a whole. “Un-
derstanding the mental model people use when researching in-
surance” could be a goal for an insurance brokerage website,
while a service that recommended home building contractors
could be interested in “Knowing at which point people turn to
an external service when doing home repair.”
Focus these objectives enough that a group could adequately
discuss each one in about 10 minutes. Do not phrase them as
questions or issues that other methods (such as a survey) can
better answer. A survey could make “A list of our competitors”
better than focus groups, whereas “The factors that make Sony’s
camera phone experience more compelling than ours” is more
appropriate.
Write a discussion guide. The discussion guide is a
script for the moderator to follow. It creates a consistent frame-
work for the focus group series by asking the same questions
in the same order with much the same context. This allows a
discussion to bring out the subtleties of the participants’ views
without shortchanging any of the topics.
Focus group discussion questions should be:
• Carefully ordered. Questions get the participants thinking
about certain issues and remembering certain events. A care-
ful sequence of questions takes advantage of their frame of
mind to make the flow of the group discussion feel more nat-
ural, which in turn helps the participants to maintain a cre-
ative flow of ideas and produce better insights. In general,
questions should flow from the most general to the most spe-
cific, with each question narrowing the discussion a bit.
There should be planned transitions between topics unless
introducing a brand new topic.
• Nondirected. Questions should not imply an answer or
present a value judgment. They should allow participants
to fill in their own thoughts and values. For example, ask-
ing, “Which do you think is a better search service, Google
or Yahoo?” assumes that the participant feels there are ad-
vantages of one over the other. Instead, frame questions
neutrally: “Are there any things you like about using the
Google search service? Are there things you like about
Yahoo? What are they? Can you compare them? How do
they compare?”
• Open-ended. Avoid constraining answers to fixed responses.
Longer, more open responses tell a greater part of the story
and tend to be less ambiguous than shorter responses.
Rather than phrasing a question in the form “Which of these
camera functions are most important to you?” you could ask
“Which functions do you use? How often?”
• Focused on specifics. Conversely, encourage participants to
be specific in their answers. Krueger (1988) recommended
breaking down why questions into multiple what questions,
explicitly asking for the influences that informed their deci-
sion and the attributes of their decision. For example, “How
did you decide to go shopping for a new phone plan?” and
“What factors went into picking this carrier?” will provide bet-
ter insight than “Why did you pick Cingular?”
• Personal. Out of politeness people tend to generalize their
experiences to the public at large or to some hypothetical
audience which they are not part of. Since you want to
know individual views, values, and experiences, emphasize
individual experiences. Formulate question so that they con-
centrate on people’s current and past behavior and opinions,
without presenting the option to project. Thus, “If you had to
redo your kitchen right now, which of these features would
you use to find a home contractor?” is preferable to “Which of
these features do you think are useful?”
Granted, fulfilling all of these criteria with all questions is of-
ten difficult (writing questions that are simultaneously specific
and open-ended is a particularly tricky challenge), but they
should be kept in mind as guidelines that should be followed
whenever possible.
Analyze results. There are as many ways of analyzing fo-
cus group information as there are analysts. Since the informa-
tion is, by definition, qualitative and contextual, the focus of the
analysis will depend on the purpose of the group.
One method consists of the following steps:
• Quickly capture initial hypotheses. Immediately after the
end of the focus groups, walk through the discussion guide
section by section and ask the moderator and observers to re-
call their thoughts about it: What was unexpected? What was
expected but did not happen? What attitudes did people dis-
play? What values did they espouse? What interesting state-
ments did they make (and why were they interesting)? What
trends did they observe? Which participants provided inter-
esting feedback? What were the problems with the group?
• Record the groups, and watch the recordings to verify hy-
potheses. Merely remembering a situation can miss subtle be-
haviors. Words are misquoted. Observers fall into groupthink.
Reviewing the discussions clarifies ambiguities and reveals
shades of meaning.
MANAGE WITH USER EXPERIENCE
When introducing a new technology into a marketplace, there
is a risk of failure and of losing money and time on the investment
in developing, marketing, and distributing the technology. It is
of course possible to create successful technology without hav-
ing a model of the end user’s or organization’s needs and de-
sires. However, such successes are essentially the product of
lucky accidents. When such success happens, the organization
has to identify the elements that led to it. By this point, how-
ever, the product’s success has permanently changed the mar-
ket and the organization, and identifying what made it success-
ful is difficult. This supply-first model depends on predictable
markets and is passing. In the current environment, “business
[needs to be] an adaptive system for responding to unantici-
pated requests in unpredictable environments” (Haeckel, 1999,
p. 10).
Working from the user experience is essentially a demand-
first philosophy, continually redefining product scope to reduce
1. User Experience and HCI • 17](https://image.slidesharecdn.com/2323845-250519204738-65f60c7f/85/Humancomputer-Interaction-Development-Process-Sears-Andrew-38-320.jpg)
![the chances of failure and increase the chances of repeated suc-
cesses. In other words, in an adaptive organization, the organi-
zation adapts to the user experience.
Organizations make technology for some reason, so user ex-
perience is implicitly included in all technology creation. How-
ever, explicitly basing every stage of technology development
on user experience models is a relatively new concept. Though
many organizations claim to be customer centered, in practice
few product management practices actually make it the center of
all of their activities. Most concentrate the examination of user
and organizational needs at the beginning of a project (often
called the “requirements gathering” phase) or at the end (the
“evaluation” phase). Those are not the only options. Projects
starting from scratch, where the technology is new and the de-
velopment team is flexible, can use agile software development
methods that introduce user-experience knowledge through-
out the development process. However, mature products with
long-established processes, attitudes, and methods often make
starting from scratch impossible. This situation requires a differ-
ent mix of techniques.
Agile User Experience Development
Henry Ford called his 1907 car the “Model T” because there was
a model S before it, and a model R before that, all of the way
back to the first Model A in 1903 (the 1928 Model A was a con-
scious rebranding to evoke a new philosophy of building cars).
In other words, Henry Ford failed 20 times over the course of
four years at making a successful passenger car. He iterated,
based on feedback, on the idea until he found the correct com-
bination of factors.
Iteration based on feedback is the core philosophy behind a
family of software management practices called “agile software
development.” Agile development does not require detailed re-
search and design specifications up front or paper trails and
sign-offs throughout. Instead, agile methods focus on exten-
sive communication, rapid iteration, and continuously collect-
ing information and adjusting to it, rather than trying to plan the
entire process.
As Highsmith (2002) described:
Agility isn’t a one-shot deal that can be checked off the organizational
initiative list. Agility is a way of life, a constantly emerging and changing
response to business turbulence. Critics may counter, “Agility is merely
waiting for bad things to happen, then responding. It is a fancy name for
lack of planning and ad hoc-ism.” But agile organizations still plan; they
just understand the limits of planning. (p. 16)
Agile methodologies, which include Extreme Programming
(Beck Andres, 2004), Scrum (Schwaber Beedle, 2001), and
Crystal Clear (Cockburn, 2004), do not explicitly incorporate
collecting and interpreting user-experience knowledge; rather,
they continuously adapt to all new information.
Larman (2003) defined a set of core agile practices, summa-
rized in Table 1.11.
Iterative development. Larman (2003, p. 9) said, “An ap-
proach to building software (or anything) in which the overall
lifecycle is composed of several iterations in sequence. Each it-
eration is a self-contained mini-project composed of activities
such as requirements analysis, design, programming, and test.”
Iterations are typically from one to four weeks, with the
goal of delivering “a stable, integrated, and tested partially
complete system” (Larman, 2003, p. 10) with every iteration.
In other words, an always-functioning system acquires func-
tionality, in contrast to a collection of parts assembled at the
end. The user experience frames the scope of each activity and
sets priorities between them. The increments of functionality
come from knowing the organization’s goals for the product,
from knowing the needs and values of the end-user audience,
and from a negotiated balance between the two.
The most important elements to end users, which satisfy
long-term goals of the organization, can be focused on first. For
example, one project’s first iteration focused on the interface
for letting users retrieve information, even though there was
no back-end database. That interface was the core to meeting
the user and business goals and had to be right.
Iteration does not need to start with functionality. Before
programmers write any code or interface designers create screen
designs, initial iterations can explore the audience’s values and
reactions with lightweight prototypes. For example, industrial
design as practiced by the design firm IDEO (Kelley Littman,
2001) is highly iterative. Key interactions (as determined by re-
search into end user and company goals) are prototyped, eval-
uated, and refined repeatedly before engineering technology
begins. At the Rhode Island School of Design, “looks-like” and
“works-like” prototypes differentiate the user experience from
technological capabilities (Cottam, 2004). Returning to an earlier
example, exploratory iterations on the children’s art product
website with end-user participation could have revealed that
content meant for educators confused parents and children, or
they could have revealed that educator content gave the web-
site added authority.
Risk-driven and client-driven. Larman (2003, p. 12)
said, “Risk-driven iterative development chooses the riskiest,
most difficult elements for the early iterations [and] the choice
of features for the next iteration comes from the client—what-
ever they perceive as the highest business value to them.”
Treating both the end user experience of products and the
user experience of organizations as parts of the same idea helps
select among potential technological solutions. For example, a
company making software for transportation logistics spent a
calendar year, many developer years, and millions of dollars de-
veloping a complex feature that allows the system to send sig-
nal when cargo enters or leaves a certain geographic area. It
sounds like a good idea, but it took much longer than initially
18 • KUNIAVSKY
TABLE 1.11. Agile Development Practices,
Adapted from Larman (2003)
Iterative development
Risk-driven and client-driven
Timeboxing
Adaptive development
Evolutionary requirements](https://image.slidesharecdn.com/2323845-250519204738-65f60c7f/85/Humancomputer-Interaction-Development-Process-Sears-Andrew-39-320.jpg)
![estimated and several years after its launch, customers had not
broadly adopted it. User research with prototypes would have
revealed that the technology did not fit work practices and that
the business relationships did not support the information in
the form provided. In other words, it does not solve a prob-
lem that people feel they have, and their business systems (in-
cluding their business software) cannot use the information.
Although organizational desire was high, for customers the risk
of not doing it was low, thus the choice was neither risk-driven
nor client-driven.
Timeboxing. Agile methodologies depend on being able
to query a customer who interprets the user experience for the
developers and makes priority trade-offs (for example, when
something turns out to be harder than previously imagined).
“Fixing the iteration end date and not allowing it to change”
(Larman, 2003, p. 13) allows scheduled user research and or-
ganizational priority review. A regular research and release plan
allows for much easier integration of the results of user re-
search into the development process. Such timeboxing allows the
customer to plan for user research so that the results of the re-
search become available when questions arise. For example,
an Internet search engine with one-week iterations had a three-
week research cycle. The research answered user experience
questions posed by the developers, and upcoming features
were prototyped and tested before expending any program-
ming resources.
Adaptive development and evolutionary require-
ments. All of these practices boil down to two key concepts:
development practices dynamically adapt to new information
and requirements for the product change as knowledge about
the user experience increases.
Introducing User Experience into an Existing Process
We have to return to our entrepreneurial roots. (Highsmith, 2002)
There had been a growing sense among the Directors of the Product
Management Group that there was a diminishing atmosphere of inno-
vation within the group. (Fraser, 2005)
[To launch a brand new product] every mindset, timeline, and as-
sumption had to be challenged. (Pellican Homier, 2005)
Organizations regularly have crises where their leadership
feels they have lost the ability to innovate. Rediscovering inno-
vation is not impossible, merely difficult. Understanding the
user experience is returning to an organization’s entrepreneur-
ial, innovative roots. Once, the organization had insight into
the end-user needs and was able to balance those with its needs
to be come successful. It lost the ability to be innovative when
it lost that perspective.
No existing organization can change all its practices over-
night. People need to be convinced at both the organizational
and individual levels that there is value in change. On a new proj-
ect, it is easier to introduce new ways of creating, but everyone
hates change when there is momentum. Forcing people to
change in that situation almost never works, but introducing
practices that make people’s lives better and move the overall
practice in the right direction sometimes works (sadly, there are
no guarantees).
Development practices that expose the organization to user
experience ideas lay the foundation for a gradual shift in per-
spective. The following practices are not in any order. They are
ideas that seem to help organizations change from the inside out.
Get a senior manager champion. The preconditions
to a successful change are the recognition of a need to change
and the authority to make changes. Those with ultimate re-
sponsibility for the success of a product need to know that user-
experience research is a key business process. Embracing the
idea that the members of an organization are not representative
of its audience has to start from the top, with the recognition
by someone in a high-level position that they cannot manage
by merely extrapolating from their experience. Making senior
managers watch end user research is an effective and dramatic
exercise that demonstrates the difference between the percep-
tion of a product inside and outside an organization. Watching
someone struggle with a flagship application wins people over
to the idea that maybe they do not know everything about how
their end users view the world and the product. However, even
without this, enlightened managers realize there is value (both
for the organization as a whole and for their careers) in re-
searching and codifying the user experience. Such managers
make excellent champions within the organization. They are ex-
perts in the organization’s needs and can serve as guides and
translators, communicating issues to other managers, framing
ways to justify a practice that has no immediate return on in-
vestment, providing a voice of authority, and making re-
sources available for the pursuit of such research. Few projects
document their reliance on this relationship, but it is critical in
nearly every successful organizational change. Hollinger (2005)
said, “We requested management buy-in early on to be able to
treat user experience defects the same as any other product de-
fects. . . . This explicit support from a senior manager on the
project was critical to our success in this area.”
Work within existing processes. It is easy to dismiss
new ideas as unworkable within the structure of an existing
practice. Contextualize new practices in terms of the existing
development process. For example, one UI design team first in-
troduced a new practice—the keeping of user-experience
scorecards—but when the practice’s value became clear, the
traditional process owners took over:
Although the design team produced the scorecards, the release man-
agement team eventually took over “enforcement”, pushing teams to
turn their yellow and red bubbles to green. This “mainstreaming” of
the reviews resulted in significantly more user experience bugs being
fixed. (Hollinger, 2005, p. 9)
This allowed the team to gradually introduce the practice while
simultaneously showing its value. As the user experience spans
technical and organizational practices, integrating it into both of
those worlds produces the broadest effects. It can start by involv-
ing representatives from business units in the HCI research
1. User Experience and HCI • 19](https://image.slidesharecdn.com/2323845-250519204738-65f60c7f/85/Humancomputer-Interaction-Development-Process-Sears-Andrew-40-320.jpg)
![1. User Experience and HCI • 21
References
Agarwal, R., E. Karahanna. (2000). Time flies when you are having fun:
Cognitive absorption and beliefs about information technology
usage. MIS Quarterly, 24(4), 665–694.
Andelman, D. A. (2005, October 5). A better way to search? Retrieved
April 5, 2001, from Forbes.com
Apple Computer. (n.d.). Interface builder documentation. Retrieved
December 1, 2004, from http://developer.apple.com/tools/interface-
builder.html
Arnall, T. (2001). Mobile interaction design case study. Retrieved Octo-
ber 30, 2005, from http://www.elasticspace.com/2001/06/mobile-
interaction-design-case-study
Beck, K., Andres, C. (2004). Extreme programming explained:
Embrace change (2nd ed.). Reading, MA: Addison-Wesley.
Bellotti, V. (1999). Personal communication.
Bentley, R., Hughes, J. A., Randall, D., Rodden, T., Sawyer, P., Shapiro, D.,
et al. (1992, November). Ethnographically informed systems design
for air traffic control. Proceedings of the Conference on Computer
Supported Cooperative Work, Toronto, Canada, 123–129.
Berg, S., Taylor, A. S., Harper, R. (2003, April). Mobile phones for the
next generation: Device designs for teenagers. Proceedings of the
Conference on Human Factors and Computing Systems CHI 2003,
Fort Lauderdale, FL, pp. 443–440.
Beyer, H., Holtzblatt, K. (1998). Contextual design: Defining cus-
tomer-centered systems. San Francisco: Morgan Kaufmann
Buckman, R. (2002, June 14). Microsoft’s cable-TV miscues turned into
a costly lesson. Wall Street Journal.
Cockburn, A. (2004). Crystal clear: A human-powered methodology for
small teams. Reading, MA: Addison-Wesley.
Cottam, M. (2004, April). Reuse for new uses. Presentation at ICSID
Forum, CHI 2004, Vienna, Austria.
Davis, F. (1989). Perceived usefulness, perceived ease of use, and user
acceptance of information technology. MIS Quarterly, 14(3), 319–340.
Elliot, K., Neustaedter, C., Greenberg, S. (2005). Time, ownership and
awareness: The value of contextual locations in the home. Proceed-
ings of the Ubicomp 2005 conference, Tokyo, Japan, pp. 251–268.
European Information Technology Observatory. (2002). Yearbook (10th
ed.). Frankfurt: Author.
Fraser, J. (2005, November). Inspired innovation—How Corel is drawing
upon employees’ ideas for user focused innovation. Proceedings of
DUX05: Conference on Designing for User eXperience, San Fran-
cisco, CA, Electronic proceedings, ISBN 1–59593–250–X.
Garrett, J. J. (2000). Elements of user experience. Retrieved October
10, 2005, from http://www.jjg.net/elements/
Garrett, J. J. (2002). Elements of user experience. Indianapolis, IN: New
Riders Press.
Haeckel, S. (1999). Adaptive enterprise: Creating and leading sense-and-
respond organizations. Boston, MA: Harvard Business School Press
Hassenzahl, M. (2003). The Thing and I: Understanding the relationship
between user and product. In M. A. Blythe, A. F. Monk, K. Over-
beeke, P. C. Wright (Eds.), Funology: From usability to enjoyment.
Dordrecht, the Netherlands: Kluwer Academic.
Highsmith, J. (2002). Agile software development ecosystems. Reading,
MA: Addison-Wesley.
Hollinger, M. (2005, November). A process for incorporating heuristic
evaluation into a software release. Proceedings of DUX05: Confer-
ence on Designing for User eXperience, San Francisco, CA, Elec-
tronic proceedings, ISBN 1–59593–250–X.
Kelley, T., Littman, J. (2001). The art of innovation: Lessons in creativ-
ity from IDEO, America’s leading design firm. New York: Doubleday.
Krueger, R. A. (1988). Focus groups: A practical guide for applied
research. Newbury Park, CA: Sage Publications.
Kuniavsky, M. (2003). Observing the user experience: A practitioner’s
guide to user research. San Francisco, CA: Morgan Kaufmann.
Kuniavsky, M., Raghavan, S. (2005, November). Guidelines are a tool:
Building a design knowledge management system for programmers.
Proceedings of DUX05: Conference on Designing for User eXperi-
ence, San Francisco, CA, Electronic proceedings, ISBN 1–59593–
250–X.
Larman, C. (2003). Agile and iterative development: A manager’s
guide. Reading, MA: Addison-Wesley.
Leadley, B., Pao, H., Douglas, S. (2005, November). Creating a user
experience culture at a nonsoftware company. Proceedings of
DUX05: Conference on Designing for User eXperience, San Fran-
cisco, CA, Electronic proceedings, ISBN 1-59593-250-X.
Madison, D. S. (2005). Critical ethnography: Method, ethics, and per-
formance. Thousand Oaks, CA: Sage Publications.
Maslow, A. H. (1943). A theory of human motivation. Psychological
Review, 50, 370–396.
Millen, D. (2000, August). Rapid ethnography: Time deepening strate-
gies for HCI field research. Proceedings of DIS 2000: Designing
Interactive Systems , New York, NY, pp. 280–286.
Nass, C., Reeves, B. (1996). The media equation: How people treat
computers, televisions, and new media as real people and places.
Cambridge, MA: Cambridge University Press.
Norman, D. A. (1998). The invisible computer. Cambridge, MA: MIT
Press.
Ortony A., Norman, D. A., Revelle, W. (2005). Affect and proto-affect in
effective functioning. In J. M. Fellous M. A. Arbib (Eds.), Who needs
emotions? The brain meets the machine (pp. 173–202). New York:
Oxford University Press.
Pellican, S., Homier, M. (2005, November). Customer driven innova-
tion: Quicken(r) rental property manager. Proceedings of DUX05:
Conference on Designing for User eXperience, San Francisco, CA,
Electronic proceedings, ISBN 1–59593–250–X.
Pine, B. J., Gilmore, J. H. (1999). The experience economy. Boston,
MA: Harvard Business School Press.
Postrel, V. (2003). The substance of style: How the rise of aesthetic value
is remaking commerce, culture and consciousness. New York:
HarperCollins.
Public Broadcasting System. (2004). Best practices for PBS member sta-
tions. Retrieved December 1, 2005, from http://www.pbs.org/remote
control/bestpractices/
Rafaeli, Y., Vilnai-Yavetz, I. (2004). Emotion as a connection of physical
artifacts and organizations. Organizational Science, 15, 6.
Saffer, D. (2002, June 3). Building brand into structure. Boxes and
Arrows. Retrieved October 28, 2005, from http://www.boxesand
arrows.com/archives/building_brand_into_structure.php
Sawhney, M. (2003, July 1). Fundamentals of Value. CIO Magazine.
Schmitt, B. H. (2003). Customer experience management: A revolu-
tionary approach to connecting with your customers. San Francisco,
CA: John Wiley Sons.
Schwaber, K., Beedle, M. (2001). Agile software development with
SCRUM. Upper Saddle River, NJ: Prentice Hall.
Spool, J. (2005, August 10). Re:[Sigia-L] Length of nav Labels. Message
posted to Sigia-L electronic mailing list, archived at http://www.info-
arch.org/lists/sigia-l/0508/0157.html
TiVo. (2005, August 24). Press release.
U.S. General Accounting Office. (1996). Content analysis: A method-
ology for structuring and analyzing written material (GAO/PEMD-
10.3.1). Washington, DC: Author.
Vredenburg, R., Isensee, S., Righi, C. (2001). User-centered design: An
integrated approach. Upper Saddle River, NJ: Prentice Hall.](https://image.slidesharecdn.com/2323845-250519204738-65f60c7f/85/Humancomputer-Interaction-Development-Process-Sears-Andrew-42-320.jpg)
![Task Requirements
Besides the users themselves and the environments they work
in, the tasks they do also have their own inherent requirements.
One compelling example of the need for a thorough under-
standing of users’ tasks to achieve usable design comes from
one of the earliest books on computer-human interaction (Ru-
binstein Hersh, 1984, p. 26).
For example, recently a water district in Maine installed an
online billing system so that when a customer called in, the
clerk could quickly retrieve a record of usage and billing for that
customer. The managers noticed that the clerks were less than
happy with the new system. A little investigation revealed that
with the manual system, the clerks would write pertinent infor-
mation in the margins of the records, such as that one person
pays on the 15th of the month rather than on the first, or that
the meter reader should contact the neighbor across the street
for access to a house. This informal information was critical to
the smooth operation of the office, but because there was no
provision for it in an official field of the payment-record form,
the information was lost in the conversion to the online sys-
tem. Understanding that there is informal as well as official in-
formation and recognizing the importance of the former would
have reduced the disruption in work style.
Another good example of what can be missed by not under-
standing users’ tasks is found in Coble, Karat, and Kahn (1997).
This report described the use of task-analysis techniques to
study the functional requirements of physicians for a clinical
workstation:
Before the . . . session started, a physician explained the purpose and
details of each section in his office chart. . . . Later, when he was doing
actual work in context, the person performing the . . . session noticed
that the note he was looking at was written with red ink. She probed
and the physician said it told him the previous encounter with this pa-
tient was a hospital visit. That fact told him he needed to review the hos-
pital discharge summary and hospital laboratory results before enter-
ing the patient’s exam room. The physician was surprised that he had
not mentioned that need before. It was so ingrained in how he worked
that he did not even process that highly relevant detail consciously any-
more. (p. 231) [Italics mine.]
In another example from my own experience, I was once
performing a requirements analysis in a police department and
observing police officers using a system of standardized paper
forms to document property. I observed infrequent users of the
forms struggling with them; there were many complex forms
and many undocumented rules about how to fill them out. Later
I observed very frequent users using them. The frequent users
tended to ignore the forms initially and take freeform notes de-
scribing the property they had to document in a format very dif-
ferent from that required on the forms. They then transcribed
their own notes onto the forms as required. It was clear from
this observation (and from follow-up interviews with the fre-
quent users) that the forms were not designed in a way that sup-
ported the users’ task, and I learned a lot from how frequent
users worked around the forms with their own format that
helped in designing better online forms. A traditional systems
analysis would typically not involve studying users actually using
paper forms in their actual work, but would have instead taken
the paper forms themselves as a description of the work to be
automated. Problems with the forms would have been missed
entirely and perpetuated in the online version of the task.
There are always a great many things like this that users sim-
ply will not think to report during an offsite interview or “focus
group” that only emerge during in-context observations of peo-
ple doing real work in their workplaces. Such things can have
major implications for product user interface design.
Here is another example, this time from the context of a cus-
tomer service application in an insurance company. In the navi-
gational model illustrated in Fig. 2.2, the free text in normal in-
tensity represents the basic user tasks identified from initial
in-context observations with users. The bold text in boxes rep-
resents the hierarchy of groups that the design team developed,
with labels they created—again, all based on initial task analysis
activities. (This hierarchy represents only a partial set of the func-
tionality required by a Customer Support Rep. For simplicity, not
all groups or low-level tasks are included in the example.)
In contrast to the designer-generated model in Fig. 2.2, Fig.
2.3 shows a user-generated model. Again, the free text in nor-
mal intensity represents the low-level tasks presented to the
user, each one on a separate index card. This time the bold text
in boxes represents the groups that one user formed from the
low-level tasks, with labels they suggested.
The differences between the designer-generated model and
the user-generated model of these tasks are significant.
For example, the design team organized all types of Changes
(e.g., Address, Beneficiary) under a single category (“Change
Requests”) within the category Sales Support, whereas this user
distinguished between those changes that have to do with
30 • MAYHEW
FIGURE 2.2. A Designer’s Navigational Model. Admin ⫽
Administration; App ⫽ application; Mgmnt ⫽ management.](https://image.slidesharecdn.com/2323845-250519204738-65f60c7f/85/Humancomputer-Interaction-Development-Process-Sears-Andrew-51-320.jpg)
Humancomputer Interaction Development Process Sears Andrew
- 1. Humancomputer Interaction Development Process Sears Andrew download https://ebookbell.com/product/humancomputer-interaction- development-process-sears-andrew-4647690 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Humancomputer Interaction In Game Development With Python Design And Develop A Game Interface Using Hci Technologies And Techniques 1st Edition Joseph Thachil George https://ebookbell.com/product/humancomputer-interaction-in-game- development-with-python-design-and-develop-a-game-interface-using-hci- technologies-and-techniques-1st-edition-joseph-thachil-george-43238120 Humancomputer Interaction In Game Development With Python Design And Develop A Game Interface Using Hci Technologies And Techniques 1st Edition Joseph Thachil George https://ebookbell.com/product/humancomputer-interaction-in-game- development-with-python-design-and-develop-a-game-interface-using-hci- technologies-and-techniques-1st-edition-joseph-thachil-george-43537828 Humancomputer Interaction Design And Development Approaches 14th International Conference Hci International 2011 Orlando Fl Usa July 914 2011 Proceedings Part I 1st Edition Ben Shneiderman Auth https://ebookbell.com/product/humancomputer-interaction-design-and- development-approaches-14th-international-conference-hci- international-2011-orlando-fl-usa-july-914-2011-proceedings- part-i-1st-edition-ben-shneiderman-auth-2449764 Humancomputer Interaction User Interface Design Development And Multimodality 19th International Conference Hci International 2017 Vancouver Bc Canada July 914 2017 Proceedings Part I 1st Edition Masaaki Kurosu Eds https://ebookbell.com/product/humancomputer-interaction-user- interface-design-development-and-multimodality-19th-international- conference-hci-international-2017-vancouver-bc-canada- july-914-2017-proceedings-part-i-1st-edition-masaaki-kurosu- eds-6616756
- 3. Humancomputer Interaction Theory Design Development And Practice 18th International Conference Hci International 2016 Toronto On Canada July 1722 2016 Proceedings Part I 1st Edition Masaaki Kurosu Eds https://ebookbell.com/product/humancomputer-interaction-theory-design- development-and-practice-18th-international-conference-hci- international-2016-toronto-on-canada-july-1722-2016-proceedings- part-i-1st-edition-masaaki-kurosu-eds-5485084 New Trends On Humancomputer Interaction Research Development New Tools And Methods 1st Edition Sandra Baldassarri https://ebookbell.com/product/new-trends-on-humancomputer-interaction- research-development-new-tools-and-methods-1st-edition-sandra- baldassarri-1080362 Universal Access In Humancomputer Interaction Design And Development Methods For Universal Access 8th International Conference Uahci 2014 Held As Part Of Hci International 2014 Heraklion Crete Greece June 2227 2014 Proceedings Part I 1st Edition Constantine Stephanidis https://ebookbell.com/product/universal-access-in-humancomputer- interaction-design-and-development-methods-for-universal-access-8th- international-conference-uahci-2014-held-as-part-of-hci- international-2014-heraklion-crete-greece-june-2227-2014-proceedings- part-i-1st-edition-constantine-stephanidis-4697338 Universal Access In Humancomputer Interaction Design And Development Approaches And Methods 11th International Conference Uahci 2017 Held As Part Of Hci International 2017 Vancouver Bc Canada July 914 2017 Proceedings Part I 1st Edition Margherita Antona https://ebookbell.com/product/universal-access-in-humancomputer- interaction-design-and-development-approaches-and-methods-11th- international-conference-uahci-2017-held-as-part-of-hci- international-2017-vancouver-bc-canada-july-914-2017-proceedings- part-i-1st-edition-margherita-antona-6616842 Human Computer Interaction New Developments Kikuo Asai https://ebookbell.com/product/human-computer-interaction-new- developments-kikuo-asai-2625840
- 7. Human Factors and Ergonomics Series Editor Published Titles Conceptual Foundations of Human Factors Measurement, D. Meister Designing for Accessibility: A Business Guide to Countering Design Exclusion, S. Keates Handbook of Cognitive Task Design, E. Hollnagel Handbook of Digital Human Modeling: Research for Applied Ergonomics and Human Factors Engineering, V. G. Duffy Handbook of Human Factors and Ergonomics in Health Care and Patient Safety, P. Carayon Handbook of Human Factors in Web Design, R. Proctor and K. Vu Handbook of Standards and Guidelines in Ergonomics and Human Factors, W. Karwowski Handbook of Virtual Environments: Design, Implementation, and Applications, K. Stanney Handbook of Warnings, M. Wogalter Human-Computer Interaction: Designing for Diverse Users and Domains, A. Sears and J. A. Jacko Human-Computer Interaction: Design Issues, Solutions, and Applications, A. Sears and J. A. Jacko Human-Computer Interaction: Development Process, A. Sears and J. A. Jacko Human-Computer Interaction: Fundamentals, A. Sears and J. A. Jacko Human Factors in System Design, Development, and Testing, D. Meister and T. Enderwick Introduction to Human Factors and Ergonomics for Engineers, M. R. Lehto and J. R. Buck Macroergonomics: Theory, Methods and Applications, H. Hendrick and B. Kleiner The Handbook of Data Mining, N. Ye The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies, and Emerging Applications, Second Edition, A. Sears and J. A. Jacko Theories and Practice in Interaction Design, S. Bagnara and G. Crampton-Smith Usability and Internationalization of Information Technology, N. Aykin User Interfaces for All: Concepts, Methods, and Tools, C. Stephanidis Forthcoming Titles Computer-Aided Anthropometry for Research and Design, K. M. Robinette Content Preparation Guidelines for the Web and Information Appliances: Cross-Cultural Comparisons, Y. Guo, H. Liao, A. Savoy, and G. Salvendy Foundations of Human-Computer and Human-Machine Systems, G. Johannsen Handbook of Healthcare Delivery Systems, Y. Yih Human Performance Modeling: Design for Applications in Human Factors and Ergonomics, D. L. Fisher, R. Schweickert, and C. G. Drury Smart Clothing: Technology and Applications, G. Cho The Universal Access Handbook, C. Stephanidis
- 8. Edited by Andrew Sears Julie A. Jacko Human- Computer Interaction Development Process CRC Press is an imprint of the Taylor & Francis Group, an informa business Boca Raton London New York
- 9. This material was previously published in The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applica- tions, Second Edition, © Taylor & Francis, 2007. CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2009 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Printed in the United States of America on acid-free paper 10 9 8 7 6 5 4 3 2 1 International Standard Book Number-13: 978-1-4200-8890-8 (Hardcover) This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint. Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.copyright.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation with- out intent to infringe. Library of Congress Cataloging-in-Publication Data Human-computer interaction. Development process / editors, Andrew Sears, Julie A. Jacko. p. cm. -- (Human factors and ergonomics) “Select set of chapters from the second edition of The Human computer interaction handbook”--Pref. Includes bibliographical references and index. ISBN 978-1-4200-8890-8 (hardcover : alk. paper) 1. Human-computer interaction. I. Sears, Andrew. II. Jacko, Julie A. III. Human-computer interaction handbook. IV. Title: Development process. V. Series. QA76.9.H85H85653 2009 004.01’9--dc22 2008050945 Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the CRC Press Web site at http://www.crcpress.com
- 10. For Beth, Nicole, Kristen, François, and Nicolas.
- 12. vii CONTENTS Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Advisory Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii About the Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Section I—Requirements Specification 1 User Experience and HCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Mike Kuniavsky 2 Requirements Specifications within the Usability Engineering Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 Deborah J. Mayhew 3 Task Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Catherine Courage, Janice (Genny) Redish, and Dennis Wixon 4 Contextual Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 Karen Holtzblatt 5 An Ethnographic Approach to Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Jeanette Blomberg, Mark Burrel Section II—Design and Development 6 Putting Personas to Work: Using Data-Driven Personas to Focus Product Planning, Design, and Development . . . . . . . . . .95 Tamara Adlin and John Pruitt 7 Prototyping Tools and Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 Michel Beaudouin-Lafon and Wendy E. Mackay 8 Scenario-based Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145 Mary Beth Rosson and John M. Carroll 9 Participatory Design: The Third Space in HCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165 Michael J. Muller 10 Unified User Interface Development: New Challenges and Opportunities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187 Anthony Savidis and Constantine Stephanidis 11 HCI and Software Engineering: Designing for User Interface Plasticity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211 Jöelle Coutaz and Gäelle Calvary Section III—Testing and Evaluation 12 Usability Testing: Current Practice and Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231 Joesph S. Dumas and Jean E. Fox 13 Survey Design and Implementation in HCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253 A. Ant Ozok 14 Inspection-based Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273 Gilbert Cockton, Alan Woolrych, and Darryn Lavery 15 Model-Based Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293 David Kieras Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311 Subject Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323
- 14. CONTRIBUTORS Tamara Adlin adlin inc., USA Michel Beaudouin-Lafon Université Paris—Sud, France Jeanette Blomberg IBM Almaden Research Center, USA Mark Burrell Microsoft, USA Gaëlle Calvary Université Joseph Fourier, France John M. Carroll College of Information Sciences and Technology, The Pennsylvania State University, USA Gilbert Cockton School of Computing and Technology, University of Sunderland, UK Catherine Courage salesforce.com, USA Joëlle Coutaz Université Joseph Fourier, France Joseph S. Dumas Bentley College, USA Jean E. Fox Bureau of Labor Statistics, USA Karen Holtzblatt InContext Enterprises, Inc., USA David Kieras Electrical Engineering and Computer Science Department, University of Michigan, USA Amy Kruse Defense Advanced Research Projects Agency, USA Mike Kuniavsky ThingM, USA Darryn Lavery Microsoft Corporation, USA Wendy E. Mackay INRIA, France Deborah J. Mayhew Deborah J. Mayhew and Associates, USA Michael J. Muller IBM Research, USA A. Ant Ozok Department of Information Systems, UMBC, USA John Pruitt Microsoft Corporation, USA Janice (Ginny) Redish Redish & Associates, Inc., USA Mary Beth Rosson College of Information Sciences and Technology, The Pennsylvania State University, USA Anthony Savidis Institute of Computer Science, Foundation for Research and Technology—Hellas (ICS-FORTH), Greece Constantine Stephanidis Institute of Computer Science, Foundation for Research and Technology—Hellas (ICS-FORTH), and Department of Computer Science, University of Crete, Greece Dennis Wixon Microsoft Game Studios, Microsoft Corporation, USA Alan Woolrych School of Computing and Technology, University of Sunderland, UK ix
- 16. xi ADVISORY BOARD Noëlle Carbonell University Henri Poincaré–Nancy 1, LORIA, CNRS & INRIA, France Stuart Card User Interface Research Group, Palo Alto Research Center (PARC), USA John M. Carroll College of Information Sciences and Technology, The Pennsylvania State University, USA Jim Foley Georgia Institute of Technology, USA Ephraim P. Glinert National Science Foundation, USA Vicki L. Hanson IBM T.J. Watson Research Center, USA John Karat IBM T.J. Watson Research Center, USA Waldemar Karwowski Center for Industrial Ergonomics, University of Louisville, USA Sara Kiesler HCI Institute, Carnegie Mellon University, USA Arnold Lund Mobile Platforms Division, Microsoft, USA Aaron Marcus Aaron Marcus and Associates, Inc., USA Dianne Murray Independent Consultant, UK Jakob Nielsen Nielsen Norman Group, USA Gary M. Olson School of Information, University of Michigan, USA Judith S. Olson School of Information, Ross School of Business, and Department of Psychology, University of Michigan, USA Sharon Oviatt Department of Computer Science and Engineering, Oregon Health and Science University, USA Fabio Paternò Laboratory on Human Interfaces in Information Systems, ISTI–C.N.R., Italy Richard Pew BBN Technologies, USA Dylan Schmorrow Office of Naval Research (ONR), USA Michael Smith Department of Industrial and Systems Engineering, University of Wisconsin–Madison, USA Kay Stanney Industrial Engineering and Management Systems, University of Central Florida, USA Constantine Stephanidis Institute of Computer Science, Foundation for Research and Technology-Hellas (ICS-FORTH) Department of Computer Science, University of Crete, Greece Peter Thomas Carey Thomas Pty Ltd., Australia Susan Wiedenbeck College of Information Science and Technology, Drexel University, USA Hidekazu Yoshikawa Department of Socio-Environmental Energy Science, Kyoto University, Japan
- 18. xiii PREFACE We are pleased to offer access to a select set of chapters from the second edition of The Human–Computer Interaction Hand- book. Each of the four books in the set comprises select chapters that focus on specific issues including fundamentals which serve as the foundation for human–computer interactions, design is- sues, issues involved in designing solutions for diverse users, and the development process. While human–computer interaction (HCI) may have emerged from within computing, significant contributions have come from a variety of fields including industrial engineering, psychology, education, and graphic design. The resulting inter- disciplinary research has produced important outcomes includ- ing an improved understanding of the relationship between people and technology as well as more effective processes for utilizing this knowledge in the design and development of so- lutions that can increase productivity, quality of life, and com- petitiveness. HCI now has a home in every application, envi- ronment, and device, and is routinely used as a tool for inclusion. HCI is no longer just an area of specialization within more traditional academic disciplines, but has developed such that both undergraduate and graduate degrees are available that focus explicitly on the subject. The HCI Handbook provides practitioners, researchers, stu- dents, and academicians with access to 67 chapters and nearly 2000 pages covering a vast array of issues that are important to the HCI community. Through four smaller books, readers can access select chapters from the Handbook. The first book, Hu- man–Computer Interaction: Fundamentals, comprises 16 chap- ters that discuss fundamental issues about the technology in- volved in human–computer interactions as well as the users themselves. Examples include human information processing, motivation, emotion in HCI, sensor-based input solutions, and wearable computing. The second book, Human–Computer In- teraction: Design Issues, also includes 16 chapters that address a variety of issues involved when designing the interactions be- tween users and computing technologies. Example topics in- clude adaptive interfaces, tangible interfaces, information visu- alization, designing for the web, and computer-supported cooperative work. The third book, Human–Computer Interac- tion: Designing for Diverse Users and Domains, includes eight chapters that address issues involved in designing solutions for diverse users including children, older adults, and individuals with physical, cognitive, visual, or hearing impairments. Five additional chapters discuss HCI in the context of specific do- mains including health care, games, and the aerospace industry. The final book, Human–Computer Interaction: The Develop- ment Process, includes fifteen chapters that address require- ments specification, design and development, and testing and evaluation activities. Sample chapters address task analysis, contextual design, personas, scenario-based design, participa- tory design, and a variety of evaluation techniques including us- ability testing, inspection-based techniques, and survey design. Andrew Sears and Julie A. Jacko March 2008
- 20. xv Andrew Sears is a Professor of Information Systems and the Chair of the Information Systems Department at UMBC. He is also the director of UMBC’s Interactive Systems Research Cen- ter. Dr. Sears’ research explores issues related to human-cen- tered computing with an emphasis on accessibility. His current projects focus on accessibility, broadly defined, including the needs of individuals with physical disabilities and older users of information technologies as well as mobile computing, speech recognition, and the difficulties information technology users experience as a result of the environment in which they are working or the tasks in which they are engaged. His research projects have been supported by numerous corporations (e.g., IBM Corporation, Intel Corporation, Microsoft Corporation, Motorola), foundations (e.g., the Verizon Foundation), and government agencies (e.g., NASA, the National Institute on Disability and Rehabilitation Research, the National Science Foundation, and the State of Maryland). Dr. Sears is the author or co-author of numerous research publications including jour- nal articles, books, book chapters, and conference proceedings. He is the Founding Co-Editor-in-Chief of the ACM Transactions on Accessible Computing, and serves on the editorial boards of the International Journal of Human–Computer Studies, the In- ternational Journal of Human–Computer Interaction, the In- ternational Journal of Mobil Human–Computer Interaction, and Universal Access in the Information Society, and the advi- sory board of the upcoming Universal Access Handbook. He has served on a variety of conference committees including as Conference and Technical Program Co-Chair of the Association for Computing Machinery’s Conference on Human Factors in Computing Systems (CHI 2001), Conference Chair of the ACM Conference on Accessible Computing (Assets 2005), and Pro- gram Chair for Asset 2004. He is currently Vice Chair of the ACM Special Interest Group on Accessible Computing. He earned his BS in Computer Science from Rensselaer Polytechnic Institute and his Ph.D. in Computer Science with an emphasis on Hu- man–Computer Interaction from the University of Maryland— College Park. Julie A. Jacko is Director of the Institute for Health Informatics at the University of Minnesota as well as a Professor in the School of Public Health and the School of Nursing. She is the author or co-author of over 120 research publications including journal arti- cles, books, book chapters, and conference proceedings. Dr. Jacko’s research activities focus on human–computer interaction, human aspects of computing, universal access to electronic in- formation technologies, and health informatics. Her externally funded research has been supported by the Intel Corporation, Microsoft Corporation, the National Science Foundation, NASA, the Agency for Health Care Research and Quality (AHRQ), and the National Institute on Disability and Rehabilitation Research. Dr. Jacko received a National Science Foundation CAREER Award for her research titled, “Universal Access to the Graphical User in- terface: Design For The Partially Sighted,” and the National Sci- ence Foundation’s Presidential Early Career Award for Scientists and Engineers, which is the highest honor bestowed on young scientists and engineers by the US government. She is Editor-in- Chief of the International Journal of Human–Computer Interac- tion and she is Associate Editor for the International Journal of Human Computer Studies. In 2001 she served as Conference and Technical Program Co-Chair for the ACM Conference on Human Factors in Computing Systems (CHI 2001). She also served as Program Chair for the Fifth ACM SIGCAPH Conference on Assis- tive Technologies (ASSETS 2002), and as General Conference Chair of ASSETS 2004. In 2006, Dr. Jacko was elected to serve a three-year term as President of SIGCHI. Dr. Jacko routinely pro- vides expert consultancy for organizations and corporations on systems usability and accessibility, emphasizing human aspects of interactive systems design. She earned her Ph.D. in Industrial Engineering from Purdue University. ABOUT THE EDITORS
- 24. ◆ 1◆ USER EXPERIENCE AND HCI Mike Kuniavsky ThingM Corporation 3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 The Boundaries of User Experience . . . . . . . . . . . . . . . . . 4 UX Is Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Garrett’s Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 The Organizational Experience . . . . . . . . . . . . . . . . . . . . 5 The 1927 Ford ModelT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 A Children’s Art Product Manufacturer Website . . . . . . . . . 6 The User View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 The User Experience of Products . . . . . . . . . . . . . . . . . . . . 7 Affect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 The User Experience of Organizations . . . . . . . . . . . . . . . . 8 Brand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Examining the User Experience . . . . . . . . . . . . . . . . . . . 11 Identifying Organizational Goals . . . . . . . . . . . . . . . . . . . . 11 Identify stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . 11 Collect stakeholder goals . . . . . . . . . . . . . . . . . . . . . . 12 Prioritize organizational goals . . . . . . . . . . . . . . . . . . . 12 A rapid technique:Project history . . . . . . . . . . . . . . . 12 Field Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Find key informants,schedule research . . . . . . . . . . . 14 Narrow the focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 User interactive observation . . . . . . . . . . . . . . . . . . . . 15 Use multiple researchers and analyze collaboratively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Focus Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Prepare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Make a schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Pick an audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Develop discussion topics . . . . . . . . . . . . . . . . . . . . . 17 Write a discussion guide . . . . . . . . . . . . . . . . . . . . . . .17 Analyze results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Manage With User Experience . . . . . . . . . . . . . . . . . . . 17 Agile User Experience Development . . . . . . . . . . . . . . . . 18 Iterative development . . . . . . . . . . . . . . . . . . . . . . . . . 18 Risk-driven and client-driven . . . . . . . . . . . . . . . . . . . 18 Timeboxing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Adaptive development and evolutionary requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Introducing User Experience Into an Existing Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Get a senior manager champion . . . . . . . . . . . . . . . . . 19 Work within existing processes . . . . . . . . . . . . . . . . . 19 Make small,but well-publicized changes . . . . . . . . . . 20 Make developers’lives easier with user experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 25. INTRODUCTION The goal for this chapter is to introduce concepts and tech- niques that help structure the application of HCI in a real-world environment by examining the larger context in which HCI hap- pens and by using that context as the basis for the design of user experiences. Understanding the broader factors that influence the user ex- perience is as important for creating successful HCI systems as thoroughly understanding the cognitive science behind the user’s actions. Company goals, economic relationships, emo- tional responses, and social interactions can overwhelm behav- ioral and perceptual responses of consumers. Although inten- sive research is currently investigating some of these ideas, the majority of firsthand experience of and thinking about design- ing experiences under such pressures has happened in the con- sumer marketplace as documented in popular business and marketing literature. In bringing these ideas and experiences to this volume, I hope to introduce the process of HCI as part of a broader activity: specifically, the development and creation of user experience in a consumer economy. THE BOUNDARIES OF USER EXPERIENCE The definition of user experience (UX) and its relationship to HCI is complex. Both fields share boundaries with a number of other fields, and each other. On one hand, either field can re- semble anthropology, cognitive psychology, industrial design, or computer science in practice. On the other, customer relation- ship management and marketing play a large role in actual day- to-day experiences with products and services. Consulting for a broad range of organizations on projects ranging from con- sumer products for broad audiences to highly focused products for internal use has shaped thinking about the definition of the term. User experience is a set of broader considerations than HCI. It aggregates and contextualizes HCI by incorporating the concerns of both end users and organizations. In other words, the user experience consists of all of the factors that influence the relationship between the end user and an organization, es- pecially when a product1 mediates that relationship. UX Is Context From the users’ perspective, their experiences are continuous. The products, their immediate environments, and their lives all interact and feed back on one another. On the most basic level, what someone understands about a product affects what he or she finds attractive about the product, and what is attractive af- fects his or her willingness to understand it. How much de- pends on the rest of the context, but it is a mistake to think that only the look or the functionality matters. It all matters, and re- search and iterative design determine to what degree. Many seemingly stand-alone products now are merely ways to access services provided by organizations. End users’ rela- tionships to an experience and the organizations creating the experience intertwine more than ever (see Table 1.1). In the days of traditional industrial manufacturing (roughly before 1970), end users of a product may have only had one interac- tion with an organization: the store from which they bought it, which may have also provided support and repair services. Pack- aged software included three or more: the store that sold the hardware, the store that sold the software, and the providers of technical support. With the introduction of web-based software interactions, the number of organizations increased, with the addition of an ISP and website provider. Modern mobile phone based applications may involve even more: a handset manufac- turer, an operating system developer, a network provider, an ap- plication developer, and a content provider. All of these orga- nizations contribute to the end-user experience, often without a lot of coordination between them. HCI is part of a technology creation process. Like any tech- nology creation process, doing it right requires not only au- tomating a certain set of tasks, but also inventing tools that intro- duce new possibilities for both the people using them and the organizations creating them. In such a multilayered environment, product development can go in many directions, and research can be conducted almost ad infinitum. However, in the end, lim- ited resources require choosing one promising direction. User experience design and research is a pragmatic pursuit. Its goal should be the understanding of the experience of tech- nology users and technology-producing organizations to man- age the risks of technology creation and increase the chances of success. Garrett’s Elements Garrett (2000, 2002) developed a model (see Fig. 1.1) for un- derstanding how various aspects of product design interact to create a whole user experience. Garrett (2000, 2002) focused on web design, but his model extended to most other kinds of user experience. It described 4 • KUNIAVSKY 1 I define product broadly. A product represents the interface between an organization and end users. It could be a physical object, a service, a system, software, or a combination of these. For example, an ATM consists of three elements: the machine itself, the card used to access it, and the service that it enables access to. However, it is a single product, especially from the perspective of the end user. More often, it is a single definable entity, but seemingly, stand-alone artifacts regularly turn out to belong to a system of interlocking, interdependent elements. TABLE 1.1. Organizations Involved in End-User Relationships Product Organizations Involved Traditional technology Sales/Repair product Traditional desktop Sales, Support software Website Internet Service Provider, Website Provider Mobile Handset manufacturer, Network provider, Application provider, Content provider
- 26. the dependencies connecting abstract business and user goals to visual design through a set of intermediate steps. These steps describe the information that a product provides and describe how people interact with that information. Productivity prod- ucts (the left-hand column, defined as “web as software inter- face”) emphasize the content less than the interaction, while information products (“web as hypertext system”) emphasize the content more than the interaction. The diagram defines stages in understanding and managing this process, and emphasizes that factors that are unrelated to ergonomics or functionality constrain end-user experience. It implies that good HCI is a subset of good product development, and inseparable from the larger context. The outer layers in Garrett’s diagram hide the inner ones from both users and from the organization at large. Users only see the visual design layer, while organizations only see the website objectives layer. However, the user experience depends on a cascading se- quence of assumptions and decisions. These are constrained by economic factors imposed by the organization and psychological or sociological factors imposed by users and society. These eco- nomic, psychological, and sociological factors tell at least half of the story of the complete user experience. They define the con- text in which decisions are made and the product actually ex- perienced, and they should be the ones in which it is designed. THE ORGANIZATIONAL EXPERIENCE End users are not the only customers of a given piece of tech- nology. Technology creation solves two sets of problems: one for the people using it, and another for the organization creat- ing it. HCI research and design often assumes that an organiza- tion’s goal is to provide optimal end-user experiences, but many other factors drive organizational motivations. Organizations’ needs and desires2 frame and prioritize product research and 1. User Experience and HCI • 5 FIGURE 1.1. Garrett’s elements of user experience diagram (Garrett, 2000). 2 Hassenzahl (2003) used pragmatic and hedonic product attributes to discuss roughly these same concepts. His terms refer to individuals’ per- spectives in the abstract, but I prefer to use needs and desires because these terms better frame discussions from users’ perspectives and work better when discussing the parallel between an organization’s perspective and that of the user of its product.
- 27. development as much as users’ abilities and goals, which are the traditional realm of HCI. An organization creates a product because it desires some- thing from a user base. The difficulty is that the user base often desires something different. The resolution of these two dis- junctive desires deeply affects the final user experience. For this reason, user-experience design and research starts with orga- nizational strategy. This example from industrial design foreshadows many of today’s HCI and user experience issues 80 years earlier. The 1927 Ford Model T The Ford Model T was an incredibly successful car, and the first killer app of the 20th century. Throughout the 19 years it was manufactured, its design remained unchanged, except for one thing: Every year, it was cheaper than the year before. From the perspective of Model T users, it was a great vehicle: reliable, pre- dictable, and inexpensive. However, by the mid-1920s, it was not selling well relative to many of its competitors, and Ford dis- continued it in 1927 (Wikipedia, 2005a). Henry Ford refused to value anything but efficiency (for his company and its cus- tomers) in his products. However, by the mid-1920s Ford’s com- petitors were selling more cars by evolving the look and feel every year (styling in automotive terminology). The goal went beyond making cars more efficient or cheaper to making them look different. Having realized that people treated cars as ex- pressions of identity, the competitors included styling as a key part of the user experience. Ford had many options they could have pursued in response to the economic pressure put on them by the profits lost to com- petitors. They could have restructured their manufacturing processes to make Model Ts even cheaper. They could have low- ered the quality of their product to increase their margins; they could have embarked on a research and development program to merge their car, tractor, and airplane products, so they would only produce one product. They could have laid-off workers and decreased the number of cars they were producing and so on. Each plan would have differently affected the driver experience. Ford’s decision was to stop making the Model T and introduce the 1928 Model A, a car with competitive styling (available in four colors, none of them the black of the Model T; Wikipedia, 2005b). Ford’s industrial designers then updated the styling of their cars on a regular basis as their competitors did. Beginning user experience evaluation by analyzing the spon- soring organization’s motivations regularly reveals the issues that pervade the assumptions behind the product. Introducing subtle changes in core assumptions, as Henry Ford’s son Edsel (then the President of Ford) did in 1927, can change the expe- rience of the entire product without having to rethink the whole user interface (because the problem may not be in the inter- face at all). A Children’s Art Product Manufacturer Website A maker of children’s art products wants a new information ar- chitecture for their website. The website has three audiences (children, educators, and parents and grandparents), and more than 200 different kinds of content. With such a depth of infor- mation and such a broad audience, there is no obviously canon- ical way to structure the content. The historical function of the website as a sales channel directed toward parents and educa- tors guided all of the initial architecture choices. However, in- terviews with company executives responsible for the website revealed that these assumptions were either inaccurate or in- appropriately emphasized. Most mistaken was the belief that the site had to be a revenue source. In fact, the Chief Financial Officer (CFO) flatly stated that the website’s goal is to spread the company’s brand identity as broadly as possible among its pri- mary audience. In its incarnation, the website met neither the goals of the original development team nor its actual goal as a brand vehicle. Throughout the product’s development lifecycle, internal expectations and assumptions guide the experience it creates in subtle ways. In this example, the information architecture for a website was distorted by the explicitly stated goal of revenue production, even though the organization’s leaders had changed their goals. When expectations contain internal conflicts, they produce contradictory and confusing interactions. Organizations have to put themselves first, even when cre- ating products for end users. For example, Southwest Airlines policy allows customers to apply the price of an unused ticket to another ticket. However, the company profits if people do not take them up on the offer. Thus, it is not in the best inter- est of the company to make it easy to perform the transaction. As of October 2005, Southwest.com allows the user to trans- fer funds from an unused ticket only if they have the exact con- firmation number of the unused ticket and the exact spelling of the name associated with it—even if they have an account on the Southwest website and the system database can pull up all of the other account information. The Web-site interface makes transferring funds difficult because the interface ulti- mately serves the company’s financial interests, not those of the customer. User experience defines the boundaries of product develop- ment through stakeholder needs and end-user goals. These needs and goals are not just management requests or customer complaints. They represent the core of how the organization defines success and what end users expect the product will do for them. Applying the tools of user experience research and design to the organization is tricky. Looking closely at organizational assumptions and expectations steps right into in-house poli- tics—that aspect of collaborative work that everyone would prefer did not exist—and can create interpersonal tension. However, unstated internal priorities often inhibit successful user experience design more than any external factor, so they are important to investigate. Fixing office politics is outside this chapter’s scope and most readers’ job descriptions, but explic- itly clarifying an organization’s priorities is well within the ca- pability of an HCI professional. In fact, it is critical. As we have seen, confusing, conflicting, and ambiguous organizational agendas produce conflicting product requirements, which in turn produce difficult to use interfaces. Knowing organiza- tional needs helps balance the needs of users and organiza- tions in design. 6 • KUNIAVSKY
- 28. THE USER VIEW As stated above, factors that affect an end user’s experience are not just those that determine the efficiency of the interface in enabling task completion. Functionality is, of course, critical to the continued product viability—it needs actually to do something—but viability is more than functionality. We all will- ingly enter into experiences (buy products, use services, etc.) that are far from functionally optimal, and yet we leave satis- fied. Agarwal and Karahanna (2000) defined the concept of “cognitive absorption,” which seems like a good way to de- scribe the main goal of product designers and developers, as “A state of deep involvement . . . exhibited through temporal dissociation, focused immersion, heightened enjoyment, con- trol, and curiosity.” Few products regularly produce cognitive absorption. In or- der to understand why, it is valuable to define some other terms describing important aspects of the user experience from the user’s perspective. Ortony, Norman, and Revelle (2005, p. 174) proposed a model that describes “an organism’s” (e.g., a person’s) psycho- logical function in the world. The model’s four (continually in- terrelating) parts are: • Affect—what the organism feels • Motivation—what the organism needs and wants • Cognition—what the organism knows, thinks, and believes • Behavior—what the organism does Product design implicitly takes all of these factors3 into con- sideration, but explicit examination of them is rare. Marketing researchers investigate motivation; interaction designers use their knowledge of cognition; usability research focuses on be- havior; and visual or identity designers and advertising agen- cies try to influence motivation through affect. However, that is an ideal situation. In reality, the practice of understanding and structuring a unified experience is so new that design generally runs on gut-level intuition, and everyone is guessing at every- thing. Gut-level decision making is not necessarily bad. Humans are often good at predicting other humans’ reactions—except when intuition totally fails. The User Experience of Products Affect. According to Ortony et al. (2005), emotional re- sponse, or affect, is a complex interaction of immediate reac- tions modulated by experience with previous situations and cognitive predictions of future states, all of which happens rapidly and simultaneously. Immediate feelings, emotions, and moods are different states operating at different levels of gran- ularity. They are also critical to people’s experiences of a product. When people fall in love at first sight with a product or a place, their successive experiences will not be moderate. The emo- tions may lead them to overlook interaction problems or poor functionality. Later, the emotional state may wear off, the hon- eymoon ends, and the inadequacies of the product turn joy into disillusionment. Davis (1989, p. 320) showed that “both perceived usefulness and perceived ease of use were significantly correlated with self- reported indicants of system use.” People’s emotional relation- ships to products before they had the opportunities to use them affected how they used them later. Zhang and Li (2005, p. 106) extended Davis’ research by applying a more primal con- cept, affective quality. They investigated the perceived affective quality of software products and concluded, “a user’s immedi- ate and reflexive affective reaction to [information technology] has a positive impact on his or her consequent cognition-oriented evaluations of the [technology].” Furthermore, Nass and Reeves (1996) described in detail how people exhibited many of the same emotional responses to computers, televisions, and films as they did to other humans, significantly changing their expectations and behaviors toward the technology as a result. What constitutes affective quality (which is measured in terms of valence and activation; e.g., the direction and magni- tude of the emotional response) in terms of technological prod- ucts is still under investigation. However, evaluating and de- signing the complete user experience clearly requires close consideration of the experience’s affective aspects. Value. People act for a reason. They engage with products or experiences for some reason (or reasons), they keep using them for other reasons, and they stop for others still. In the largest context, Maslow’s (1943) hierarchy of needs serves as one model of how what people value in their lives motivates their actions. Norman et al. (2005) described how one kind of motivation, curiosity, could arise from an emotional response to an environment. “Animals’ motivation systems [let] the resting point of affect be slightly positive so that when there is nothing that needs to be done, the animal is led to explore the environ- ment” (Ortony et al., 2005, p. 194). However, pure curiosity rarely leads people to have new ex- periences or to continue well-known experiences. When using a household appliance, for example, curiosity rarely drives peo- ple’s behavior. From a product developer’s perspective, a good approximation of motivation is what creates value for the end user. Value consists of two elements: • The product’s perceived potential for changing a customer/ user’s life • How well it satisfies that potential Perceived potential consists of three elements: functional, economic, and psychological (Sawhney, 2003). The functional aspect is the prospective user’s expectation about whether the product will be able to solve a real-world problem the person 1. User Experience and HCI • 7 3 These terms are a framework for the subsequent discussion. They are not defined in the same rigorous, technical way that Norman et al. (2005) defined them in their work. The definitions provided here are the more common dictionary definitions, which are a superset of how Norman et al. defined them.
- 29. is having. “Will the disk utility program recover my thesis?” or “Will the personal video recorder let me watch The Simpsons at 3 A.M.?” The economic aspect consists of the cost-benefit analysis that a prospective buyer of a product does when considering whether purchasing the product will be worth the opportunity cost of spending money on it. This is the literal, most traditional, definition of value. “Will this CRM system let me shave 25% off of my expenses?” The psychological aspect contains all of the hopes that some- one has for how owning or using a thing will change his or her life and is both the most difficult to understand and the po- tentially most important. It holds all of the emotional attach- ment, all of the social pressure, and all of the personal desires that make up someone’s self-image, as they are contemplating buying, and then using, a product. Some consumer objects, such as the Nokia 7280 phone (see Fig. 1.2), evoke much more about their values than they communicate about their function- alities. Designed as fashion items, much of their functionalities are the same as that for garments: They explicitly project an im- age of their users to both others and the users. However, these same ideas apply to ostensibly purely func- tional products. Every underused enterprise software product is the result of a perceived value that did not match the reality of the situation on the ground, often for reasons that were nei- ther functional nor economic. The design of the user experience is the practice of creating products that satisfy perceived value. What brings people value changes with context is that, at different places and times, people will have different values. There is a lifecycle to expectations dictated by habituation. As same people grow accustomed to a product’s functionality, its novelty wears off. For a long time, the Model T satisfied what consumers wanted in a car. For 19 years, Henry Ford thought only the price of the car had to change, but consumers clearly thought differently. As the automobile’s functionality became commonplace, people’s relationship to it changed. They began to focus on the psychological needs it satisfied and to see it less as a tool they were using and more as part of who they were. People desire variety (Postrel, 2003), and the black Model T no longer satisfied. Car buyers were willing to pay extra for a dif- ferent user experience, but Ford did not recognize this until it was almost too late. Blindness to the larger user experience also exists in the de- velopment of software products. The business press regularly describes the struggle between well-established companies and their younger competitors. Such stories typically describe a company with an older product whose target audience no longer wants sees value in the user experience their product provides. The older company clearly produced good user value at one point, or else they would not have had the success that allowed them to be in a threatened leadership position. Their products changed their audience’s expectations, but then the company failed to notice when expectations moved on. For ex- ample, Yahoo! search technology was lagging in the early 2000s when compared to Google’s. At one point, Yahoo! was a dom- inant player in the search market, but by 2005, they got to the point where, “The company is doing everything that the fertile imaginations of their software engineers can muster in order to persuade people to search with them first” (Andelman, 2005). Likewise, organizations also often produce products for which the market is not yet ready. In 2005, a number of large organizations invested in entertainment PCs, which look like stereo equipment, and associated products, such as media servers, but, to the puzzlement of the companies making these services, there was a lack of widespread adoption of such services in the past (Buckman, 2002). These products’ unpop- ularity may have had nothing to do with the feature set or its pre- sentation. The makers of these products should not necessarily have been doing any more usability testing or focus groups. The interface for the TiVo (2005) personal video recorder was widely praised by both interaction designers and users, but it took the company eight years to achieve profitability. It may be that pa- tience is an ingredient in the user experience of these products before they appear worthwhile to a broad audience. As Sawhney (2003) described, the process of creating cus- tomer value in technology products requires understanding the interaction of all the elements that make the product desirable: According to HP, the benefits of the iPaq are its powerful processor, bright screen, expandability and flexibility—a statement of functional value. But to close a sale, HP must also demonstrate economic value with quantified estimates of improved productivity for end users as well as application developers. And HP must convince customers of the emotional benefits of choosing a device platform that is backed by rep- utable and financially solid companies such as HP and Microsoft. (Sawhney, 2003) Creating a user experience requires understanding this entan- glement of ideas as well as HP did in creating the iPaq. The User Experience of Organizations Brand. Brand identity generally refers to the combination of all the implicit values an organization communicates about itself, as understood by the consumers of that organization’s products or services. Symbols such as logos and slogans evoke brand identity, but the actual identity is the set of values that people project onto an organization, and by extension, onto its products based on per- sonal experiences with that organization and its advertising. In terms of the user experience, brand identity creates expectations for the value that an organization’s products will provide to the 8 • KUNIAVSKY FIGURE 1.2. Nokia 7280 phone.
- 30. end user. As such, it is an important component in setting people’s expectations for how to approach a product and what the product will do for them economically, functionally, or psychologically. Brands live in the minds and expectations of the buyers and users of an organization’s products and services. A logo can evoke a set of feelings and expectations for the value that a product will give someone, but it is not the actual value. The product still has to provide the value, although often that value is not in terms of the actual functionality, but rather in the emo- tional satisfaction that owning, using, or being seen with a product brings. This aspirational component of a brand is the emotional value the audience perceives the product will deliver. In that sense, it is the perceived affective quality of all of the products produced by an organization. Products that do not meet brand expectations can either disappoint or confuse users. During the dot-com boom of the late 1990s, many companies attempted business models that took their brands well outside of people’s existing expectations for them. For example, when Intel, a chipmaker, partnered with toy manufacturer Mattel, it seemed like a good way to merge cutting edge technology with toy manufacturing. The partnership pro- duced several products under the Intel Play brand (Fig. 1.4). However, sales of the toys did not meet expectations, and the partnership was dissolved. As with any enterprise, the circum- stances were complex, but one of the potential problems may have been that the Intel brand strongly connoted an entirely dif- ferent set of values than was appropriate for the sale of toys. As manufactured and sold by Digital Blue (Fig. 1.3), an educational toy company founded to market and develop the products from the failed venture, the products developed by Intel Play are see- ing financial success. This shows that the entire hierarchy of Garrett’s (2000) Elements can be satisfied on a functional level, but if the total user experience does not fulfill the user’s larger expectations, products can still fail. Good experiences while using a product will affect people’s perceptions of the organization that produced it, which in turn affects their expectations for the functionality of other prod- ucts that the company produces. Bad experiences with a ser- vice, such as documented in Rafaeli and Vilnai-Yavetz (2004), can lead to a wholesale dissatisfaction with other products that the organization produces, irrespective of those products’ im- mediate user experience. From an HCI perspective, understanding and incorporating brand identity into the experience is important. As Saffer (2002) said, “Navigation, nomenclature, and content presentation must also reflect the company’s brand. The most elegant visual de- sign in the world isn’t going to overcome inappropriate inter- action design.” For example, knowing the children’s art product manufac- turer (previously mentioned) was more interested in commu- nicating the company brand than producing revenue changed the direction of the user experience dramatically. Websites in- tended to efficiently sell products that are designed to be purely functional, whereas one intended to evoke a sense of playfulness, whimsy, and creativity (the psychological values the company in question tried to communicate) is much dif- ferent. Compare the McMaster-Carr website, which has been a very successful sales website (Spool, 2005), to the site for the Lego toy company (see Fig. 1.5 and Fig. 1.6). The interaction design, the organization of the content, the kind of content presented, and the visual design of individual interface elements of the two websites differ not just because the audience differs or the products differ (though those dif- ferences are undeniably important) but also because the mes- sage they want to communicate differs. Compare the Carhartt clothing company’s websites in the United States to that in Eu- rope (see Fig. 1.7 and Fig. 1.8). In the United States, Carhartt is branded primarily as a work wear manufacturer, while in Eu- rope, it is a fashion brand for urban youth. 1. User Experience and HCI • 9 FIGURE 1.3. The Digital Blue Digital Movie Creator, II. FIGURE 1.4. The Intel Play Digital Movie Creator.
- 31. Relationships. In today’s world, we rarely interact with an organization only once. The process of buying, owning, using, and maintaining a product, whether software or an appliance, consists of many interactions with an organization. Customer re- lationship management (Wikipedia, 2005c) and customer ex- perience management (Wikipedia, 2005d) practices define these interactions as contact points or touch points (Schmitt, 2003). These practices aim to analyze and design positive expe- riences during these interactions. In fact, some theories (Pine & Gilmore, 1999) claim these interactions are even more im- portant than the products that spark them. The mobile phone is an example of the numerous customer relationships involved in owning and using a contemporary product. Although technically a computer, a mobile phone is not just a computational tool. Its functionality as a tool and as a communication medium completely depends on the services accessible through a handset. In a sense, it is the physical man- ifestation of a set of virtual, continually shifting services (as evi- denced by the complexity of subscription plans). Without the services, a phone handset is useless. However, the network does not just provide transparent connectivity; the ecology of organizations involved in delivering the mobile user experience is fragmented (Fig. 1.9), and none of the players is wholly responsible for the HCI. Mobile user-experience design processes require an under- standing of the relationship between various organizations and the way in which users will interact with them. Knowing these contact points can focus and prioritize the HCI research and design. Arnall (2001) cited constraints imposed network 10 • KUNIAVSKY FIGURE 1.5. McMaster-Carr website homepages. FIGURE 1.7. Carhartt U.S. website homepages. FIGURE 1.8. Carhartt Europe website homepages. FIGURE 1.6. Lego website hompages.
- 32. performance, billing, and hardware limitations in creating an SMS-based service. Creating a satisfying user experience re- quired determining both user’s experience with each of those contact points and the integration of all of them. For example, the design of the service had to include both interaction and financial incentives for people to sign up for the service (the signup process was made to be quick and the service was ini- tially free). The exact nature of contact points will vary based on the details of the service or product under consideration, but it typi- cally involves • Customer service • Billing • Sales • Account management • Marketing To some extent, this has always been true in all HCI devel- opment, but it has not been a prime focus of the research and design process. In an ecology of many interacting services, such as described above, ignoring the other players in the environ- ment is no longer optional. When such a service provides a so- lution to an end user, the solution cannot just be evaluated through the completion of a narrow set of tasks. It needs to be analyzed in the improvement it makes in the life of the person who uses it. People must find value throughout their interaction with it, whether through the out of box experience (Wikipedia, 2005e) in unpacking the product, or how they feel as they are using it, or their interactions with the product and the organi- zation during a technical support call. Industrial designers and architects have addressed these is- sues for a long time, recognizing that the evolving roles their products play in people’s lives are not always possible to pre- dict or design to the last detail. They have focused on creat- ing user experiences that offer multiple channels of value (rarely in monetary terms, but by a combination of affective and functional ideas). Salespeople and marketers have ap- proached the experience from the other direction. They try to identify the interactions people have with an organization, to understand the value (in monetary terms) of those interac- tions, and to maximize their monetary values or to minimize their expenses. Computer interfaces straddle both sides of the equation, providing immediate value for end-users and—especially in a dynamic networked environment such as that provided by mo- bile phones, ubiquitous computing, or the web—value for or- ganizations (whether monetary or, as in case of governments or nonprofit organizations, through other metrics that in- clude social goods). Integrating an analysis of the relation- ship between people and organizations as mediated by the in- terface is a key component to providing value to both groups. EXAMINING THE USER EXPERIENCE Approaching the investigation of such difficult to quantify ideas as affect and value is no small task. Organizations may be unable to articulate their intentions or values. Differentiating end users’ needs from their desires and their actual behavior from hope- ful visions is difficult. Further, the ambiguous nature of the col- lected data makes interpretations vary across interpreters. Ex- tracting quantitative information about a broad group of people takes an investment of extraordinary resources. However, the difficulty of collecting this information should not discourage you from trying to collect it. In order to reduce the risk of failure (though, sadly, probably not increase the risk of success), a model of the whole user experience such as Gar- rett’s (2000) is valuable. This section describes in detail several techniques for under- standing the organizational and user needs for the user experi- ence. They are by no means exhaustive, but they are included as examples of how to approach a user-experience research proj- ect, rather than focusing on fragmented tasks, and how to prag- matically apply the theory of the previous sections. Identifying Organizational Goals There are three steps to understanding organizational goals for a product: 1. Identifying stakeholders 2. Collecting stakeholder goals 3. Prioritizing among the goals Identify stakeholders. Start by identifying groups who most often own the product (or who most often care about the product). Make a list of all of the departments affected by the product’s success or failure and of who in each depart- ment is most responsible for it. If there is not a single person who is responsible for the product in a given department, find the person who dealt with it most recently. Odds are that this person regularly deals with it or can tell you who does. Product managers generally know which groups and 1. User Experience and HCI • 11 FIGURE 1.9. The mobile data value web (European Informa- tion Technology Observatory, 2002).
- 33. individuals have the biggest stake in the project and the list will likely contain: • Engineering4 • Design • Marketing Other groups can have stakes in the process, depending on the size/structure of the organization in the product’s success. A significant managerial presence in a product could be a major moneymaker (or loser) or if it is brand new. Each of these groups has a different perspective on the product. For example, a fictitious list of stakeholders (Table 1.2) for a web-based data warehousing application contains represen- tatives from identity design and marketing in addition to the people who actually build the product. Collect stakeholder goals. Once you have your list of stakeholders, find out what they consider the most important issues. You can do this either by getting all of the stakeholders together and spending an afternoon setting organization-wide priorities for the product or by speaking to each person inde- pendently. Individual interviews are often necessary with exec- utives, and it is critical that they are involved in this process. Ask each person (or department) 1. In terms of what you do on a day-to-day basis, what are the goals of this product? 2. Are there ways that it is not meeting those goals? If so, what are they? 3. Are there questions you want to have answered about it? If so, what are they? Every group will have different goals and will measure suc- cess differently. Programmers may measure success by the num- ber of bugs per thousand lines of code. Identity design may have internal reviews that evaluate how well the product inte- grates with the corporate brand. Customer support will want to minimize the number of questions they have to field. Sales will always want to bring in more revenue. Once you have spoken to the departmental representatives, make a list of the goals and desires. At this point, you will prob- ably see that some of the goals are contradictory. It is too early to attempt to resolve the contradictions, but investigating the relationship between them may be an important near-term goal for the project. Prioritize organizational goals. Based on your inter- views, you will have some idea of the corporate priorities with respect to the goals you have defined. Some things are impor- tant because the organization believes they prevent people from using a key feature. Others may be important because they dif- ferentiate the product from its competitors. Still others might be less important because they create a drain on resources or are currently a topic of debate within the company. There are many prioritization methods. Sometimes, just mak- ing a list is sufficient, but using a technique that abstracts key fac- tors can be useful. Table 1.4 explains one modified from the total quality management industrial manufacturing discipline. Using this technique, the questions in Table 1.3 could be prioritized, as in Table 1.5. Often, when prioritized systematically, it is easy to see why product development happens in the way it does. The lists show unstated company priorities come out and agendas that are or- thogonal to the organization’s actual needs. In retrospect, it is possible to see how decisions go against the product and orga- nization’s needs and how teams’ abilities produce the conditions that generate bad user experiences. Most importantly, tables such as these allow you to prioritize what you learn about user needs. A rapid technique: project history. It is not always possible to perform a rigorous investigation of an organization’s 12 • KUNIAVSKY 4 These terms are used here broadly. Engineering typically consists of programmers in a software or web environment but can include electrical and mechanical engineers in a hardware-development project. Likewise, design can include information architects, industrial designers, interaction de- signers, and visual designers. TABLE 1.2. List of Potential Stakeholders of a Fictitious Data Warehousing Application Alison, VP of Product Development Erik, Interaction Design Michel, Marketing Claire, Database Administration Ed, Customer Support Leif, QA Joan, Identity Design TABLE 1.3. A List of Goals and Questions of a Fictitious Data Warehousing Application Who Goals and Questions Alison, VP Product Fewer complaints from major clients Development Match data retrieval features offered by competitor Erik, Interaction Help construct more sophisticated reports, since Design the current interface does not reveal full report engine Why do so many people start and then abandon the query wizard? Michel, Marketing To show tight integration of the new report generator with the query system Claire, Database Is there a way to keep people from clicking the Administration search all button? It hammers the database every time. Ed, Customer Reduce support calls about report generator Support Shift more support from the phone to email Leif, QA Identify query wizard JavaScript errors to address user complaints Joan, Identity Make the look and feel of the acquired report Design generator match that of the query interface
- 34. needs. A fast way to understand the organization’s goals is to create a quick history of the project. The sequence of events that lead to the current situation reveals a set of problems and solutions, which in turn reveal the organization’s needs and values. The process is straightforward in principle, although the answers to basic questions can reveal complexities in priority and interest that a simple narrative explanation of the current situation does not. Getting a project history can be as simple as asking the following questions of the key stakeholders respon- sible for a project. The goal is to encourage them to describe the sequence that led to the current situation. • Why did you decide to do this? • Why did you decide to do it now? • Who initiated the project? • What was the organizational pressure that suggested it? The idea is to ask these questions (which are just a variant on the standard who/what/when/why interrogatives) recursively. In other words, for every answer, it is possible to ask the same questions to get an even older, and maybe deeper, set of moti- vations. Some techniques recommend doing a certain number of times (four seems to be common), but going deeply on a couple of key ideas is usually enough to understand the deeper motivations and constraints underlying the current situation. One variant that has proved useful is to ask to include anyone mentioned into the conversation. “Oh, so Lucie suggested that PCB designers weren’t using the spec sheets, which is why we are trying to make them more prominent. Could we talk to her about how she determined that they were not using them enough?” It could be that Lucie has stacks of e-mails from cus- tomer service in which people ask for information that is readily available, or maybe she just has a hunch. In the former case, the information in the e-mail could be valuable in determining users’ expectations from the service; in the latter case, under- standing Lucie’s motivations provides information about how she measures success or envisions the purpose of the service. Field Observation Norman (1998) said, “The goal is to make the people who are being observed become participants in the discovery process of learning just what their real needs are—not the artificial needs proscribed by the way they do things today, but what the goals are, what they are striving for. This is the role of rapid ethnography.” A highly effective and increasingly popular method of ex- ploring the user experience comes from field-research tech- niques based on methods pioneered by anthropology, ethnog- raphy, and ethnomethodology. Examining work and life context produces a richer understanding of the relationships between preference, behavior, problems, and values. Laboratory and sur- vey methods extract people from their environments to focus on individual tasks or perspectives or aggregate responses from many people. Field observation’s goal is to gain insight into the total relationship between the elements of the user experience as experienced and understood in the context of use. Rather than trying to validate theories in a controlled setting, these ethnography-derived methods, including contextual in- quiry (Beyer & Holzblatt, 1998), derive insight through direct observation of people in their actual environment with (ideally) little presumption about their behavior and needs. Direct observation removes much of the bias that creeps into research when people or tasks are isolated. Outside of the envi- ronment that triggers them, our explanations of desires, values, reactions and behaviors, especially in routine events, lose criti- cal details by our tendency to simplify, idealize, and project. Ex- ploring the context of activities can identify people’s larger goals through the small details. For example, when someone leaves a note on a kitchen counter, the goal is not to just to leave the mes- sage, but rather to communicate something specific to a mem- ber of the household (even him- or herself). The message may be a to-do list, a reminder, or an alert (Elliot, Neustaedter, & Greenberg, 2005), and its location communicates how to inter- pret the message. When discussing domestic communications 1. User Experience and HCI • 13 TABLE 1.4. A Prioritization Technique 1. Make a column next to your list of questions and label it “Desire.” Go down the list and negotiate with the group a rating for each item on a scale of one to five. Five means the feature affected is a must have, critical to the success of the product, and one means it is nice to have, but not essential. 2. Next, make a second column and label it “Risk.” This will reflect how bad the problem is. Write a number on a one to five scale here, too. Five represents bad problems (ones that either directly affect the bottom line right now or represent major malfunctions), and one refers to problems that are annoyances or information that would be good to know. 3. Finally, make a column and label it “Ease.” This is how easy your team feels it will be to address the problem. Five means that it is easy to do, and one means that it is very difficult. 4. Multiply the three entries in the columns, and write the result next to them in a third column called “Priority.” This combines and amplifies the factors. Ordering the list by the last column gives you a starting order in which to investigate the product’s user experience. TABLE 1.5. The Prioritization Technique from Table 1.4 Applied to the Questions in Table 1.3 Goal Desire Risk Ease Total Match data retrieval features 4 3 2 24 offered by competitor Why do so many people start and 4 5 4 80 then abandon the query wizard? To show tight integration of the 3 3 4 36 new report generator with the query system Is there a way to keep people from 5 5 3 75 clicking the search all button? It hammers the database every time. Reduce support calls about 2 4 2 16 report generator Identify query wizard JavaScript 3 2 5 30 errors to address user complaints Make the look and feel of the 5 2 4 40 report generator match the query interface
- 35. outside the context of their daily routine, critical details such as spatial placement, time of day, materials used, or triggering event can be lost. Direct observation identifies emotional reactions that would be otherwise difficult to capture. For example, Vrendenburg, Righi, and Isensee (2001) described a situation where a t-shirt included in the packing material of an IBM RS/6000 computer led to surprise and delight from users—signs of a good user ex- perience—just unpacking the box: Users opened the product box to find a t-shirt, a mouse pad, a copy of Wired magazine, and games that showcased the 3D graphics capabilities of the system such as Quake. This approach to design worked beauti- fully. It became cool to have an RS/6000. One of the most common ques- tions asked by customers in the feedback survey was “Where can I get another t-shirt”? (p. 34) This was an unexpected observation that was not part of a focused program of focused ethnographic observation of peo- ple’s experiences unpacking RS/6000 computers, but it is repre- sentative of the kinds of things such observation produces. In an- other instance, Berg, Taylor, and Harper (2003) observed the following relationships between UK teenagers and their mobile phones: [The] text messages that were exchanged were sometimes described as objects that evoked particular memories. The messages were the embodiment of something personal that could be stored, retrieved, reread and shared, becoming tangible mementos for individuals and groups. Thus, the phone appeared to provide a means to participate in social exchange in so far as it enabled particular objects to take on symbolic meaning and for the objects to be seen as meaningful be- tween people. (p. 434) Such insights map directly to user experience design (as the authors then proceeded to do). They allow technology to en- able specific, observed behaviors in the context they occur, rather than hypothetical behaviors and assumed needs. Field research methods for user-experience design are typi- cally neither as detailed, data-heavy, or analytically rigorous as formal ethnography (Bentley et al., 1992). These techniques fo- cus on pragmatic on the ground observation and interpretation within the context of a development and production process. They use standardized methods and seek to identify contact points, activity sequences, artifacts, and values in the context of work practices. Beyer and Holzblatt’s (1998) contextual inquiry is probably the most prevalent of these techniques. Generalized from rapid ethnography (Millen, 2000), Table 1.6 lists a set of steps for conducting field research. Find key informants, schedule research. Millen (2000) recommended identifying informants and asking them to serve as guides through a field observation. He suggested that guides should be “people with access to a broad range of people and activities and be able to discuss in advance where in- teresting behaviors are most likely to be observed or where ac- tivities that reveal social tension are most likely to be found” (Millen, 2000, p. 282). For example, when observing technol- ogy in a hospital, it pays to talk to a nurse who works there, or if investigating hobbyist PC case modification (casemod) cul- ture, it’s valuable to have a member of a club of modders intro- duce you to the hobby and the players in it. When choosing informants, you should pick at least five peo- ple or groups who resemble the people who will use your prod- uct or who will provide key insights. Overall, they should have the same profile as the eventual target audience, though fringe members of a group may be good informants and provide in- formation or exhibit behavior that typical group members will have internalized. The breadth and depth of research will determine the extent of the study undertaken: long-term planning generally requires deeper insight and, thus, more and longer observation than short-term problem solving, for example. A typical month-long research schedule (Table 1.7) generally involves two to five hours per observation or interview period, followed by two to three hours of group analysis per hour of observation. Narrow the focus. The goal of traditional ethnographies is to understand as much as possible about the entire context in which a group of individuals acts, without judgment. In con- trast, most commercial research projects begin with an idea about what problems need solving and an idea about how to solve them. Field observation clarifies and focuses these ideas by discovering the situations in which these problems occur and how people deal with them. In addition, unlike an evaluative technique such as usability testing, it is observational and typi- cally uncovers unexpected directions. Thus, it is best done be- fore the process of creating solutions has begun when there is still time to iterate on research. This is usually at the beginning of the development cycle. However, in the interest of maximizing immediate results, the project typically concentrates on the fields of activity that will likely produce results that designers can incorporate into the user experience. Narrowing focus means identifying the im- portant aspects of your audience’s work or life practice, while leaving open the option to challenge assumptions. One tech- nique is for researchers to familiarize themselves closely with the terminology, tools, and techniques their audiences are likely 14 • KUNIAVSKY TABLE 1.6. Steps for Conducting Field Research, Adapted from Millen (2000) 1. Find key informants 2. Narrow the focus 3. Use interactive observation 4. Use multiple researchers and analyze collaboratively 5. Validate conclusions TABLE 1.7. Typical Field Research Schedule Timing Activity t 2 weeks Organize and schedule participants. t Begin observation. Begin analysis-scheduling process for development team. t 1 week Complete observation. Review videotapes and notes. Complete analysis scheduling. t 2 weeks Begin analysis. t 3 weeks Complete analysis.
- 36. to use. An informant can walk the researchers through some concepts before formalizing the research goals. The sports- caster method, where one informant explains what another one is doing, is another useful technique. For example, walking through a shopping district with a fashion-conscious teenage commentator can reveal a lot about where to look for interest- ing behaviors, rather than starting from scratch. With this information in mind, it’s possible to narrowly de- fine the aspect of the practice that you can ask questions about and observe. User interactive observation. This is the key to the technique, and it requires going to where people are engaged in the kind of activity the experience for which you are designing and asking them to teach you about their activities. Most of the time should be spent observing what the participants are doing, what tools they are using, and how they are using them. One effective technique is to take on the role of an apprentice and ask them to give a running description of what they are do- ing. As in an expert-apprentice relationship, this should be enough to describe the practice to the apprentice but not enough to interrupt the flow of the work. As an apprentice, you may occasionally ask for explanations, clarifications, or walk- throughs of actions, but do not let it drive the discussion. Observations can be in the form of structured interviews, with prewritten discussion guides. This is useful in answering specific questions, but risks missing key challenges to assump- tions. Other kinds of tools can elicit specific kinds of information (Beyer Holzlbatt, 1998; Millen, 2000), or aid in construct- ing models later (Wixon et al., 2002). An informant can use a pa- per model of a shop floor, for example, to describe activity in a factory than would be possible in the loud environment of the factory itself. Collect as much documentation of the practice as possible. Digital and video cameras, liberally used, provide both material for analysis and illustrations for presentation. Collect physical artifacts, when possible. For example, a group of researchers studying patterns of technology use in urban German areas took 400 photographs in a span of three hours and brought back posters, local handicrafts, and a pipe from a construction site. Use multiple researchers and analyze collabora- tively. Collecting and analyzing data simultaneously can pro- vide efficiency, though it introduces more potential biases to the interpretation of the observations (Madison, 2005). Techniques for group qualitative data analysis range from traditional tran- script coding methods (U.S. General Accounting Office, 1996) to contextual inquiry’s formal methods (Beyer Holzblatt, 1998) for constructing multifaceted models of users’ work prac- tices. Affinity diagrams are a particularly popular method. Table 1.8 describes the steps in the construction of an affinity diagram. It takes about one day. This rather mechanistic process yields good first-cut results about the breadth of the user experience, and frames subse- quent investigation. Validation. A key part of modeling is to evaluate the qual- ity of the model with the people whose lives it models. An im- mediate follow-up interview with in-depth questions can clarify a lot. Certain situations may not have been appropriate to in- terrupt (e.g., if you are observing a surgeon or a stock trader, that may apply to the whole observation period), whereas oth- ers may have brought up questions that would have interrupted the task flow. Conducting this interview while the participant’s memory of the event is still fresh will produce best results. “You’ll never understand what’s really going on until you’ve talked to people about what they are doing. The [follow-up] in- terview . . . gives you the rationale to make sense of things that might otherwise seem odd or insignificant” (Bellotti, 1999). Focus Groups5 People’s affective responses and values are hard to observe ob- jectively, and getting a subjective read is often all that is possible. Focus groups are structured group interviews that quickly and inexpensively reveal a target audience’s desires, experiences, priorities, and values. Sometimes vilified by their associations with dishonest marketing, they do not deserve their notoriety. They are neither the panacea for curing bad products nor pseu- doscientific voodoo to justify irrational decision making. When moderated well, carefully analyzed, and appropriately presented, they are an excellent technique for uncovering what people think about a given topic and, especially, how they think about it. A focus group reveals people’s perceptions of their values: what they feel right now and how they see that in relation to themselves. Those are crucial in understanding how an experi- ence will affect them. 1. User Experience and HCI • 15 TABLE 1.8. Affinity Diagram Construction, Adapted from Beyer and Holzblatt (1998) 1. Extract 50–100 notes from each interview. Notes are singular observations about tools, sequences, interactions—anything. Randomize them. 2. Get a group of people together in a room with a blank wall or a big whiteboard. Have them block out the whole day for the work. 3. Divide the group into pairs of analysts. Give each pair an equal number of notes. 4. Write one note on a Post-it and put it on the wall/window/board. 5. Tell the group to put notes that relate to that note around it one at a time. It does not matter how the notes relate as long as the group feels they relate. 6. If no more notes relate to a given note cluster, write a label summarizing and naming the cluster (use a different color so it’s easy to identify the labels). 7. Repeat the process with the other notes, labeling groups as they occur. 8. Generally, it is useful to break up groups of more than four notes into smaller clusters. However, there is no upper bound on how many notes may be in a group if there is no obvious way to break it up. 9. As the groups accumulate, Beyer and Holzblatt (1998) recommended using pink notes to label groups of blue notes and green notes to label groups of pink notes. 5 Much of this chapter is adapted from Kuniavsky, M. (2003).
- 37. In product development, focus groups are most useful early in the development cycle, when they generate ideas, prioritize features, and provide insight into people’s values and expecta- tions. They can reveal the features people value highest and why they value them, though not whether they will actually use them. As a competitive research tool, they uncover what peo- ple value in competitors’ products and where those prod- ucts fail. As Krueger (1988, p. 83) said, “The purpose of focus groups is not to infer, but to understand, not to generalize but to determine a range, not to make statements about the population but to provide insights about how people perceive a situation.” A focus group series is a sequence of tightly moderated group discussions among people taken from a thin slice of a product’s target audience. The goal is to encourage the partici- pants to feel comfortable revealing their thoughts and feelings by putting them in a group of people who are like them, or share an interest or an experience that directly relates to a prod- uct or an idea. Prepare. Focus group preparation consists of having sev- eral things: • A schedule. The best results come from situations where there has been enough time to examine the contingencies. A good schedule provides sufficient time for everything, es- pecially recruiting and guide writing, and enough slop to make a mistake or two. • The target audience. Who will be invited to participate? Specifically, you need to know the subset of the target audi- ence that is likely to give you the best feedback. • The research scope. Focus group series can have a few groups of a handful of people or as many as a dozen groups with ten or more participants apiece. The number of groups and peo- ple will depend on the complexity of your questions, the depth to which you want to explore the answers, and the cer- tainty with which you want to know these answers. More than four groups per audience are rarely necessary, but two are generally not enough. • Specific research topics. Not all groups feel equally comfort- able talking about all subjects and not all subjects lend them- selves to group discussion. Carefully chosen topics and a thought-through discussion guide yield the most information without sacrificing the depth of research or the clarity of the results. Make a schedule. A typical schedule for a focus group series takes about three weeks from beginning to end and should provide sufficient time for recruiting and writing the dis- cussion guide. The process is detailed in Table 1.9. Pick an audience. From your ideal target audience, you should choose a subset or several subsets that are likely to give you the most useful feedback. The right group will vary from sit- uation to situation. First, you need a solid profile of your target audience, complete with a thorough understanding of their de- mographic/technological makeup. For example, if you are just looking to find out what existing users value about your service, you want to pick the people who represent the largest subset of your actual audience. If you are looking to find whether a new audience will be interested in what you are developing, a clear specification of who are the potential users will be neces- sary and what factors will uniquely differentiate them from oth- ers. For example, when introducing a new product for use after a car accident, it is hard to get people to predict what they are going to need; however, talking to people who were in car ac- cidents recently may get an evaluation of what could have been useful. A sample profile is in Table 1.10. The perspective of the members of the subgroups defines similarity. A group of audiophiles will likely be comfortable to- gether regardless of age, whereas 20-year-old and 35-year-old urban restaurant goers probably have perspectives that differ enough to require multiple groups. If you feel that certain groups of people would not feel comfortable with each other, then do not put them together. Income, race, sex, class, age, job, and computer experience can play roles in how people interact in a group situation and how they react to a given user experience. 16 • KUNIAVSKY TABLE 1.9. Typical Focus Group Research Schedule Timing Activity t 2 weeks Determine audience and scope, start recruiting immediately t 2 weeks Determine broad topics to be investigated, start writing guide t 1 week Write first version of discussion guide, discuss exact topic wording with development team, check on recruiting t 3 days Write second version of discussion guide with timing, discuss with development team, recruiting should be completed t 2 days Complete guide, schedule run-through, set up, and check all equipment t 1 day Run-through in the morning, check times, and adjust guide questions as appropriate Do final recruiting check t Conduct groups (usually one to three days, depending on scheduling) Discuss with observers, collect copies of all notes t 1 day Relax. Do something else t 3 days Watch all tapes, take notes t 1 week Combine notes, write analysis TABLE 1.10. Sample Audience Profile for Focus Groups Participant Recruiting Age: 20 to 55 Gender: Separate groups for men and women Income: Household income over $70,000/year Computer use: Computer at home or work Internet use: Internet at home or work. One or more years’ experience. Five to ten hours per week for personal use (shopping, reading news, banking, etc.) Mobile use: Own a mobile phone, used nonvoice mobile services (played a game, SMS, etc.) one or more times in previous six months Behavior: Were in a noninjury auto accident in the previous 9–12 months, as driver
- 38. Develop discussion topics. For an average focus group, you should have three to five main topics to investigate. You should phrase topics in terms of the project as a whole. “Un- derstanding the mental model people use when researching in- surance” could be a goal for an insurance brokerage website, while a service that recommended home building contractors could be interested in “Knowing at which point people turn to an external service when doing home repair.” Focus these objectives enough that a group could adequately discuss each one in about 10 minutes. Do not phrase them as questions or issues that other methods (such as a survey) can better answer. A survey could make “A list of our competitors” better than focus groups, whereas “The factors that make Sony’s camera phone experience more compelling than ours” is more appropriate. Write a discussion guide. The discussion guide is a script for the moderator to follow. It creates a consistent frame- work for the focus group series by asking the same questions in the same order with much the same context. This allows a discussion to bring out the subtleties of the participants’ views without shortchanging any of the topics. Focus group discussion questions should be: • Carefully ordered. Questions get the participants thinking about certain issues and remembering certain events. A care- ful sequence of questions takes advantage of their frame of mind to make the flow of the group discussion feel more nat- ural, which in turn helps the participants to maintain a cre- ative flow of ideas and produce better insights. In general, questions should flow from the most general to the most spe- cific, with each question narrowing the discussion a bit. There should be planned transitions between topics unless introducing a brand new topic. • Nondirected. Questions should not imply an answer or present a value judgment. They should allow participants to fill in their own thoughts and values. For example, ask- ing, “Which do you think is a better search service, Google or Yahoo?” assumes that the participant feels there are ad- vantages of one over the other. Instead, frame questions neutrally: “Are there any things you like about using the Google search service? Are there things you like about Yahoo? What are they? Can you compare them? How do they compare?” • Open-ended. Avoid constraining answers to fixed responses. Longer, more open responses tell a greater part of the story and tend to be less ambiguous than shorter responses. Rather than phrasing a question in the form “Which of these camera functions are most important to you?” you could ask “Which functions do you use? How often?” • Focused on specifics. Conversely, encourage participants to be specific in their answers. Krueger (1988) recommended breaking down why questions into multiple what questions, explicitly asking for the influences that informed their deci- sion and the attributes of their decision. For example, “How did you decide to go shopping for a new phone plan?” and “What factors went into picking this carrier?” will provide bet- ter insight than “Why did you pick Cingular?” • Personal. Out of politeness people tend to generalize their experiences to the public at large or to some hypothetical audience which they are not part of. Since you want to know individual views, values, and experiences, emphasize individual experiences. Formulate question so that they con- centrate on people’s current and past behavior and opinions, without presenting the option to project. Thus, “If you had to redo your kitchen right now, which of these features would you use to find a home contractor?” is preferable to “Which of these features do you think are useful?” Granted, fulfilling all of these criteria with all questions is of- ten difficult (writing questions that are simultaneously specific and open-ended is a particularly tricky challenge), but they should be kept in mind as guidelines that should be followed whenever possible. Analyze results. There are as many ways of analyzing fo- cus group information as there are analysts. Since the informa- tion is, by definition, qualitative and contextual, the focus of the analysis will depend on the purpose of the group. One method consists of the following steps: • Quickly capture initial hypotheses. Immediately after the end of the focus groups, walk through the discussion guide section by section and ask the moderator and observers to re- call their thoughts about it: What was unexpected? What was expected but did not happen? What attitudes did people dis- play? What values did they espouse? What interesting state- ments did they make (and why were they interesting)? What trends did they observe? Which participants provided inter- esting feedback? What were the problems with the group? • Record the groups, and watch the recordings to verify hy- potheses. Merely remembering a situation can miss subtle be- haviors. Words are misquoted. Observers fall into groupthink. Reviewing the discussions clarifies ambiguities and reveals shades of meaning. MANAGE WITH USER EXPERIENCE When introducing a new technology into a marketplace, there is a risk of failure and of losing money and time on the investment in developing, marketing, and distributing the technology. It is of course possible to create successful technology without hav- ing a model of the end user’s or organization’s needs and de- sires. However, such successes are essentially the product of lucky accidents. When such success happens, the organization has to identify the elements that led to it. By this point, how- ever, the product’s success has permanently changed the mar- ket and the organization, and identifying what made it success- ful is difficult. This supply-first model depends on predictable markets and is passing. In the current environment, “business [needs to be] an adaptive system for responding to unantici- pated requests in unpredictable environments” (Haeckel, 1999, p. 10). Working from the user experience is essentially a demand- first philosophy, continually redefining product scope to reduce 1. User Experience and HCI • 17
- 39. the chances of failure and increase the chances of repeated suc- cesses. In other words, in an adaptive organization, the organi- zation adapts to the user experience. Organizations make technology for some reason, so user ex- perience is implicitly included in all technology creation. How- ever, explicitly basing every stage of technology development on user experience models is a relatively new concept. Though many organizations claim to be customer centered, in practice few product management practices actually make it the center of all of their activities. Most concentrate the examination of user and organizational needs at the beginning of a project (often called the “requirements gathering” phase) or at the end (the “evaluation” phase). Those are not the only options. Projects starting from scratch, where the technology is new and the de- velopment team is flexible, can use agile software development methods that introduce user-experience knowledge through- out the development process. However, mature products with long-established processes, attitudes, and methods often make starting from scratch impossible. This situation requires a differ- ent mix of techniques. Agile User Experience Development Henry Ford called his 1907 car the “Model T” because there was a model S before it, and a model R before that, all of the way back to the first Model A in 1903 (the 1928 Model A was a con- scious rebranding to evoke a new philosophy of building cars). In other words, Henry Ford failed 20 times over the course of four years at making a successful passenger car. He iterated, based on feedback, on the idea until he found the correct com- bination of factors. Iteration based on feedback is the core philosophy behind a family of software management practices called “agile software development.” Agile development does not require detailed re- search and design specifications up front or paper trails and sign-offs throughout. Instead, agile methods focus on exten- sive communication, rapid iteration, and continuously collect- ing information and adjusting to it, rather than trying to plan the entire process. As Highsmith (2002) described: Agility isn’t a one-shot deal that can be checked off the organizational initiative list. Agility is a way of life, a constantly emerging and changing response to business turbulence. Critics may counter, “Agility is merely waiting for bad things to happen, then responding. It is a fancy name for lack of planning and ad hoc-ism.” But agile organizations still plan; they just understand the limits of planning. (p. 16) Agile methodologies, which include Extreme Programming (Beck Andres, 2004), Scrum (Schwaber Beedle, 2001), and Crystal Clear (Cockburn, 2004), do not explicitly incorporate collecting and interpreting user-experience knowledge; rather, they continuously adapt to all new information. Larman (2003) defined a set of core agile practices, summa- rized in Table 1.11. Iterative development. Larman (2003, p. 9) said, “An ap- proach to building software (or anything) in which the overall lifecycle is composed of several iterations in sequence. Each it- eration is a self-contained mini-project composed of activities such as requirements analysis, design, programming, and test.” Iterations are typically from one to four weeks, with the goal of delivering “a stable, integrated, and tested partially complete system” (Larman, 2003, p. 10) with every iteration. In other words, an always-functioning system acquires func- tionality, in contrast to a collection of parts assembled at the end. The user experience frames the scope of each activity and sets priorities between them. The increments of functionality come from knowing the organization’s goals for the product, from knowing the needs and values of the end-user audience, and from a negotiated balance between the two. The most important elements to end users, which satisfy long-term goals of the organization, can be focused on first. For example, one project’s first iteration focused on the interface for letting users retrieve information, even though there was no back-end database. That interface was the core to meeting the user and business goals and had to be right. Iteration does not need to start with functionality. Before programmers write any code or interface designers create screen designs, initial iterations can explore the audience’s values and reactions with lightweight prototypes. For example, industrial design as practiced by the design firm IDEO (Kelley Littman, 2001) is highly iterative. Key interactions (as determined by re- search into end user and company goals) are prototyped, eval- uated, and refined repeatedly before engineering technology begins. At the Rhode Island School of Design, “looks-like” and “works-like” prototypes differentiate the user experience from technological capabilities (Cottam, 2004). Returning to an earlier example, exploratory iterations on the children’s art product website with end-user participation could have revealed that content meant for educators confused parents and children, or they could have revealed that educator content gave the web- site added authority. Risk-driven and client-driven. Larman (2003, p. 12) said, “Risk-driven iterative development chooses the riskiest, most difficult elements for the early iterations [and] the choice of features for the next iteration comes from the client—what- ever they perceive as the highest business value to them.” Treating both the end user experience of products and the user experience of organizations as parts of the same idea helps select among potential technological solutions. For example, a company making software for transportation logistics spent a calendar year, many developer years, and millions of dollars de- veloping a complex feature that allows the system to send sig- nal when cargo enters or leaves a certain geographic area. It sounds like a good idea, but it took much longer than initially 18 • KUNIAVSKY TABLE 1.11. Agile Development Practices, Adapted from Larman (2003) Iterative development Risk-driven and client-driven Timeboxing Adaptive development Evolutionary requirements
- 40. estimated and several years after its launch, customers had not broadly adopted it. User research with prototypes would have revealed that the technology did not fit work practices and that the business relationships did not support the information in the form provided. In other words, it does not solve a prob- lem that people feel they have, and their business systems (in- cluding their business software) cannot use the information. Although organizational desire was high, for customers the risk of not doing it was low, thus the choice was neither risk-driven nor client-driven. Timeboxing. Agile methodologies depend on being able to query a customer who interprets the user experience for the developers and makes priority trade-offs (for example, when something turns out to be harder than previously imagined). “Fixing the iteration end date and not allowing it to change” (Larman, 2003, p. 13) allows scheduled user research and or- ganizational priority review. A regular research and release plan allows for much easier integration of the results of user re- search into the development process. Such timeboxing allows the customer to plan for user research so that the results of the re- search become available when questions arise. For example, an Internet search engine with one-week iterations had a three- week research cycle. The research answered user experience questions posed by the developers, and upcoming features were prototyped and tested before expending any program- ming resources. Adaptive development and evolutionary require- ments. All of these practices boil down to two key concepts: development practices dynamically adapt to new information and requirements for the product change as knowledge about the user experience increases. Introducing User Experience into an Existing Process We have to return to our entrepreneurial roots. (Highsmith, 2002) There had been a growing sense among the Directors of the Product Management Group that there was a diminishing atmosphere of inno- vation within the group. (Fraser, 2005) [To launch a brand new product] every mindset, timeline, and as- sumption had to be challenged. (Pellican Homier, 2005) Organizations regularly have crises where their leadership feels they have lost the ability to innovate. Rediscovering inno- vation is not impossible, merely difficult. Understanding the user experience is returning to an organization’s entrepreneur- ial, innovative roots. Once, the organization had insight into the end-user needs and was able to balance those with its needs to be come successful. It lost the ability to be innovative when it lost that perspective. No existing organization can change all its practices over- night. People need to be convinced at both the organizational and individual levels that there is value in change. On a new proj- ect, it is easier to introduce new ways of creating, but everyone hates change when there is momentum. Forcing people to change in that situation almost never works, but introducing practices that make people’s lives better and move the overall practice in the right direction sometimes works (sadly, there are no guarantees). Development practices that expose the organization to user experience ideas lay the foundation for a gradual shift in per- spective. The following practices are not in any order. They are ideas that seem to help organizations change from the inside out. Get a senior manager champion. The preconditions to a successful change are the recognition of a need to change and the authority to make changes. Those with ultimate re- sponsibility for the success of a product need to know that user- experience research is a key business process. Embracing the idea that the members of an organization are not representative of its audience has to start from the top, with the recognition by someone in a high-level position that they cannot manage by merely extrapolating from their experience. Making senior managers watch end user research is an effective and dramatic exercise that demonstrates the difference between the percep- tion of a product inside and outside an organization. Watching someone struggle with a flagship application wins people over to the idea that maybe they do not know everything about how their end users view the world and the product. However, even without this, enlightened managers realize there is value (both for the organization as a whole and for their careers) in re- searching and codifying the user experience. Such managers make excellent champions within the organization. They are ex- perts in the organization’s needs and can serve as guides and translators, communicating issues to other managers, framing ways to justify a practice that has no immediate return on in- vestment, providing a voice of authority, and making re- sources available for the pursuit of such research. Few projects document their reliance on this relationship, but it is critical in nearly every successful organizational change. Hollinger (2005) said, “We requested management buy-in early on to be able to treat user experience defects the same as any other product de- fects. . . . This explicit support from a senior manager on the project was critical to our success in this area.” Work within existing processes. It is easy to dismiss new ideas as unworkable within the structure of an existing practice. Contextualize new practices in terms of the existing development process. For example, one UI design team first in- troduced a new practice—the keeping of user-experience scorecards—but when the practice’s value became clear, the traditional process owners took over: Although the design team produced the scorecards, the release man- agement team eventually took over “enforcement”, pushing teams to turn their yellow and red bubbles to green. This “mainstreaming” of the reviews resulted in significantly more user experience bugs being fixed. (Hollinger, 2005, p. 9) This allowed the team to gradually introduce the practice while simultaneously showing its value. As the user experience spans technical and organizational practices, integrating it into both of those worlds produces the broadest effects. It can start by involv- ing representatives from business units in the HCI research 1. User Experience and HCI • 19
- 41. process. Leadley, Pao, and Douglas (2005, p. 6) said, “You have to allot time and budget for the Business Analysts to attend user in- terviews and usability testing.” Later, it can progress to a more integrated approach: Getting the entire marketing, engineering, and quality assurance teams to watch customer-interview tapes and call the customers themselves was a wonderful achievement. All teams now require this to be part of a new product process. (Pellican Homier, 2005, p. 13) Another way is to use familiar tools to represent user expe- rience ideas. For example, Hollinger (2005) treated unmet user experience needs as “bugs” and used the internal bug-tracking system to keep track of them. Make small, but well-publicized changes. Persistent internal marketing is crucial to wide-scale adoption of user ex- perience ideas. Beginning with small projects, such as usability tests of existing projects, every report, presentation, and dis- cussion can highlight insights gleaned from user experience re- search and analysis, linked to organizational goals. For exam- ple, one group chose to share their findings with the executive staff. Hollinger (2005) said, “The scorecards were presented to vice presidents in the development organization at release sta- tus meetings, adding legitimacy to user experience being an in- tegral part of release quality decisions.” (p. 9) Internal marketing should be an integral part of a plan for changing a development culture. In a plan developed by Leadley et al. (2005; see Table 1.12, p. 4), most of the effort is devoted to marketing within the company, using a number of methods. Such an extended effort takes patience, persistence, and re- sources, as acknowledged by Leadley et al. (2005, p. 5): “The ‘sales’ effort by way of ‘dog and pony shows’ absorbed as much of our time as defining standards, building elements and de- signing our website!” However, internal marketing is inexpensive relative to failed products, and the potential benefits of these methods can be justified by comparing them to one failed product launch, six months of delayed adoption, or another appropriate metric. Make developers’ lives easier with user experience. Technology development always happens under severe time constraints, and time-pressured developers resist additional work. It is one thing to communicate that user-experience re- search and analysis increases chances of long-term success, but demonstrating how it reduces work is even better. One effective way to win over developers is to give them more freedom and reduce the amount of paperwork in their lives. Re- placing documents with tools that embody good practices in code means that developers do not feel pressured to memorize complex standards or reinvent techniques. Apple Computer (n.d.) successfully enables developers to create consistent inter- faces by backing up rules with a toolbox of interface elements and development tools that make it easier to follow the rules than to break them. Similarly, PBS created a set of “widgets” (Public Broadcasting System, 2004) that make it easier for member sta- tions to conform to a uniform organizational standard. Leadley et al. (2005) and Kuniavsky and Raghavan (2005) created tem- plates that included the code to generate interaction elements that conformed to end-user and organizational goals. “A UI Li- brary with 9 templates and 40 elements, a high-level methodol- ogy, and a guide for how to use our system. . . . For both tem- plates and elements we provided the HTML code and an HTML-rendered version of the item” (Leadley et al., 2005, p. 8). CONCLUSION When an organization creates technology, it embodies in a prod- uct its idea for a solution to an end-user problem, with the goal that this will ultimately help the organization itself. HCI is how the end user interacts with the product, but this symbiotic rela- tionship between the end users and the organization lies at the core of how that interaction is structured. Understanding the user experience, therefore, is the process of understanding the end-user needs and the organization needs with the goal of maximizing the benefit to both. This is true regardless of whether the product is destined for a broad consumer market or an internal tool. Unfortunately, most methods still treat the interaction of humans with com- puters and the interaction of the product with the organization as different. In fact, developing the user experience is the whole of technology creation. Emotional, social, and organizational needs make up the fabric in which HCI exists. Without them, there would be no computers and no reason for humans to interact with them. 20 • KUNIAVSKY TABLE 1.12. Timeline of Allianz User-Centered Practice Introduction (Leadley et al., 2005) Number of Projects Year Process Involved 2001 Personas 4 Dog pony shows 2002 Usability testing 10 UX training 1st 3rd Thursdays Dog pony shows 2003 Usability testing 15 JSP benchmarking Case studies Prototyping UX training JSP training 1st 3rd Thursdays 2004 Contextual inquiry 17 Usability testing UX training UX Thursdays SIG presentations 2005 Contributions to Software 19 Development Lifecycle Governance Standards Accountability of enterprise usability brand standards UX Thursdays
- 42. 1. User Experience and HCI • 21 References Agarwal, R., E. Karahanna. (2000). Time flies when you are having fun: Cognitive absorption and beliefs about information technology usage. MIS Quarterly, 24(4), 665–694. Andelman, D. A. (2005, October 5). A better way to search? Retrieved April 5, 2001, from Forbes.com Apple Computer. (n.d.). Interface builder documentation. Retrieved December 1, 2004, from http://developer.apple.com/tools/interface- builder.html Arnall, T. (2001). Mobile interaction design case study. Retrieved Octo- ber 30, 2005, from http://www.elasticspace.com/2001/06/mobile- interaction-design-case-study Beck, K., Andres, C. (2004). Extreme programming explained: Embrace change (2nd ed.). Reading, MA: Addison-Wesley. Bellotti, V. (1999). Personal communication. Bentley, R., Hughes, J. A., Randall, D., Rodden, T., Sawyer, P., Shapiro, D., et al. (1992, November). Ethnographically informed systems design for air traffic control. Proceedings of the Conference on Computer Supported Cooperative Work, Toronto, Canada, 123–129. Berg, S., Taylor, A. S., Harper, R. (2003, April). Mobile phones for the next generation: Device designs for teenagers. Proceedings of the Conference on Human Factors and Computing Systems CHI 2003, Fort Lauderdale, FL, pp. 443–440. Beyer, H., Holtzblatt, K. (1998). Contextual design: Defining cus- tomer-centered systems. San Francisco: Morgan Kaufmann Buckman, R. (2002, June 14). Microsoft’s cable-TV miscues turned into a costly lesson. Wall Street Journal. Cockburn, A. (2004). Crystal clear: A human-powered methodology for small teams. Reading, MA: Addison-Wesley. Cottam, M. (2004, April). Reuse for new uses. Presentation at ICSID Forum, CHI 2004, Vienna, Austria. Davis, F. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly, 14(3), 319–340. Elliot, K., Neustaedter, C., Greenberg, S. (2005). Time, ownership and awareness: The value of contextual locations in the home. Proceed- ings of the Ubicomp 2005 conference, Tokyo, Japan, pp. 251–268. European Information Technology Observatory. (2002). Yearbook (10th ed.). Frankfurt: Author. Fraser, J. (2005, November). Inspired innovation—How Corel is drawing upon employees’ ideas for user focused innovation. Proceedings of DUX05: Conference on Designing for User eXperience, San Fran- cisco, CA, Electronic proceedings, ISBN 1–59593–250–X. Garrett, J. J. (2000). Elements of user experience. Retrieved October 10, 2005, from http://www.jjg.net/elements/ Garrett, J. J. (2002). Elements of user experience. Indianapolis, IN: New Riders Press. Haeckel, S. (1999). Adaptive enterprise: Creating and leading sense-and- respond organizations. Boston, MA: Harvard Business School Press Hassenzahl, M. (2003). The Thing and I: Understanding the relationship between user and product. In M. A. Blythe, A. F. Monk, K. Over- beeke, P. C. Wright (Eds.), Funology: From usability to enjoyment. Dordrecht, the Netherlands: Kluwer Academic. Highsmith, J. (2002). Agile software development ecosystems. Reading, MA: Addison-Wesley. Hollinger, M. (2005, November). A process for incorporating heuristic evaluation into a software release. Proceedings of DUX05: Confer- ence on Designing for User eXperience, San Francisco, CA, Elec- tronic proceedings, ISBN 1–59593–250–X. Kelley, T., Littman, J. (2001). The art of innovation: Lessons in creativ- ity from IDEO, America’s leading design firm. New York: Doubleday. Krueger, R. A. (1988). Focus groups: A practical guide for applied research. Newbury Park, CA: Sage Publications. Kuniavsky, M. (2003). Observing the user experience: A practitioner’s guide to user research. San Francisco, CA: Morgan Kaufmann. Kuniavsky, M., Raghavan, S. (2005, November). Guidelines are a tool: Building a design knowledge management system for programmers. Proceedings of DUX05: Conference on Designing for User eXperi- ence, San Francisco, CA, Electronic proceedings, ISBN 1–59593– 250–X. Larman, C. (2003). Agile and iterative development: A manager’s guide. Reading, MA: Addison-Wesley. Leadley, B., Pao, H., Douglas, S. (2005, November). Creating a user experience culture at a nonsoftware company. Proceedings of DUX05: Conference on Designing for User eXperience, San Fran- cisco, CA, Electronic proceedings, ISBN 1-59593-250-X. Madison, D. S. (2005). Critical ethnography: Method, ethics, and per- formance. Thousand Oaks, CA: Sage Publications. Maslow, A. H. (1943). A theory of human motivation. Psychological Review, 50, 370–396. Millen, D. (2000, August). Rapid ethnography: Time deepening strate- gies for HCI field research. Proceedings of DIS 2000: Designing Interactive Systems , New York, NY, pp. 280–286. Nass, C., Reeves, B. (1996). The media equation: How people treat computers, televisions, and new media as real people and places. Cambridge, MA: Cambridge University Press. Norman, D. A. (1998). The invisible computer. Cambridge, MA: MIT Press. Ortony A., Norman, D. A., Revelle, W. (2005). Affect and proto-affect in effective functioning. In J. M. Fellous M. A. Arbib (Eds.), Who needs emotions? The brain meets the machine (pp. 173–202). New York: Oxford University Press. Pellican, S., Homier, M. (2005, November). Customer driven innova- tion: Quicken(r) rental property manager. Proceedings of DUX05: Conference on Designing for User eXperience, San Francisco, CA, Electronic proceedings, ISBN 1–59593–250–X. Pine, B. J., Gilmore, J. H. (1999). The experience economy. Boston, MA: Harvard Business School Press. Postrel, V. (2003). The substance of style: How the rise of aesthetic value is remaking commerce, culture and consciousness. New York: HarperCollins. Public Broadcasting System. (2004). Best practices for PBS member sta- tions. Retrieved December 1, 2005, from http://www.pbs.org/remote control/bestpractices/ Rafaeli, Y., Vilnai-Yavetz, I. (2004). Emotion as a connection of physical artifacts and organizations. Organizational Science, 15, 6. Saffer, D. (2002, June 3). Building brand into structure. Boxes and Arrows. Retrieved October 28, 2005, from http://www.boxesand arrows.com/archives/building_brand_into_structure.php Sawhney, M. (2003, July 1). Fundamentals of Value. CIO Magazine. Schmitt, B. H. (2003). Customer experience management: A revolu- tionary approach to connecting with your customers. San Francisco, CA: John Wiley Sons. Schwaber, K., Beedle, M. (2001). Agile software development with SCRUM. Upper Saddle River, NJ: Prentice Hall. Spool, J. (2005, August 10). Re:[Sigia-L] Length of nav Labels. Message posted to Sigia-L electronic mailing list, archived at http://www.info- arch.org/lists/sigia-l/0508/0157.html TiVo. (2005, August 24). Press release. U.S. General Accounting Office. (1996). Content analysis: A method- ology for structuring and analyzing written material (GAO/PEMD- 10.3.1). Washington, DC: Author. Vredenburg, R., Isensee, S., Righi, C. (2001). User-centered design: An integrated approach. Upper Saddle River, NJ: Prentice Hall.
- 43. Wikipedia. (2005a). Ford Model T. Retrieved October 10, 2005, from http://en.wikipedia.org/wiki/Ford_Model-T Wikipedia. (2005b). Ford Model A. Retrieved October 10, 2005, from http://en.wikipedia.org/wiki/Ford_Model_A Wikipedia. (2005c). Customer relationship management. Retrieved October 29, 2005, from http://en.wikipedia.org/wiki/Customer_ relationship_management Wikipedia. (2005d). Customer experience management. Retrieved October 29, 2005, from http://en.wikipedia.org/wiki/Customer_ experience_management Wikipedia. (2005e). Out of box experience. Retrieved October 30, 2005, from http://en.wikipedia.org/wiki/Out-of-box_experience. Wixon, D. R., Ramey, J., Holtzblatt, K., Beyer, H., Hackos, J., Rosenbaum, S., et al. (2002, April). Usability in practice: Field methods, evolu- tion and revolution. Proceedings CHI 2002: Proceedings of the Con- ference on Human Factors and Computing Systems , Minneapolis, MN, pp. 880–884. Zhang, P., Li, N. (2005). The importance of affective quality. Com- munications of the ACM, 9, 105–108. 22 • KUNIAVSKY
- 44. ◆ 2◆ REQUIREMENTS SPECIFICATIONS WITHIN THE USABILITY ENGINEERING LIFECYCLE Deborah J. Mayhew, PhD Deborah J. Mayhew Associates 23 Introducing Requirements Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Phase 1:Requirements Analysis . . . . . . . . . . . . . . . . . . . . . 24 User profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Contextual task analysis . . . . . . . . . . . . . . . . . . . . . . . 24 Usability goal setting . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Platform capabilities/constraints . . . . . . . . . . . . . . . . 24 General design guidelines . . . . . . . . . . . . . . . . . . . . . . 25 Phase 2:Design/Testing/Development . . . . . . . . . . . . . . . 25 Level 1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Work reengineering . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Conceptual model design . . . . . . . . . . . . . . . . . . . . . . 26 Conceptual model mockups . . . . . . . . . . . . . . . . . . . . 26 Iterative conceptual model evaluation . . . . . . . . . . . . 26 Level 2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Screen design standards . . . . . . . . . . . . . . . . . . . . . . . 26 Screen design standards prototyping . . . . . . . . . . . . . 26 Iterative screen design standards evaluation . . . . . . . 26 Style guide development . . . . . . . . . . . . . . . . . . . . . . . 26 Level 3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Detailed user interface design . . . . . . . . . . . . . . . . . . 26 Iterative detailed user interface design evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Phase 3:Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 User feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Focusing on Requirements Analysis . . . . . . . . . . . . . . . 26 The user profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Contextual task analysis . . . . . . . . . . . . . . . . . . . . . . . 27 Motivating and Justifying Requirements Specification . . . . . . . . . . . . . . . . . . . . . . . 29 User Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Work Environment Requirements . . . . . . . . . . . . . . . . . . . 30 Task Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
- 45. INTRODUCING REQUIREMENTS SPECIFICATIONS Three key ingredients are necessary to ensure that usability is achieved during product development: • Application of established design principles and guidelines; • A structured methodology for design; • Managerial and organizational techniques. At this point in the history of the field of human-computer interaction, there are well-established software design princi- ples and guidelines available, based on objective research and reported in the literature. Many of these principles and guide- lines are enumerated throughout different chapters in this book. Development organizations need to have staffs which are fluent in these design guidelines participate in design efforts, so this general accumulated knowledge will find its way into their products. However, just having a design guru on board does not guar- antee that design principles and guidelines will find their way into products. Design is complex, and there simply is no cook- book approach to design that can rely on general principles and guidelines alone. Development organizations also need struc- tured methods for achieving usability in their products. Similarly, a well-structured and documented design method- ology must be introduced and managed—it does not happen by itself. Thus, managerial and organizational techniques must be applied to ensure that the design methodology is followed and includes the application of well-established design principles. Even when good management practices are being ap- plied, either of the remaining two ingredients alone—design guidelines or design methods—is necessary, but not suffi- cient. Optimal design cannot be accomplished by the system- atic application of generic guidelines alone, because every product and its intended set of users are unique. Design guidelines must be tailored for and validated against prod- uct-unique requirements, and this is what the structured methods accomplish. Conversely, applying structured methods without also draw- ing on well-established design principles and guidelines is inef- ficient at best and may simply fail at worst. Without the benefit of the initial guidance of sound design principles during first passes at design, a particular project with its limited resources may simply never stumble upon a design approach that works. For example, formal usability testing is a valuable and objective method for uncovering usability problems. How- ever, without a clear understanding of basic design principles and guidelines, as well as unique requirements data, solving those problems after they have been identified will not be easy or likely. This section addresses the need for methodology and pro- vides chapters that address a variety of techniques that can be applied during the development process to achieve usability in product design. This chapter sets the stage for this section and, in particular, for the subsection on one stage of the development process: requirements specification. The Usability Engineering Lifecycle (Mayhew, 1999) docu- mented a structured and systematic approach to addressing usability within the product-development process. It consists of a set of usability engineering tasks applied in a particular order at specified points in an overall product-development lifecycle. Several types of tasks are included in the Usability Engineer- ing Lifecycle: • Structured usability-requirements analysis tasks; • An explicit usability goal-setting task, driven directly from requirements-analysis data; • Tasks supporting a structured, top-down approach to user interface design that is driven directly from usability goals and other requirements data; • Objective usability evaluation tasks for iterating design to- ward usability goals. Figure 2.1 represents in summary, visual form, the Usability Engineering Lifecycle. The overall lifecycle is cast in three phases: Requirements Analysis, Design/Testing/Development, and Installation. Specific usability-engineering tasks within each phase are presented in boxes, and arrows show the basic order in which the tasks should be carried out. Much of the sequenc- ing of tasks is iterative, and the specific places where iterations would most typically occur are illustrated by arrows returning to earlier points in the lifecycle. Brief descriptions of each life- cycle task follow. Phase 1: Requirements Analysis User profile. A description of the specific user character- istics relevant to user interface design (e.g., computer literacy, expected frequency of use, level of job experience) is obtained for the intended user population. This will drive tailored user in- terface design decisions and identify major user categories for study in the Contextual Task Analysis task. Contextual task analysis. A study of users’ current tasks, workflow patterns, and conceptual frameworks is made, resulting in a description of current tasks and workflow, and understanding and specification of underlying user goals. These will be used to set usability goals and drive Work Reengineering and user interface design. Usability goal setting. Specific qualitative goals reflect- ing usability requirements are developed, extracted from the User Profile and Contextual Task Analysis. In addition, quanti- tative goals (based on a subset of high-priority qualitative goals) are developed, defining minimal acceptable user per- formance and satisfaction criteria. These usability goals focus later design efforts and form the basis for later iterative usabil- ity evaluation. Platform capabilities/constraints. The user interface capabilities and constraints (e.g., windowing, direct manipula- tion, screen size, color, etc.) inherent in the technology platform 24 • MAYHEW
- 46. 2. Requirements Specifications Within the Usability Engineering Lifecycle • 25 FIGURE 2.1. The Usability Engineering Lifecycle. (Illustration taken from Mayhew, 1999.) chosen for the product (e.g., Apple Macintosh, MS Windows, prod- uct-unique platforms) are determined and documented. These will define the scope of possibilities for user interface design. General design guidelines. Relevant general user in- terface design guidelines available in the usability engineer- ing literature are gathered and reviewed. They will be ap- plied during the design process to come, along with all other project-specific information gathered in the previous tasks. Phase 2: Design/Testing/Development Level 1 Design Work reengineering. Based on all requirements-analysis data and the usability goals extracted from it, user tasks are re- designed at the level of organization and workflow to streamline work and exploit the capabilities of automation. No user inter- face design is involved in this task, just an abstract organization of
- 47. functionality and workflow design. This task is sometimes re- ferred to as “Information Architecture.” Conceptual model design. Based on all the previous tasks, initial high-level design alternatives are generated. At this level, navigational pathways and major displays are identified, and rules for the consistent presentation of work products, processes, and actions are established. Screen design detail is not addressed at this design level. Conceptual model mockups. Paper-and-pencil or proto- type mockups of high-level design ideas generated in the pre- vious task areprepared, representing ideas about high-level functional organization and Conceptual Model Design (see Beaudouin- Lafon and MacKay in this book for a discussion of prototyp- ing tools and techniques). Detailed screen design and com- plete functional design are not in focus here. Iterative conceptual model evaluation. The mockups are evaluated and modified through iterative evaluation tech- niques such as formal usability testing, in which real, repre- sentative end users attempt to perform real, representative tasks with minimal training and intervention, imagining that the mockups are a real product user interface (see section III in this volume for chapters on testing and evaluation). This and the previous two tasks are conducted in iterative cycles until all major usability “bugs” are identified and engineered out of Level 1 (e.g., Conceptual Model) design. Once a Con- ceptual Model is relatively stable, system architecture design can commence. Level 2 Design Screen design standards. A set of product-specific stan- dards and conventions for all aspects of detailed screen design is developed, based on any industry and/or corporate standards that have been mandated (e.g., Microsoft Windows, Apple Macintosh, etc.), the data generated in the Requirements Analy- sis phase, and the product-unique Conceptual Model Design arrived at during Level 1 Design. Screen design standards prototyping. The Screen Design Standards (as well as the Conceptual Model Design) are applied to design the detailed user interface to selected sub- sets of product functionality. This design is implemented as a running prototype. Iterative screen design standards evaluation. An evaluation technique, such as formal usability testing, is carried out on the Screen Design Standards prototype, and then re- design/reevaluation iterations are performed to refine and val- idate a robust set of Screen Design Standards. Iterations are con- tinued until all major usability bugs are eliminated and usability goals seem within reach. Style guide development. At the end of the design/eval- uate iterations in Design Levels 1 and 2, you have a validated and stabilized Conceptual Model Design, and a validated and sta- bilized set of standards and conventions for all aspects of detailed Screen Design. These are captured in the document called the product Style Guide, which already documents the results of requirements-analysis tasks. During Detailed User Interface De- sign, following the Conceptual Model Design and Screen Design Standards in the product Style Guide will ensure quality, coher- ence, and consistency—the foundations of usability. Level 3 Design Detailed user interface design. Detailed design of the complete product user interface is carried out based on the re- fined and validated Conceptual Model and Screen Design Stan- dards documented in the product Style Guide. This design then drives product development. Iterative detailed user interface design evaluation. A technique such as formal usability testing is continued dur- ing product development to expand evaluation to previously unassessed subsets of functionality and categories of users, and also to continue to refine the user interface and validate it against usability goals. Phase 3: Installation User feedback. After the product has been installed and in production for some time, feedback is gathered to feed into design enhancements, design of new releases, and/or design of new but related products. FOCUSING ON REQUIREMENTS ANALYSIS This section of the book provides in-depth coverage of the different phases (and tasks within those phases) of the Usability Engineering Lifecycle. In particular, this subsection, Re- quirements Specification, provides chapters describing and discussing different tasks and techniques for requirements spec- ification in some depth and from different perspectives. The goal of this chapter is to reinforce the importance of this phase of the lifecycle and to provide real-world examples of the ben- efits of conducting the kinds of techniques discussed in the later chapters of this subsection. Three main things must be studied and understood to tailor design to support unique requirements: • The users • The users’ tasks • The users’ work environment In The Usability Engineering Lifecycle, the first is addressed in the task called the User Profile, and the second two are ad- dressed in the task called Contextual Task Analysis. The user profile. There is no single best user interface style or approach for all types of users. Specific interface de- sign alternatives that optimize the performance of some types 26 • MAYHEW
- 48. of users may actually degrade the performance of other types of users. For example, an infrequent, casual user needs an easy-to-learn and easy-to-remember interface, but a high- frequency expert user needs an efficient, powerful, and flex- ible interface. These are not necessarily the same thing. Sim- ilarly, a highly skilled typist might perform better with a keyboard-oriented interface, whereas a low-skill typist might do better with a graphical user interface in which point-and- select interaction replaces keyboarding. Unless designers know the specific characteristics of a popula- tion of users (e.g., expected frequency of use, level of typing skill, special needs and constraints, etc.), they cannot make optimal user interface design decisions for them. The purpose of a User Profile is thus to establish the general requirements of a category of users in terms of overall interface style and approach. One relatively new technique for gathering, documenting, and applying user profile data in user interface design is the use of “personas” (Pruitt Adlin, 2006; see also Adlin Pruitt in this volume). Personas are realistic and detailed descriptions of imag- inary people who represent all the characteristics, skill sets, goals, top tasks, responsibilities, tools, pain points, and so on of a cate- gory of users. They are used to drive discussion and design all throughout the product-development lifecycle, from product conception to user acceptance testing. They help keep the focus on users’ needs and goals, and give stakeholders a common lan- guage with which to consider, discuss, and evaluate product- design ideas. Another older, but still effective, way to keep the user perspective in product design is participatory design, which builds users right into the design team. Besides understanding individual users of different cate- gories, understanding the characteristics of groups and com- munities is another aspect of user profiling that becomes im- portant in the design of groupware and products aimed at online communities and computer-supported cooperative work. This aspect of requirements analysis is addressed else- where (chapter 27, HCI Handbook). The User Profile task fits into the overall Usability Engineer- ing Lifecycle as described as follows: • The User Profile task is the first task in the Usability Engi- neering Lifecycle; • The User Profile task will feed directly into the Contex- tual Task Analysis task by identifying categories of users whose tasks and work environment must be studied in that later task; • The User Profile task will feed directly into the Usability Goal Setting task in that usability goals are in part driven directly by user characteristics (e.g., a low frequency of use indicates a need for ease-of-learning and remembering). Thus, different usability goals will be extracted from the profiles of different categories of users; • Ultimately, the User Profile task will have a direct impact on all design tasks, which are focused on realizing usability goals, in turn based in part on User Profiles; • The User Profile task will also drive the selection of usability- evaluation issues and test users; • Output from the User Profile task will be documented in the product Style Guide. The User Profile task fits into the underlying software devel- opment methodology as follows: • The User Profile task can occur in parallel with, overlapping with, or following the development of the Requirements Model in the Analysis Phase in Object-Oriented Software Engineering (OOSE), or function and data modeling in the requirements phase of a traditional rapid prototyping methodology. It could either define Actors for the Require- ments Model or take the definition of user categories from the Requirements Model as its starting point; • The User Profile task (along with all other Usability Engineer- ing Lifecycle Requirements Analysis tasks) should occur prior to the development of the Analysis Model in the Analysis phase of OOSE (or the application architecture design in a traditional rapid prototyping methodology). Contextual task analysis. The purpose of the Contex- tual Task Analysis task is to obtain a user-centered model of work as it is currently performed (e.g., to understand how users currently think about, talk about, and do their work in their actual work environment). Ultimately, the reason for this is that when designing a new product and its user interface, it is important to find an optimal compromise or tradeoff be- tween three goals: • Realizing the power and efficiency that automation makes possible; • Reengineering work processes to more effectively support identified business goals; • Minimizing retraining by having the new product tap as much as possible into users’ existing task knowledge, and maximiz- ing efficiency and effectiveness by accommodating human cognitive constraints and capabilities within the context of their actual tasks. Traditionally, in software-development methodologies, the most focus is put on the first goal, and some of the second goal and most of the third are lost, because designers and de- velopers never really understand the users’ work and their current work models. A great deal of work reengineering oc- curs in application design, and only some of it serves the first two goals. Much of it is unnecessary and not useful, and it results in unnecessary training and usage burdens on the user. The third goal—minimizing the training overhead and maximizing efficiency and effectiveness—cannot be factored in unless designers have a clear picture of users’ current work models: how they do their work in the realities of their every- day work environment, and how they think about it and talk about it. Traditional systems analysis usually (but not always) results in the inclusion of all required data and low-level functions, and structures them in a robust implementation architecture. With- out a truly user-centered approach, however, it often fails to or- ganize and present that data and functionality in a manner that supports and optimizes the work performance of real users in their real work environment. This missing piece is the whole point of a Contextual Task Analysis. 2. Requirements Specifications Within the Usability Engineering Lifecycle • 27
- 49. Thus, the purpose of this task is to supplement more tradi- tional types of systems analyses to define usability requirements and to point toward ways of meeting those requirements. Then, in later tasks, these requirements can be applied directly to making user interface design decisions. Contextual Task Analysis consists of the following basic steps: • Gathering background information about the work being automated; • Collecting and analyzing data from observations of and in- terviews with users as they do real work in their actual work environment; • Constructing and validating models of how users currently think about and do their work. A central, key step in the Contextual Task Analysis task is the second step, sometimes referred to as “contextual observa- tions/interviews.” Here, the idea is that analysts must observe and interview users in their real-life work context to understand their work and discover their work models. Only then can de- signers structure and present functionality in an application user interface in a way that taps into users’ current work models and optimally supports their tasks. An abstract modeling of users’ tasks, which is the focus of more traditional types of business and systems analysis, does not typically take into consideration key aspects of actual workflow and key aspects of the users and their work envi- ronment, and simply does not support this goal. Another way of putting this is that traditional systems analysis models work in the abstract, without considering the basic capabilities and constraints of human information processing; the particular characteristics of the intended user population; the unique characteristics of the work environment; and how users them- selves model, carry out, and talk about their tasks. In addi- tion, the usual approach in a traditional business/systems analysis is to decompose high-level units of work into low- level functions. In the process, much of how the work is ac- tually carried out is lost. The result of this analysis approach is often systems that provide all necessary functionality, but in an organization and presentation that simply does not support the natural flow of work and address the current “points of pain” for individual users. Based on an analysis of direct observations, models can be constructed that represent not the work in the abstract from a systems point of view, but instead represent how users cur- rently think about, talk about, and actually carry out their work (e.g., models reflecting the users’ point of view). These models do not get directly designed into the application or its interface. They feed into only one of the goals referred to ear- lier, that of tapping into existing user knowledge, habit, and capabilities, and they are juggled with the other two goals of supporting general business goals and exploiting the power of automation. This juggling happens in a later task in The Us- ability Engineering Lifecycle called “Work Reengineering,” but also often referred to as “Information Architecture.” One generic aspect of tasks that has become increasingly important with the explosion of e-commerce is the issues of se- curity and privacy. Understanding users’ requirements for and expectations of privacy, and making users feel confident in the security and privacy of personal information they are asked to divulge in the course of various kinds of online transactions, has become a significant part of the necessary research into user tasks, and the design of interactions to support them. Contextual Task Analysis task fits into the overall Usability Engineering Lifecycle as described as follows: • The User Profile task will feed directly into the Contextual Task Analysis task by identifying categories of users (e.g., ac- tors) whose tasks must be studied; • The Contextual Task Analysis task will feed directly into the Usability Goal Setting task by helping to identify dif- ferent primary goals for different task types (use cases), and by identifying bottlenecks and weaknesses in current work processes that can be reduced through good user in- terface design; • The Contextual Task Analysis task will feed directly into the Work Reengineering task. Current user work models are reengineered only as much as necessary to exploit the power of automation and contribute to explicit business goals. Current user knowledge and experience are ex- ploited as much as possible to facilitate ease of learning and use; • The Contextual Task Analysis task will be documented in the product Style Guide; • Ultimately, the Contextual Task Analysis task will have a direct impact on all design tasks, and on the selection of usability testing and evaluation issues, as well as on the design of usability testing materials. Contextual Task Analysis fits into the underlying software de- velopment methodology as follows: • The Contextual Task Analysis task can occur in parallel with, overlapping with, or following the development of the Re- quirements Model in the Analysis Phase in OOSE (or function and data modeling in the requirements phase of a traditional rapid prototyping methodology). It could either identify Use Cases for the Requirements Model, or take the definition of Use Cases from the Requirements Model as its starting point for constructing Task Scenarios; • The Contextual Task Analysis task (along with all other Us- ability Engineering Lifecycle Requirements Analysis tasks) should occur prior to the development of the Analysis Model in the Analysis phase of OOSE (or the application architec- ture design in a traditional rapid-prototyping methodology). Currently, in the field of Usability Engineering, there is no well-established, universally applied, general, practical, and highly structured technique for performing a Contextual Task Analysis for the purpose of driving the user interface design for a product that has already been identified and scoped. It is more of an art than a science at this point, with each usability practitioner using his or her own informal ap- proach. Recently, however, some structured techniques have begun to emerge, and experience with them has been reported in the literature (e.g., Beyer Holtzblatt, 1998; Hackos Redish, 1998). 28 • MAYHEW
- 50. MOTIVATING AND JUSTIFYING REQUIREMENTS SPECIFICATION While the previous section set the stage for Requirements Spec- ifications within the broader perspective of the whole Usability Engineering Lifecycle and underlying development process, this section provides motivation and the justification for investing in Requirements Specifications tasks and activities, in particular through the reporting of “war stories” from the experience of myself and other practitioners. The war stories are divided into those relating to user, environment, and task requirements. User Requirements Following are two examples from my own experience of the im- portance of knowing your users. For two of my clients, I first interviewed project team mem- bers (developers) to get a general sense of the user population. My purpose was to solicit input to the design of a User Profile questionnaire that I would later employ to solicit profile infor- mation directly from the users themselves. In one case, the project team was convinced that their users would have a generally low level of familiarity with the Microsoft Windows platform they planned for their product. They were thus prepared to depart significantly from the Windows platform user interface standards in their product user interface. The User Profile questionnaire, however, revealed a generally high level of Windows experience. This, and the fact that the Windows user interface standard was a good fit for the application functionality, led me to strongly advise them to adopt the Windows standards as closely as possible. They were still interested in creating their own unique user interface, but early testing of several alternative designs that varied in how faithfully they followed Windows stan- dards clearly showed that users learned much more quickly the more consistent the design was with Windows standards. On the other project, the development team felt quite con- fident that users would generally have high levels of computer literacy. An extensive User Profile questionnaire of more than 800 users, however, revealed that only a very small percentage of potential users had any experience with computer software at all, let alone the Windows user interface standards. In this case, based on this User Profile data, we designed (and validated through testing) a highly simplified user interface that departed significantly from the Windows standards. In both of these cases, two things are clear: • Project team members often have serious misconceptions about the key characteristics of their users; • These misconceptions could lead teams to design inappro- priate user interfaces for those users. Work Environment Requirements It is also important to understand the environment in which users will be utilizing a product to carry out their tasks, because this environment will place constraints on how they work and how well they work. By analogy, suppose a screwdriver is being designed and all that is known is the size of the screw head it must fit. So, some- thing like a traditional screwdriver is designed, with the cor- rectly sized blade. But, suppose it then turns out that the user needs to apply the screw from the inside of a narrow pipe to assemble some piece of equipment. Clearly, a traditional screw- driver will be useless in this work context. Similarly, suppose a software application is being designed for a set of users, but the designers have never gone to the users’ actual work environment. They assume a traditional office-like environment and design software that will work on a traditional workstation. But, suppose it then turns out that in the actual work environment, users are constantly in motion, moving all around the environment to get different parts of an overall job done. If software for a traditional workstation is de- signed, this will simply not work in this environment. Software that will run on a smaller and more portable device that can be carried around with the user, such as the units carried by UPS delivery staff, would be required instead. In another example, suppose designers have never visited the user’s workplace, and they assume users all work in closed offices. So, a system with voice input and output is designed. But, it then turns out that users work in one big open area with desks located right next to one another. The noise from all those talking people and workstations will create an impossi- ble work environment, and most voice-recognition systems sim- ply do not work with acceptable accuracy in a noisy environ- ment. The point is, there are many aspects of the actual work environment that will determine how well a tool will work in that environment, and so the environment itself must be stud- ied and the tool tailored to it. A real example of the importance of understanding the users’ work environment comes from a project I worked on with a large metropolitan police department. Requirements- analysis activities revealed that in the typical police station, the appearance of the interior is dark, run-down, and cluttered; the lighting is harsh and artificial; and the air is close and sometimes very hot. The noise level can be high, the work areas are cramped and cluttered, and the overall atmosphere is tense and high-pressured at best, chaotic and sometimes riotous at worst. These conditions most likely have a general impact on morale, and certainly will have an impact on cognitive functioning that, in turn, will impact productivity and effectiveness. A user inter- face must be carefully designed to support the natural and pos- sibly extreme degradations of human performance under these conditions. In addition, it was observed that in the noisy, stressful, and distracting work environment in a typical police station, users will frequently be interrupted while performing tasks, some- times by other competing tasks, sometimes by unexpected events, unpredictable prisoners, and so forth. A user interface in such an environment must constantly maintain enough context information on the screen so that when users’ attention is tem- porarily but frequently drawn away from their tasks, they can quickly get reoriented and continue their task without errors, and not have to backup or repeat any work. 2. Requirements Specifications Within the Usability Engineering Lifecycle • 29
- 51. Task Requirements Besides the users themselves and the environments they work in, the tasks they do also have their own inherent requirements. One compelling example of the need for a thorough under- standing of users’ tasks to achieve usable design comes from one of the earliest books on computer-human interaction (Ru- binstein Hersh, 1984, p. 26). For example, recently a water district in Maine installed an online billing system so that when a customer called in, the clerk could quickly retrieve a record of usage and billing for that customer. The managers noticed that the clerks were less than happy with the new system. A little investigation revealed that with the manual system, the clerks would write pertinent infor- mation in the margins of the records, such as that one person pays on the 15th of the month rather than on the first, or that the meter reader should contact the neighbor across the street for access to a house. This informal information was critical to the smooth operation of the office, but because there was no provision for it in an official field of the payment-record form, the information was lost in the conversion to the online sys- tem. Understanding that there is informal as well as official in- formation and recognizing the importance of the former would have reduced the disruption in work style. Another good example of what can be missed by not under- standing users’ tasks is found in Coble, Karat, and Kahn (1997). This report described the use of task-analysis techniques to study the functional requirements of physicians for a clinical workstation: Before the . . . session started, a physician explained the purpose and details of each section in his office chart. . . . Later, when he was doing actual work in context, the person performing the . . . session noticed that the note he was looking at was written with red ink. She probed and the physician said it told him the previous encounter with this pa- tient was a hospital visit. That fact told him he needed to review the hos- pital discharge summary and hospital laboratory results before enter- ing the patient’s exam room. The physician was surprised that he had not mentioned that need before. It was so ingrained in how he worked that he did not even process that highly relevant detail consciously any- more. (p. 231) [Italics mine.] In another example from my own experience, I was once performing a requirements analysis in a police department and observing police officers using a system of standardized paper forms to document property. I observed infrequent users of the forms struggling with them; there were many complex forms and many undocumented rules about how to fill them out. Later I observed very frequent users using them. The frequent users tended to ignore the forms initially and take freeform notes de- scribing the property they had to document in a format very dif- ferent from that required on the forms. They then transcribed their own notes onto the forms as required. It was clear from this observation (and from follow-up interviews with the fre- quent users) that the forms were not designed in a way that sup- ported the users’ task, and I learned a lot from how frequent users worked around the forms with their own format that helped in designing better online forms. A traditional systems analysis would typically not involve studying users actually using paper forms in their actual work, but would have instead taken the paper forms themselves as a description of the work to be automated. Problems with the forms would have been missed entirely and perpetuated in the online version of the task. There are always a great many things like this that users sim- ply will not think to report during an offsite interview or “focus group” that only emerge during in-context observations of peo- ple doing real work in their workplaces. Such things can have major implications for product user interface design. Here is another example, this time from the context of a cus- tomer service application in an insurance company. In the navi- gational model illustrated in Fig. 2.2, the free text in normal in- tensity represents the basic user tasks identified from initial in-context observations with users. The bold text in boxes rep- resents the hierarchy of groups that the design team developed, with labels they created—again, all based on initial task analysis activities. (This hierarchy represents only a partial set of the func- tionality required by a Customer Support Rep. For simplicity, not all groups or low-level tasks are included in the example.) In contrast to the designer-generated model in Fig. 2.2, Fig. 2.3 shows a user-generated model. Again, the free text in nor- mal intensity represents the low-level tasks presented to the user, each one on a separate index card. This time the bold text in boxes represents the groups that one user formed from the low-level tasks, with labels they suggested. The differences between the designer-generated model and the user-generated model of these tasks are significant. For example, the design team organized all types of Changes (e.g., Address, Beneficiary) under a single category (“Change Requests”) within the category Sales Support, whereas this user distinguished between those changes that have to do with 30 • MAYHEW FIGURE 2.2. A Designer’s Navigational Model. Admin ⫽ Administration; App ⫽ application; Mgmnt ⫽ management.
- 52. customer information and those that have to do with policy de- tails, but located both under the category Customer Support rather than Sales Support. As it turned out, Customer Support staff can make simple changes to customer information on their own, but more complex paperwork and approvals are required for policy changes. Thus, these are two distinct categories of tasks to users. Even though requests for these types of changes often come from customers via sales agents, this user still re- garded them as really reflecting Customer Support. Similarly, the design team lumped all Office Administration tasks in one group, whereas this user distinguished between daily and occasional office tasks. Different people get assigned to these types of tasks, so, again, this is a meaningful distinc- tion to users. The designers imagined a category unto itself called Follow- Up, in which incomplete tasks of all types (e.g., Incomplete App) are all located, whereas this user considered follow-up activities as belonging with the original task types with which they are associated. Finally, note that the user regarded New Sales (data entry of new policy applications) as its own category, whereas the de- signers had seen this as a subcategory of Sales Support—a very different perception. One important thing to note in comparing this user’s model of tasks with the designer’s first pass at a model of tasks is that, for any set of low-level tasks, there may be a large number of very different “logical” task organizations possible, but there will only be a small number of rather similar ones that will make sense to users, given their actual work. A traditional systems analysis will decompose high-level functional requirements to all the corresponding low-level tasks, but it typically does not ensure that the task organization most consistent with the users’ models of their tasks will be presented to the user in the user interface to a product intended to support those tasks. That is one of the main goals of a task analysis. Also note that this user’s model is most likely not exactly the same as other users’ models, although in most cases, there will be a lot of similarity across individual users’ models. It is neces- sary to consolidate all the sampled users’ task models and gen- erate one consolidated model (in the same format as the indi- vidual users’ models, as illustrated in Fig. 2.3) that captures all the across-user commonalties as well as possible. One last example from my recent experience illustrates the importance of studying users’ work in depth to design the user interface to a software application that supports that work. In this example, the application was a database system in- tended to support users in a government agency. The mission of the agency was to uncover and prosecute criminal behavior of a specific type. The job of the users of the intended system was to manage publicity for their agency in the media. These users needed to interact with the media to enhance reporting on criminal cases to use the media to help discourage criminal behavior and encourage public cooperation in reporting and investigating criminal behavior. The database of information being provided to these users included information on criminal cases in progress relevant to this agency, prior press releases and news articles on relevant criminal cases, a “phonebook” of contact information for re- porters and other contacts in the media, records of past com- munications with the media, and so forth. A card-sorting exer- cise revealed that users considered these categories of data types—Cases, Documents, Media Contact Information, Media Communications—to be distinct and meaningful categories that would provide a good foundation for the navigational structure of the application. However, what was not revealed by the card sorting exercise, but did become clear through other methods of studying users’ work in context, was that when users searched for and found a particular item in one of these categories, such as a case, they then typically wanted to auto- matically see items in other categories related to the item they had initially looked up. Based on the card-sort data, I had initially designed a navi- gational structure in which the user first selected a category of data, and then searched for items in that category. Assuming from the card-sort data that a search for one type of data was independent from searching for another type, I designed the in- teraction such that searching for something within any category of data was independent of searching for something within any other category of data. That is, if the user searched for and found a case, and then navigated to the category of Documents, or to the category of Media Contact Information, the initial de- sign assumed that the user wanted to start an independent, un- related new search in that category. However, further discussion with users revealed that in fact when the user searched for and found a case, it was most likely that he or she would then want immediate access to documents related to that case, or contact information related to that case. Similarly, if the user initially searched for a particular reporter’s contact information, then he most likely would be interested in then seeing all documents re- lated to this reporter, and/or all cases related to this reporter. This required a very different navigational and interaction de- sign. Even though card-sorting data had been collected, with- out the ongoing input of users during early design, it would have been very easy to design the application in such as way as to make the users’ most typical type of task very tedious and cumbersome. 2. Requirements Specifications Within the Usability Engineering Lifecycle • 31 FIGURE 2.3. A User’s Navigational Model. Admin ⫽ Adminis- tration; App ⫽ application.
- 53. Clearly, it is possible, even likely, to design a user interface that does not support users, their tasks, or their work environ- ment if an in-depth requirements analysis is not conducted prior to design and incorporated into design. The chapters that follow describe and discuss a variety of techniques for gather- ing these all-important requirements specifications. 32 • MAYHEW References Beyer, H., Holtzblatt, K. (1998). Contextual design. San Francisco: Morgan Kaufmann Publishers, Inc. Coble, J. M., Karat, J., Kahn, M. G. (1997). Maintaining a focus on user requirements throughout the development of clinical workstation software. CHI ’97 Proceedings. Hackos, J. T., Redish, J. C. (1998). User and task analysis for interface design. New York: John Wiley Sons, Inc. Mayhew, D. J. (1999). The usability engineering lifecycle. San Francisco: Morgan Kaufmann Publishers. Pruitt, J., Adlin, T. (2006). The persona lifecycle: Keeping people in mind throughout product design. San Francisco: Morgan Kaufmann Publishers/Elsevier. Rubinstein, R., Hersh, H. (1984). The human factor: Designing com- puter systems for people. Burlington, MA: Digital Press.
- 54. ◆ 3◆ TASK ANALYSIS Catherine Courage Salesforce.com Janice (Ginny) Redish Redish Associates, Inc. Dennis Wixon Microsoft 33 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Defining Task Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Task Analysis in this Chapter . . . . . . . . . . . . . . . . . . . . . . . 34 Considering Four PrinciplesThat Underlie Task Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Task Analysis Is an Integral Part of a Broader Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Task Analysis Includes Understanding Users’Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Considering Norman’s entire action cycle as task analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Task Analysis Is Relevant at All Stages of the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Practical Reality Impinges on What We Actually Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Selling Task Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Dispelling the MythsThat Lead to Resistance . . . . . . . . . . 37 We do market research;We do not need task analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Task analysis is too time consuming and costly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Using Other Opportunities to SellTask Analysis . . . . . . . . 37 MakingTask Analysis Part of the Standard Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Planning for a Task Analysis (Issues to Consider) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Background Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Getting Into the Project Plan . . . . . . . . . . . . . . . . . . . . . . 38 Getting Sign-off and Meeting Schedules . . . . . . . . . . . . . . 38 Providing Useful and Usable Data . . . . . . . . . . . . . . . . . . . 38 Deciding What the ProjectTeam Needs . . . . . . . . . . . . . . 38 Where is the product in its overall life cycle? . . . . . . . 39 How much time do you have to conduct your task analysis? . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 How broad or specialized is the user population for the product? . . . . . . . . . . . . . . . . . . . . 39 How widespread geographically,culturally, and linguistically is the user population for the product? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 How detailed must we specify the tasks? . . . . . . . . . . 39 Is this a special type of product for which traditional task analysis may not be useful? . . . . . . . . 39 Deciding on an Appropriate Level of Granularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Deciding Where to Start . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Gathering Reusable Data . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Going to Different Users at DifferentTimes . . . . . . . . . . . 40 Collecting Task Analysis Data . . . . . . . . . . . . . . . . . . . . . 40
- 55. Another Random Document on Scribd Without Any Related Topics
- 56. Másnap megint, mint azelőtt, A száraz kortyokat nyelem. Csak menne már el a szüret, Csak menne a pokolba már! Hozná meg isten a telet, Hideg házban huzzam ki bár. Vagy meglövöm magam, vagy a Duna leszen fekvő helyem, Ha a jövő szüretkor is A száraz kortyokat nyelem. (Buda.) Verseim. A költészet fája életem, Minden versem egy levelke rajt. Fa, levél el fog hervadni majd, A felejtés szele rá sóhajt. És mivelhogy elhervadni fog, Ne is ápolgassam én e fát? Más hasznot ha nem hajt: legalább, A mig élek, hűs árnyékot ád. (Pest.)
- 57. Csokonai. Egy kálomista pap s Csokonai Egymásnak voltak jó barátai. Kilódul egyszer Debreczenből
- 58. S a jó barát előtt megáll, S: ihatnám pajtás! így kiált föl Csokonai Vitéz Mihály. »No ha ihatnál, hát majd ihatol, Akad még bor számodra valahol, Ha máshol nem, tehát pinczémben; Ottan nem egy hordó bor áll«, Szólott a pap, s leballag véle Csokonai Vitéz Mihály. »Ihol ni, ucczu!« fölkiált a pap, A mint egy hordóból dugaszt kikap; »Szaladj csapért! ott fönn felejtém; Szaladj, öcsém, de meg ne állj!« És fölrohan ló halálában Csokonai Vitéz Mihály. A likra tette tenyerét a pap; Csak vár, csak vár, hogy jön talán a csap, S a csap nem jött, és a pap morgott: »De mi az ördögöt csinál, Hol a pokolba marad az a Csokonai Vitéz Mihály?« Tovább nem győzte várni a csapot, Ott hagyta a hordót, (a bor kifolyt,) Fölmén a pinczéből a házba, De ott fönn senkit nem talál. Csak késő este érkezett meg Csokonai Vitéz Mihály. Hát a dologban ez volt az egész: Kereste ott fönn a csapot Vitéz, Zeget-zugot kikutat érte, De csak nem jön rá, hogy hol áll? É
- 59. És így csapért szomszédba mégyen Csokonai Vitéz Mihály. A szomszédban valami lakzi volt. Elébe hoztak ételt és italt; És ím az étel és bor mellett És a zenének hanginál Csapot, papot, mindent felejtett Csokonai Vitéz Mihály. (Pest.) Dáridó után. Ez volt aztán az éjszaka! Bort többé soh’se lássak, Ha életemben párja volt Ennek az áldomásnak. Egész mohácsi ütközet Ment végbe ott közöttünk; Igaz, hogy a török a bor, És a magyar mi lettünk. Hanem még az is igaz ám, Hogy harczoltunk vitézül, Kivált mikor már a király, Az ész, kidőlt nyergébül. A győzelmes poharakat Dühhel nyakon ragadtuk, S függtünk letéphetetlenűl, Mint a piócza, rajtuk. Ha oly hosszú lesz életünk, Mint kortyaink valának,
- 60. Megérjük boldogabb korát A bús magyar hazának. (Pest.) Szerelmem zúgó tenger… Szerelmem zúgó tenger, De most zúgása nem ver Órjási hánykódás közt földet és eget; Elszenderűlt, miképen A gyermek bölcsejében, Ha hosszan jajgatott és hosszan könnyezett. A síma habtükörben Evez föl és le lelkem Szelíd merengésnek hintázó csónakán; Partjáról a jövőnek Csattog felém lágy ének… Te énekelsz, remény, te kedves csalogány! (Pest.) Volnék bár… Volnék bár sivatag bús szigete A tenger közepének, Hová ember, madár nem lépne be – Csak tégedet ne ismernélek. Volnék megdermedt jégsziklája bár A messze föld végének, Mit nem melenget lanyha napsugár – Csak tégedet ne ismernélek.
- 61. Volnék bár a földöv homokja, hol A nyári nap tüzének Örök sugára égető pokol – Csak tégedet ne ismernélek. Volnék bár hallgató éjféleken Átokvert kósza lélek, Ki még koporsójában sem pihen – Csak tégedet ne ismernélek. Nem volna mérve oly nagy terhe rám A kínnak, szenvedésnek, Létem keresztjét jobban hordanám – Csak tégedet ne ismernélek. S még is, még is… nem volna életem, Az örök üdvességnek Magas helye sem tetszenék nekem, Ha tégedet nem ismernélek. (Pest.) Az én szerelmem… Az én szerelmem nem a csalogány, Kit fölkeltett a hajnalszürkület, Hogy édes ének szóljon ajakán A nap csókjától rózsás föld felett. Az én szerelmem nem kies liget, Hol csendes tóban hattyúk ringanak, Fehér nyakok mig bókot integet A vízbe néző hold sugárinak. Az én szerelmem nem nyugalmas ház, Mit kert gyanánt körűl a béke vett,
- 62. Hol a boldogság anyaként tanyáz, S tündér leányt szűl: a szép örömet. Az én szerelmem rengeteg vadon; A féltés benne mint haramja áll, Kezében tőr: kétségb’esés vagyon, Minden döfése százszoros halál. (Pest.) Szemek, mindenható szemek! Szemek, mindenható szemek! Ne nézzetek, ne nézzetek Reám oly hidegen, oly hidegen; Megöltök, ez halál nekem, Halál nekem! Vagy, oh mindenható szemek! Csak öljetek meg, öljetek; Aztán mosolygjatok, mosolygjatok, S én újolag föltámadok, Föltámadok! (Pest.) Élet, halál! nekem már mindegy! Élet, halál… nekem már mindegy! Ez a kétség irtóztató; Igy nem mehet tovább, a mint megy, És »a ki mer, nyer« példaszó. Hozzá megyek, hozzá kell mennem, Előtte szívem fölnyitom,
- 63. Hadd lássa meg, mi kín van bennem, S hogy azt mind érte hordozom. S ha szenvedésem látni fogja, S a halvány színt, melyben vagyok; Talán meglágyul indulatja, Talán majd szánakozni fog. És hátha könyvéből szemének E drága sort olvashatom: Hisz én már téged rég kisérlek, Van érted titkos bánatom. És hátha csókja szent kulcsával Nyitand számomra majd eget… Vagy, mint őrültet, szolga által Szobájából majd kilöket. (Pest.) A külföld magyarjaihoz. Ti fekélyek a hazának testén, Mit mondjak felőletek? Hogyha volnék tűz: kiégetnélek, Égetném rosz véretek. Nem vagyok tűz, nincs emésztő lángom; De van éles hangu szóm, Mely reátok átkait kiáltja, Átkait irtóztatón. Annyi kincse van hát e hazának, Hogy nem is fér benne meg? Hiszen e hon, e boldogtalan hon Oly szegény és oly beteg. É
- 64. És ti rablók! a mit orvosságra Izzad kínnal e haza: Elhordjátok idegen bálványtok, A külföld oltárira. E hazán, mely porban esd kenyérért, Nem esik meg szívetek; Míg ő vért sír, poharaitokba Kinn ti a bort töltitek. És csak akkor tértek vissza, már ha Koldusbot van nálatok: Kit koldussá tettetek, hogy tőle Ismét koldulhassatok. A miként ti e szegény hazából Magatok száműzitek: Vesse úgy ki csontotokat a sír S a mennyország lelketek! (Pest.) Mért nem születtem ezer év előtt? Mért nem születtem ezer év előtt? Midőn születtek Árpád daliái, S ragadva kardot, a vérkedvelőt, A nagy világgal mentek szembeszállni. Beh mondtam volna csataéneket, Versenyt rivalgót kürtjével Lehelnek, Melynek zugási mennydörgéseket Vadúl kavargó örvényökbe nyeltek. Beh fölvetettem volna magamat Hadvész után nyerítő paripára,
- 65. Keresni a sírt vagy babéromat Hazát teremtő harczok viharába’. Beh énekeltem volna diadalt, Vitézeimnek, párduczbőrre dőlve, Midőn az ütközetmoraj kihalt S az áldomás csengése jött helyébe. Vagyok henyélő század gyermeke, Hol megdalolni méltó tárgyam nincsen; S ha volna is, mi lenne sikere? Sínlődik a nyelv terhes rabbilincsen. (Pest.) A borhoz. Oh bor! te voltál eddig egy barátom; De látom, Hogy már kihalt tüzed, mely értem ége, S frigyünknek vége, vége. Ha eddig hozzád folyamodtam Bús állapotban, Keresztelő lett… a búbánatot Vidámsággá kereszteléd. Mért járulok hiába most eléd? Varázserődet mért nem mutatod? Fejem nehéz, És reszket már e kéz, Mely a teli Pohárt ajkamhoz emeli; Ezt befolyásod eszközölte, De nem hatál be a kebelbe: A lélek ép, Nem részegűlhet semmifélekép.
- 66. A multnak fekete Emlékzete – Mint Dejaníraköntös – rajta van Letéphetetlenűl, minduntalan. Oh bor! Ki annyiszor Voltál bajomnak orvossága, Légy most is az, bár utójára: Feledtesd el velem a gúnymosolyt, Mely lángszerelmem jégjutalma volt! (Pest.) Katona vagyok én… Katona vagyok én, kiszolgált katona, Csak káplár sem voltam, mindig közkatona. A katonasághoz ifjuságot vittem, Ott maradt az, haza öregséggel jöttem. Nagy volt pontosságom, nagy volt a hűségem, Nem volt reám mérve csak egy büntetés sem. Mi lett a jutalmam, mikor kiszolgáltam? A generális megveregette vállam. (Pest.) Szivem, te árva rabmadár! Szivem, te árva rabmadár! Kit szűk, szoros kalitka zár, Légy csendesebben odabenn, Ne hánykolódjál oly igen; Ugy meg találod sérteni
- 67. Magad, hogy vér fog ömleni… Vagy üsd meg magadat tehát, Jőjön halálos seb reád; Véreddel majd megírhatom Szerelmem és hattyúdalom. (Pest.) Gyere lovam… Gyere, lovam, hadd tegyem rád nyergem! Galambomnál kell még ma teremnem. A kengyelbe most teszem bal lábam, De lelkem már a galambomnál van. Száll a madár, tán párjához siet; Sebesen száll, el is hagyott minket. Érjük utol szaporán, jó lovam, A párját ő sem szereti jobban. (Pest.) A leánykákhoz. Ne haragudjatok rám, Leánykák, lelkeim! Hogy oly sokszor beszélnek A borról verseim. Ti nem gondolhatjátok, Mily bús az életem, Hogy gyakran a keservek Keservét szenvedem.
- 68. Mig olvassátok tőlem A tréfás dalokat, Nem sejtitek, hogy néha Szivem majd megszakad. S lássátok, szépeim! ha A bú nekem rohan, Mint felbőszült oroszlán, Emésztő-szilajan; Ha a világ előttem Éjjé sötétedik, S a sötétséges éjben Vihar kerekedik, És a vihar szivemben Dúl irgalmatlanúl: Csak a bor, a mitől ez Ismét lecsillapúl. Lecsillapúl lassanként, Elzúg a fergeteg, S én újólag vidám, kék Eget szemlélhetek; S a fölvidámult égen A régi fényben jár A jó kedv holdja, a szép Örömcsillagsugár. Ily jótevő orvosság A szőlőnedv nekem; Nem egyszer menté meg már Megúnt, bús életem. Mert gyakran voltam úgy, hogy Csak még egy pillanat…
- 69. S most pókháló födözné Versíró tollamat, Mig én magam fekünném A sírban hidegen, S a föld hideg porával Vegyűlne tetemem – – – Ne haragudjatok hát, Leánykák, lelkeim! Hogy oly sokszor beszélnek A borról verseim. (Pest.) Szülőimhez. Hejh édes szülőimék, Gazdagodjam meg csak! Akkor, hiszem istenem, Nem panaszolkodnak. Minden teljesülni fog, A mit csak kivánnak; Megelőzöm vágyait Éd’s apám s anyámnak. Lesz csinos ház, a miben Megvonúlnak szépen; Pincze lesz a ház alatt, Jó bor a pinczében. Meghihatja éd’s apám Minden jó barátját; Borozás közt lelköket A jó kedvbe mártják.
- 70. Szép kocsit csináltatok Éd’s anyám számára; Nem kell, hogy a templomot Gyalogosan járja. Lesz arany szegélyzetű Imádságos könyve, Krisztus urunk képe lesz Szépen metszve benne. Pistinak meg majd veszek Drága paripákat, Rajtok jó Istók öcsém Vásárokra járhat. Végesvégül lesz nekem Dúsgazdag könyvtárom; Akkor majd a verseket Nem pénzért csinálom. Ingyen osztom azokat Szét az ujságokba; Minden szerkesztő, tudom, Szivesen fogadja. S hogyha szép lyányt kaphatok: – De magyar lelkűt ám! – Éd’s apám tánczolni fog Fia lakodalmán. Igy élünk majd boldogan A mulatságoknak, Igy biz, édes szüleim… Gazdagodjam meg csak! (Pest.)
- 71. Boldog éjjel… Boldog éjjel! együtt vagyok rózsámmal, A kis kertben mulatozunk egymással; Csendesség van, csak az ebek csaholnak, Fenn az égen Tündérszépen Ragyog a hold, a csillag. Nem jó csillag lett volna én belőlem; Tudja isten, nem maradnék az égen, Nem kellene én nekem a mennyország, Lejárnék én Minden estén, Kedves rózsám, tehozzád. (Pest.) Fényes csillag… Fényes csillag, mondd meg nekem. Mért nem maradtál odafenn? Mondd meg: arra mi ok szolgál, Hogy az égről lefutottál? »Csak az az ok szolgál arra, Mert rá néztem galambodra; Sugaramnál szebb a szeme, Bosszankodás kergetett le.« (Pest.) A természet vadvirága.
- 72. Mit ugattok, mit haraptok Engemet, hitvány ebek! Torkotokba, hogy megfúltok, Oly kemény konczot vetek. Nyirbáljatok üvegházak Satnya sarjadékain: A korláttalan természet Vadvirága vagyok én. Nem verték belém tanítók Bottal a költészetet, Iskolai szabályoknak Lelkem soh’sem engedett. Támaszkodjék szabályokra, Ki szabadban félve mén. A korláttalan természet Vadvirága vagyok én. Nem virítok számotokra, Árva finnyás kóficzok! Kiknek gyönge, kényes, romlott Gyomra mingyárt háborog; Van azért, ki ép izléssel Üdvezelve jön elém. A korláttalan természet Vadvirága vagyok én. Hát azért nekem örökre Szépen békét hagyjatok; Ugy sem sok gyümölcsü munka: Falra borsót hánynotok. S kedvetek ha jön kötődni, Ugy kapkodjatok felém: A természetnek tövises Vadvirága vagyok én.
- 73. (Pest.) Esik, esik, esik… Esik, esik, esik, Csókeső esik; Az én ajakamnak Nagyon jól esik. Az eső, az eső Villámlással jár; A szemed, galambom, Villámló sugár. Mennydörög, mennydörög A hátunk megett; Szaladok, galambom, Jön az öreged. (Pest.) Levél egy szinész barátomhoz. Jut még eszedbe a fiú? kivel Együtt czepelted a vándorbotot, Mely koldusbotnak is beillenék, Midőn a sorsnak fényes kedve nincs; És ez nem épen olyan ritkaság Szinészre nézve, mint boldogtalan Magyar hazánkban a hű honfigond. – Lásd, én reátok még emlékezem, És elfeledni nem fogom soha A jót s roszat, mely ott közöttetek Mult napjaimnak osztályrésze volt. Előttem áll a délután, midőn
- 74. A színészetbe béavattatám. Barangolék föl és le czéltalan A nagy hazának minden tájain. Tarisznyámban, mit hátamon vivék, Nem mondhatom, hogy nagy volt a teher, De a nyomor, mint ólom, megnyomott. Könnyíte rajt a víg könnyelműség, Mely útaimban hű társam vala. Ekkép juték egy nyári délután Egy kis városba; fáradt lábaim A fogadóban megpihentenek. – Vendégszobája egyik oldalán Helyet szerényen színpad foglala. Mire való is már a fényüzés?… Azon tünődtem épen: kérjek-e Ebédet vagy se? hát ha majd sovány Zsebem bicskája szépen bentörik? Az ajtót ekkor megnyitá egy ur; Volt bennem annyi emberismeret, Rá foghatnom, hogy nem más mint szinész. Fején kalapja nagybecsű vala, Mert Elizéus prófétával az Rokonságban volt… tudnillik: kopasz. Kabátja új, a nadrág régi rongy, És lábát csizma helytt czipő födé, Alkalmasint a melyben szerepelt. »Thalia papja?« kérdém. »Az vagyok; Talán ön is?« – »Még eddig nem.« – »Tehát Jövőben? fölség…« – »Azt sem mondhatom«, Vágtam szavába; ámde ő rohant, S vezette gyorsan az igazgatót. Fehér köpenyben az igazgató Jött üdvezelni engem nyájasan: »Isten hozá önt, tisztelt honfitárs! Lesz hát szerencsénk önhöz, édes ur? Imádja úgy-e a művészetet?
- 75. Ah, jó barátom, isteni is az! S önnek szeméből olvasom ki, hogy Szinészetünknek egykor hőse lesz, És kürtölendik bámult nagy nevét A két hazának minden ajkai… Ebédelt már ön? itt az ételek Fölötte drágák, s a mi több: roszak. Az ispán urtól őzczombot kapánk, A káposztából is van maradék – Ha meghivásom nem méltóztatik Elútasítni: jó ebédje lesz.« Igy ostromolt a jó igazgató, Forgatva nyelve könnyü kerekét. Én nem rosz kedvvel engedék neki. Menék ebédre, és ebéd után Beiktatának ünnepélyesen A társaságba – nem kutatva: mi Valék, deák-e vagy csizmadia? Másnap fölléptem a Peleskei Notáriusban. Hősleg működém Három szerepben, minthogy összesen A társaságnak csak hat tagja volt. – Egy ideig csak elvalék velök; Faluzgatánk jó s bal szerencse közt. De a barátság végre megszakadt, Mert én utáltam a nyegléskedést, A sok »utószor«-t, a görögtüzet, S tudj’ a manó, mily csábitásokat. A társaság is végre szétoszolt Egymást érő bel- s külviszály miatt; S én ujra jártam széles e hazát, Mignem keblébe vett más társaság. Mit ottan, itt is azt tapasztalám, S tapasztalásom nem volt olyatén, Mely kedvre hozta volna lelkemet. Kenyért keresni színészek leszünk,
- 76. Nem a művészet szent szerelmiből, S haladni nincsen semmi ösztönünk. »Pártolj, közönség, és majd haladunk«, Mond a szinész; és az meg így felel: »Haladjatok, majd aztán pártolunk;« És végre mind a kettő elmarad. Nem is hiszem, hogy a szinészetet Becsülni fogják, míg az befogad Minden bitangot, gaz sehonnait, Kik a világnak söpredékei, S itten keresnek biztos menhelyet. Barátom, ez fájt én nekem s neked, Ez keseríte minket annyira. Az isten adja, hogy minél előbb Akképen álljon szinművészetünk, A mint valóban kéne állnia. (Pest.) Az öreg úr. Az öreg urnak élete Szánandó gyötrelem, Veséig gyötri a szegényt, Féltékeny szerelem. Unokaöcscse oly gonosz, S szép, ifju a neje; Unokaöcscse ver szöget Megőszült fejibe. Míg nőtlen volt: terhére nem Esett a hivatal, Nyugottan, híven végezé; De most majd belehal.
- 77. Míg nőtlen volt: barátinál El-elkártyázgatott; De mostan éjszakázni fél… Keserves állapot! Míg nőtlen volt: álom között Folyának éjei; De most az öreg úr szemét Behúnyni sem meri. Pedig, pedig, szegény öreg, Féltés hiába bánt; Öcséd nődet nem szereti… Hanem a szobalyányt. (Pest.) Szerelem, szerelem… Szerelem, szerelem, Keserű szerelem! Miért bántál olyan Kegyetlenűl velem? Te voltál szivemben Első és utósó, Nem sokára készül Számomra koporsó. Elmegyek az ácshoz, Fejfát csináltatok, Egyszerű fejfámra Csak egy sort iratok; Fekete betűkkel Ez lesz írva rája: »Itt hervad a hűség Eltépett rózsája.«
- 78. (Pest.) János gazda. János gazda derék gazda, Nincsen párja hat faluba’; Csak egy a bibéje, Hogy soha sincs pénze. Széles, hosszú szántóföldje, Sok gabona terem benne, Vásárra jár véle, Még sincs soha pénze. Nem kóborol a kocsmába, Kocsmárosra nem kiáltja: Hejh, bort az icczébe! Még sincs soha pénze. Felesége szép, takaros, Legényekre nem haragos, Kivált béresére… Hát azért nincs pénze. (Pest.) A tintás-üveg. Vándorszinész korába Megyeri (Van-e, ki e nevet nem ismeri?) Körmölgeté, mint más, a színlapot. Kapott Ezért Egyszer vagy öt forintnyi bért,
- 79. A mint mondom, vagy öt forintnyi bért. Először is hát tintáért megyen, Ha ismét írni kell, hogy majd legyen. A tintás-üveget pedig hová Dugá? Bele Kabátja hátsó zsebibe, A mint mondom, kabátja zsebibe. S hogy pénzre tett szert, lett Megyeri vig, S haza felé menvén, ugrándozik. Hiába inti őt Szentpéteri: »Kari, Vigyázz! Kedved majd követendi gyász, A mint mondom, majd követendi gyász.« Ugy lett. A sok ugrándozás alatt Kifolyt a tinta; foltja megmaradt. Megyeri elbusúlt – kedvét szegi Neki A folt, Mivel csak egy kabátja volt, A mint mondom, csak egy kabátja volt, Mi több: kabátja épen sárga volt, És igy annál jobban látszott a folt. »Eldobnám – szólt – de mással nem birok;« Ez ok Miatt Hordá, mig széjjel nem szakadt, A mint mondom, mig széjjel nem szakadt. (Pest.)
- 80. Mit szól a bölcs? Hm, bizony csak sok nem úgy halad, A mint kéne, itt a nap alatt. Szikrát sem törődve szól a bölcs: Itt van a pohár, hol a bor? tölts! Tenger a pénz, melyben elsülyed Sok hajó: elv, jellem, becsület. Szikrát sem törődve szól a bölcs: Itt van a pohár, hol a bor? tölts! Korpafőt diszít selyem kalap, S az okos fő teng darócz alatt. Szikrát sem törődve szól a bölcs: Itt van a pohár, hol a bor? tölts! A lét könyviből e szót »barát« Az idők régen kivakarák. Szikrát sem törődve szól a bölcs: Itt van a pohár, hol a bor? tölts! Egyenesség, nyilt őszinteség Rókaságnak zsákmányúl esék. Szikrát sem törődve szól a bölcs: Itt van a pohár, hol a bor? tölts! Feleséghűség járatlan ut, Rajta már csak az együgyü fut. Szikrát sem törődve szól a bölcs: Itt van a pohár, hol a bor? tölts! Igazmondás elhajított kő, Hajító fejére visszajő. Szikrát sem törődve szól a bölcs:
- 81. Itt van a pohár, hol a bor? tölts! Megterem sok prédikáczió, Nem igen hallgatják, bármi jó. Szikrát sem törődve szól a bölcs: Itt van a pohár, hol a bor? tölts! (Pest.) Pál mester. Pál mester ilyformán okoskodott, És félre csapta Szilajhegykén a kalapot: »Eh, a ki adta! Mire való a feleség nekem? Nélkűle szabadabb lesz életem; Elkergetem… az lesz belőle.« És ugy tett, a miként beszéle. Pál mester később így okoskodott, Csak hogy nem csapta Ő félre most a kalapot: »Hejh, a ki adta! Még is csak kár volt elkergetnem őt; Kezében gazdaságom egyre nőtt, S most elpusztúl… az lesz belőle.« És ugy lett, a miként beszéle. Pál mester ekkor így okoskodott, És félre csapta Ismét hegykén a kalapot: »Eh, a ki adta! Mi haszna minden búm és bánatom? Ugy sincs sokam; azt is tovább adom, Tovább adom… az lesz belőle.« É
- 82. És ugy tett, a miként beszéle. Pál mester végre így okoskodott, S szemére csapta Keservesen a kalapot: »Hejh, a ki adta! Most már minden, de minden oda van; Mi tévő légyek? felkössem magam? Fel, felkötöm… az lesz belőle.« És ugy tett, a miként beszéle. (Pest.) Részegség a hazáért. Fiuk, az isten áldjon meg, Én is iszom, igyatok! Én nem nézhetek vidámon Végig elhagyott hazámon, Csak mikor részeg vagyok! Ekkor úgy látom hazámat, A mint kéne lennie; Mindenik pohár, a melynek Habjai belém ömölnek, Egy sebét hegeszti be. S ha mig részeg vagyok: boldog Volna a hon csakugyan, Bár örökké kéne élnem, Fiuk, nem láthatna éngem Soha senki józanan. (Pest.)
- 83. Szerelem és bor. Azt mondom, a mit mindig mondok: Ne háborgassanak a gondok, Ne háborgassanak bennünket! Legyen vidámság, tréfa, nesz; Ifjak vagyunk, és ifjuságunk Idő jártával oda lesz. Járjunk a szerelem kertében, Virág ott nyílik minden lépten; Ha meg talál tüskéje szúrni: Illatja gyógyulást szerez. Szeressünk! mert erőnk, szeretni, Idő jártával oda lesz. Midőn a szerelem kertében, A nap tikkasztón süt az égen: Térjünk hüs árnyékú lugasba A borgyümölcs tőkéihez. Igyunk! pénzünk van, hátha pénzünk Idő jártával oda lesz. E kép a legszebb élet képe; Adjunk érette bút cserébe. Mint fellegekre a szivárvány, Reánk mosolyogni fog ez, Ha majd derengő ifjuságunk Idő jártával oda lesz. (Pest.) Etelkéhez.
- 84. Láttad-e, angyalom, a Dunát S a szigetet közepén? Ide szivembe képedet Akként foglalom én. A szigetről zöld fa-lomb Mártja a vízbe magát; Ha te szivembe igy a remény Zöldjét mártanád! (Buda.) Rabhazának fia. Menjünk, menjünk a földbe, Beteg szivem! Hiszen Megtetted, a mit kelle, Megtetted, a mit lehetett: Viselted honfisebedet. Hideg van a siréjben; Másnak lehet… Meleg, Forró lesz a sir nékem: Mit életemben viselék, A honfisebb még ott is ég. De az itélet napja Eljön talán, S hazám Bilincseit lerontja. Akkor sebem begyógyuland, S hüvösben nyugszom ott alant. (Pest.)
- 85. Lant és Kard. Felhős az ég hazámon, Aligha nem lesz vész; Csak hadd legyen, nem bánom, Lelkem reája kész. Lantom nagyon szeretne Hallgatva állani, Régóta van kezembe’, Már kopnak húrjai.
- 86. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com