<Previous Lesson

Human Computer Interaction

Next Lesson>

Lesson#23

REQUIREMENTS

As the aim of this lecture is to introduce you the study of Human Computer
Interaction, so that after studying this you will be able to:

. Understand the narratives and scenarios

. Define requirements using persona-based design
It has already been discussed how to capture qualitative information about users.
Through careful analysis of this information and synthesis of user models, we can get
a clear picture of our users and their respective goals. It has also been explained how
to prioritize which users are the most appropriate design targets. The missing piece to
the puzzle, then, is the process of translating this knowledge into coherent design
solutions that meet the needs of users while simultaneously addressing business needs
and technical constraints.
Now we shall describe a process for bridging the research-design gap. It employs
personas as the main characters in set of techniques that rapidly arrive at design
solutions in an iterative repeatable, and testable fashion. This process has three major
milestones: defining user requirements; using these requirements to in turn define the
fundamental interaction framework for the product; and filling in the framework with
ever-increasing amounts of design detail. The glue that holds the process together is
narrative: use of personas to tell stories that point to design.

23.1 Narrative as a design tool

Narrative, or storytelling, is one of the oldest human activities. Much has been written
about the power of narrative to communicate ideas. However, narrative can also,
through its efficacy at engaging and stimulating creative visualization skills, serve as
a powerful tool in generating and validating design ideas. Because interaction design
is first and foremost the design of behavior that occurs over time, a narrative structure,
combined with the support of minimal visualization tools such as the whiteboard, is
perfectly suited for envisioning and representing interaction concept. Detailed
refinement calls for more sophisticated visual and interactive tools, but the initial
work of defining requirements and frameworks is best done fluidly and flexibly, with
minimal reliance on technologies that will inevitably impede ideation.

Scenarios in design

Scenario is a term familiar to usability professional, commonly used to describe a
method of design problem solving by concretization: making use of a specific story to
both construct and illustrate design solutions. Scenarios are anchored in the concrete,
but permit fluidity; any member of the design team can modify them at will. As
Carroll states in his book, Making Use:
Scenarios are paradoxically concrete but rough, tangible but flexible … they
implicitly encourage ‘what-if’? Thinking among all parties. They permit the
articulation of design possibilities without understanding innovation ….

212
Scenarios compel attention to the use that will be made of the design product.
They can describe situations at many levels of detail, for many different
purposes, helping to coordinate various aspects of the design project.
Carroll’s use of scenario-based design focuses on describing how users accomplish
tasks. It consists of an environment setting and includes agents or actors that are
abstracted stand-ins for users, with role-based names such as Accountant or
Programmer.
Although Carroll certainly understands the power and importance of scenarios in the
design process, there can be two problems with scenarios as Carroll approaches them:

. Carroll’s scenarios are not concrete enough in their representation of the
human actor. It is impossible to design appropriate behaviors for a system
without understanding in specific detail the users of the system. Abstracted,
role-oriented models are not sufficient concrete to provide understanding or
empathy with users.

. Carroll’s scenarios jump too quickly to the elaboration of tasks without
considering the user’s goals and motivations that drive and filter these tasks.
Although Carroll does briefly discuss goals, he refers only to goals of the
scenario. These goals are somewhat circularly defined as the completion of
specific tasks. Carroll’s scenarios begin at the wrong level of detail: User
goals need to be considered before user tasks can be identified and prioritized.
Without addressing human goals, high-level product definition becomes
difficult.
The missing ingredient in scenario-based methods is the use of personas. A persona
provides a sufficiently tangible representation of the user to act as a believable agent
in the setting of a scenario. This enhances the designer’s ability to empathize with
user mental models and perspectives. At the same time, it permits an exploration of
how user motivations inflect and prioritize tasks. Because personas model goals and
not simply tasks, the scope of the problem that scenarios address can also be
broadened to include product definition. They help answer the questions, “ what
should this product be?” and “how should this product look and behave?”

Using personas in scenarios

Persona-based scenarios are concise narrative descriptions of one or more personas
using a product to achieve specific goals. Scenarios capture the non-verbal dialogue
between artifact and user over time, as well as the structure and behavior of
interactive functions. Goals serve as filter for tasks and as guides for structuring the
display of information and controls during the interactive process of constructing the
scenarios.
Scenario content and context are derived from information gathered during the
Research phase and analyzed during the modeling phase. Designers role-play
personas as the characters in these scenarios, similar to actors performing
improvisation. This process leads to real-time synthesis of structure and behavior—
typically, at a whiteboard—and later informs the detailed look and feel. Finally,
personas and scenarios are used to test the validity of design ideas and assumptions
throughout the process. Three types of persona-based scenarios are employed at
different points in the process, each time with a successively narrower focus.

213

Persona-based scenarios versus use cases

Scenarios and use cases are both methods of describing a digital system. However,
they serve very different functions. Goal-directed scenarios are an iterative means of
defining the behavior of a product from the standpoint of specific users. This includes
not only the functionality of the system, but the priority of functions and the way
those functions are expressed in terms of what the user sees and how he interacts with
the system.
Use cases, on the other hand, are a technique that has been adopted from software
engineering by some usability professionals. They are usually exhaustive description f
functional requirements of the system, often of a transactional nature, focusing on
low-level user action and system responds—is not, typically, part of conventional or
concrete use case, many assumptions about the form and behavior of the system to be
designed remain implicit. Use cases permit a complete cataloguing of user tasks for
different classes of users, but say little or nothing about how these tasks are presented
to the user or how they should be prioritized in the interface. Use cases may be useful
in identifying edge cases and for determining that a product is functionally complete,
but they should be deployed only in the later stages of design validation.

23.2 Envisioning solutions with persona-based design

It has already been discussed that the translation from robust models to design
solutions really consists of two major phases. Requirements Definition answers the
broad questions about what a product is and what it should do, and Framework
Definition answers questions about how a product behaves and how it is structured to
meet user goals. Now we look Requirement Definition phase in detail.

Defining the requirements

The Requirement Definition phase determines the what of the design: what functions
our personas need to use and what kind of information they must access to accomplish
their goals. The following five steps comprise this process:
1. Creating problem and vision statement
2. Brainstorming
3. Identifying persona expectations
4. Constructing the context scenario
5. Identifying needs
Although these steps proceed in roughly chronological order, they represent an
iterative process. Designers can expect to cycle through step 3 through 5 several times
until the requirements are stable. This is a necessary part of the process and shouldn’t
be short-circuited. A detailed description of each of these steps follows.

Step1: Creating problem and vision statement

Before beginning any process of ideation, it’s important for designers to have a clear
mandate for moving forward, even if it is a rather high-level mandate. Problem and
vision statements provide just such a mandate and are extremely helpful in building
consensus among stakeholders before the design process moves forward.
At a high level, the problem statement defines the objective of the design. A design
problem statement should concisely reflect a situation that needs changing, for both

214
the personas and for the business providing the product to the personas. Often a
cause-and-effect relationship exists between business concerns and persona concerns.
For example:
Company X’s customer satisfaction ratings are low and market share has
diminished by 10% over the past year because users don’t have adequate tools
to perform X, Y and Z tasks that would help them meet their goal of G.
The connection of business issues to usability issues is critical to drive stakeholders’
buy-in to design efforts and to frame the design effort in term of both user and
business goals.
The vision statement is an inversion of the problem statement that serves as a highlevel
design vision or mandate. In the vision statement, you lead with the user’s
needs, and you transition from those to how business goals are met by the design
vision:
The new design of Product X will help users achieve G by giving them the
ability to perform X, Y and Z with greater [accuracy, efficiency, and so on],
and without problems A, B, C that they currently experience. This will
dramatically improve Company X’s customer satisfaction ratings and leads to
increased market share.
The content of both the problem and vision statement should come directly from
research and user models. User goals and needs should derive from the primary and
secondary personas, and business goals should be extracted from stakeholder
interviews.

Step 2: Brainstorming

Brainstorming performed at this earlier stage of Requirements Definition assumes a
somewhat ironic purpose. As designers, you may have been researching and modeling
users and the domain for days or even weeks. It is almost impossible that you have
not had design ideas percolating in your head. Thus, the reason we brainstorming at
this point in the process is t get these ideas out our heads so we can “let them go” at
least for the time being. This serves a primary purpose of eliminating as much
designer bias as possible before launching into scenarios, preparing the designers to
take on the roles of the primary personas during the scenario process.
Brainstorming should be unconstrained and critical—put all the wacky ideas you’ve
been considering (plus some you haven’t) out n the table and be the prepared to
record them and file them away for safekeeping until much later in the process. It’s
not likely any of them will be useful in the end, but there might be the germ of
something wonderful that will fit into the design framework you later create.
Holtzblatt & Beyer describe a facilitated method for brainstorming that can be useful
for getting a brainstorming session started, especially if your team includes nondesigners.

Step 3: Identifying persona expectations

The expectations that your persona has for a product and its context of use is,
collectively, that persona’s mental model of the product. It is important that the
representation model of the interface—how the design behaves and presents itself—
should match the user’s mental model as closely as possible, rather than reflecting the
implementation model of how the product is actually constructed internally.
For each primary persona you must identify:

215

. General expectations and desires each may have about the experience of using
the product

. Behaviors each will expect or desire from the product

. Attitude, past experience, aspirations and other social, cultural, environmental
and cognitive factors that influence these desires
Your persona descriptions may contain enough information to answer some of these
questions directly; however, you should return to your research data to analyze the
language and grammar of how user subjects and describe objects and actions that are
part of their usage patterns.
Some things to look for include:

. What do the subjects mention first?

. Which action words (verbs) do they use?

. Which intermediate steps, tasks, or objects in a process don’t they mention?
After you have compiled a good list of expectations and influences, do the same for
secondary and customer personas and crosscheck similarities and differences.

Step 4: constructing context scenarios

Scenarios are stories about people and their activities. Context scenarios are, in fact,
the most story-like of the three types of scenario we employ in that the focus is very
much on the persona, her mental models, goals, and activities. Context scenarios
describe the broad context in which usage patterns are exhibited and include
environmental and organizational considerations. Context scenarios establish the
primary touch-points that each primary and secondary persona has with the system
over the course of a day, o some other meaningful length of time that illuminates
modes of frequent and regular use. Context scenarios are sometimes, for this reason,
called day-in-the-life scenarios.
Context scenarios address questions such as the following

. What is the setting in which the product will be used?

. Will it be used for extended amounts or time?

. Is the persona frequently interrupted?

. Are there multiple users on a single workstation/device?

. What other products is it used with?

. How much complexity is permissible, based on persona skill and frequency of
use?

. What primary activities does the persona need to accomplish to meet her
goals?

. What is the expected end result of using the product?
To ensure effective context scenarios, keep them broad and relatively shallow in
scope. Resist the urge of dive immediately into interaction detail. It is important to
map out the pig picture first and systematically identify needs. Doing this and using
the steps that follow prevent you from getting lost in design details that may not fit
together coherently later.

216
Context scenarios should not represent system behaviors as they currently are. These
scenarios represent the brave new world of goal-directed products, so, especially in
the initial phases, focus on the goals. Don’t yet worry about exactly how things will
get accomplished—you can initially treat the design as a bit of a magic black box.
Sometimes more than one context scenario is necessary. This is true especially when
there are multiple primary personas, but sometimes even a single primary persona
may have two or more distinct contexts of use.
An example text scenario
The following is an example of a first iteration of a context scenario for a primary
persona for a PDA/phone convergence device and service; Salman, a real-estate agent
in Lahore. Salman’s goals are to balance work and home life, cinch the deal, and
make each client feel like he is his only client.
Salman’s context scenario might be as follow:
1. Getting ready in the morning, Salman uses his phone to check e-mail. It has a
large enough screen and quick connection time so that it’s more convenient
than booting up a computer as he rushes to make his daughter, Alia, a
sandwich for school.
2. Salman sees e-mail from his newest client who wants to see a house this
afternoon. Salman entered his contact info a few days ago, so now he can call
him with a simple action right from the e-mail.
3. While on the phone with his client, Salman switches to speakerphone so he
can look at the screen while talking. He looks at his appointments to see when
he’s free. When he creates a new appointment, the phone automatically makes
it an appointment with client, because it knows with whom he is talking. He
4. quickly keys the address of the property into the appointment as he finishes his
conversation.
5. After sending Alia off to school, Salman heads into the real-estate office to
gather the papers he needs for the plumber working on another property. His
phone has already updated his Outlook appointments so the rest of the office
knows where he’ll be in the afternoon.
6. The day goes by quickly, and he’s running a bit late. As he heads towards the
property he’ll be showing client, the phone alerts him that his appointment is
in 15 minutes. When he flips open the phone, it shows not only the
appointment, but a list of all documents related to client, including e-mail,
memos, phone messages, call logs to client’s number, and even thumbnail
pictures of the property that Salman sent as e-mail attachments. Salman
presses the call button, and the phone automatically connects to client because
it knows his appointment with him is soon. He lets him know he’ll be there in
20 minutes.
7. Salman knows the address of the property, but is a bit unsure exactly where it
is. He pulls over and taps the address he put into the appointment. The phone
downloads directions along with a thumbnail map showing his location
relative to the destination.
8. Salman gets to the property on time and starts showing it to client. He hears
the phone ring from his pocket. Normally while he is in an appointment, the
phone will automatically transfer directly to voicemail, but Alia has a code she
can press to get through. The phone knows it’s Alia calling, and uses a
distinctive ring tone.

217
9. Salman takes the call—Alia missed the bus and needs a pickup. Salman calls
her daughter and ask her that he will pick her up after 30 minutes.
Now how the scenario remains at a fairly high level, not getting into too specific
about interface or technologies. It’s important to create scenarios that are within the
realm of technical possibility, but at this stage the details of reality aren’t yet
important.

Step 5: identifying needs

After you are satisfied with an initial draft of your context scenario, you can begin to
analyze it to extract the persona’ needs. These needs consist of objects and actions as
well as contexts. It is preferred not to think of needs as identical to tasks. The
implication is that tasks must be manually performed by the user, whereas the term
needs implies simply that certain objects need to exist and that certain actions on them
need to happen in certain contexts. Thus, a need from the scenario above might be:
Call (action) a person (object) directly from an appointment (context)
If you are comfortable extracting needs in this format, it works quite well; you can
separate them as described in the following sections.
Data needs
Persons’ data needs are the objects and information that must be represented in the
system. Charts, graphs, status markers, document types, attributes to be sorted,
filtered, or manipulated, and graphical object types to be directly manipulated are
examples of data needs.
Functional needs
Functional needs are the operations that need to be performed on the objects of the
system and which are eventually translated into interface controls. Functional needs
also define places or containers where objects or information in the interface must be
displayed.
Contextual needs and requirements
Contextual needs describes relationships between sets of objects or sets of controls, as
well as possible relationship between objects and controls. This can include which
types of objects to display together to make sense for workflow or to meet specific
persona goals, as well as how certain objects must interact with other objects and the
skills and capabilities of the personas using the product.

Other requirements

It’s important to get a firm idea of the realistic requirements of the business and
technology you are designing.

. Business requirements can include development timelines, regulations, pricing
structures, and business models.

. Technical requirements an include weight, size, form-factor, display, power
constraints, and software platform choices.

. Customer and partner requirements can include ease of installation,
maintenance, configuration, support costs, and licensing agreements.
Now design team should have a mandate in the form of the problem and vision
statements, a rough, creative overview of how the product is going to address user

218
goals in the form of context scenarios, and a reductive list of needs and requirements
extracted from your research user models, and scenarios. Now you are ready to delve
deeper into the details of your product’s behaviors, and begin to consider how the
product and its functions will be represented.

<Previous Lesson

Human Computer Interaction

Next Lesson>

Home

Lesson Plan

Topics

Go to Top

Next Lesson
Previous Lesson
Lesson Plan
Topics
Home
Go to Top