Analysis

1. User Profiles
2. Personae
3. Scenarios
 Interaction Design Process
Profiles
Personae
Scenarios
what is Task analysis
wanted guidelines
principles
Interviews analysis precise
Ethnography specification
Exploratory evaluation design

what is there dialogue implement

vs. notations and deploy
what is wanted evaluation
prototype
heuristics architectures
documentation
help
Analysis
Iterative Design
Do not focus on only the “best” or most
experienced users

Consider a range of users to ensure that

your product works for at least 80% of your
user population.

However, it is not impracticable to target

90–95% of the population.
1. User Profiling
Defining User
You need to define what you mean by “user.”
Most people consider the individuals who will interact
directly with the product as their users, but you may
need to consider other individuals as well:
The manager of your direct user
The system administrator who configures the product for
the direct user
People who receive artifacts or information from the
system
People deciding whether they will purchase your software

who use competitors’ products (you want to convert

them to use your product).
Categorizing Users
Primary
individuals who work regularly or directly with the
product

Secondary
use the product infrequently or through an intermediary

Tertiary
affected by the system or the purchasing decision-
makers

All of these individuals have an interest in the product

User Profile
You should begin by developing a user
profile.
This is a detailed description of your users’
attributes (job title, experience, level of
education, key tasks, age range, etc.).

the typical users might be between 18 and

35 years of age, have job titles like “Travel
Specialist,” “Travel Agent,” or “Travel
Assistant,” and work for travel agencies
with fewer than 50 employees.
User Profile
2. Personae
The Persona
A persona is a prototypical user:
An imaginary, but very specific, example of a
particular type of user.
Not “real”, but hypothetical.

A persona is used to role-play through an

interface design and check if the design would
meet the needs of such a user.

It is more important to define the persona in

great and specific detail, so that it cannot
wiggle under the pressure of development.
 Defining a Persona
Attribute Details
Identity Give this user a first and last name. Provide an age and other
demographic information that would be representative of the user
profile. Include a picture as well. If you have a face to go with the
name, the persona is more realistic and easier to associate with.
Status Is this a primary, secondary, tertiary, or anti-user of your system?
Goals What are this user’s goals? Do not limit yourself to goals related to
your specific product.
Skill set What is the background and expertise of your user? This includes
education, training, and specialized skills. Again, do not limit
yourself to details related to your specific product.
Tasks What are the basic or critical tasks the user conducts? What is the
frequency, importance, and duration of those tasks? More detailed
task information is included in scenarios.
Relationshi Understanding with whom the user associates is important.
ps Including relationships in the persona keeps you thinking about
secondary and tertiary stakeholders.
Requiremen What does your user need? Including quotes will really drive those
ts needs home.
Expectation How does the user think the product works? How does the user
s organize the information in his or her domain/job?
Photograph Include a photo in your persona to put a human face to your end
user.
An Example Persona
 Alexandra Davis’s Persona (contd.)
She loves the perks she gets working for TravelSmart.com. She is able to
travel all over the world with her family at a substantially reduced rate. This is
very important to her and she wouldn’t work those kinds of hours without
such perks. Alexandra began working as a travel agent right after college. She
has used every system out there and is amazed at how difficult they are to
use. Speed is the name of the game. “Clients don’t want to sit on the phone
and listen to typing for five minutes while I look up all the available five-star
hotels in Barbados. I need that information with few keystrokes and all on one
screen. Don’t make me page through screen after screen to see the rates for
all the hotels.” Alexandra loves helping clients design their dream vacation!
She helps to take care of all of their travel needs – including choosing
destinations, booking airfares, arranging car rentals, booking hotels, and
arranging tickets for attractions. Clients often send Alexandra postcards and
pictures from their destinations because they are so grateful for all her help.
She appreciates the fact the TravelSmart.com offers clients the opportunity to
do it all themselves or to seek out the help of a professional. She feels that
travel agents are sorely under-appreciated.“Of course people can make travel
reservations on any website today. There are tons of them out there and they
all offer pretty much the same deals. But if you don’t know anything about
your destination, you could easily pick a bad hotel because their advertising
literature is out of date, or you could pay too much because you don’t know
what to ask for. Travel agents do so much more than book flights!”
Primary and Secondary Personae
A primary persona will not be satisfied with
a design for someone else.
If there are multiple personas with radically
different needs, there are multiple primaries.
Each primary gets their own interface.

A secondary persona is mostly satisfied

with a primary’s interface, but has a
specific additional need.
Case: In-Flight Entertainment
System
In Flight for Zoom Airways
At each seat a touch-screen video console

36 films in five categories, 36 music channels, news,

children's shows, games, shopping.

computers + large hard disks in front of the plane.

true video on demand – each passenger can start, pause, and

rewind programs independently

Two Separate Interfaces

 One for the passengers in the seat console.
 A different one for employees in the attendant’s station.
InFlight for Zoom Airways
Step 1: Know Thy Users
The seat console interface has to satisfy

First class
Business class
Economy class
Children
Elderly
Etc.
Defining Personae

Chuck knows his vast flying experience has earned him

some shortcuts, but he does not mind investing a little
effort into remembering those special commands.
Defining Personae

Marie is similar to Chuck, and both would be

annoyed by time-consuming training screens
for new users.
Defining Personae

Erin knows wanting to play games is something

special, so she does not mind pressing a few
extra buttons to get them.
Final Prototype
Defining Goals for each Persona
Goals and personas co-exist. A persona
exists to achieve his goals, a goal exists to
give meaning to a persona.
Define the goals of each persona.
2. Scenarios
Scenarios
 A precise description of a persona using an
interface to achieve a goal

 What will users want to do?

 Step-by-step walkthrough
 what can they see (sketches, screen shots)
 what do they do (keyboard, mouse etc.)
 what are they thinking?

 Use and reuse throughout design

Creating Scenarios
Scenarios normally include descriptions about:
The individual user (i.e., the persona)
The task or situation
The user’s desired outcome/goal for that task
Procedure and task flow information
A time interval
Envisioned features/functionality the user will
need/use.

You may also want to include exceptions. What

are some of the rare events that happen?
 Creating Scenarios
Using the list of tasks in the user profile and/or persona, choose the
critical tasks and begin creating scenarios with your stakeholders.

In one scenario, describe the ideal way the persona might complete
a given task.

In another scenario, describe a problem (or problems) the persona

might encounter while completing this task and how the persona
would react.

Continue building a set of scenarios for each of your personas until

you feel you have covered the functionality of your product and the
tasks/situations users encounter.

Use the information from user requirements activities to validate

your scenarios and add more information to them
 An Example Scenario
Sally needs to plan a vacation for her family. She decides to
hop on TravelSmart.com and do both the research and
reservations there. She begins by researching the top family-
friendly destinations as recommended by TravelSmart.com
customers. She wants to compare the travel time, travel
costs, hotel costs, hotel availability, and amusement activities
for each destination. For each of those criteria, Sally gave a
weighting to help her make her decision. She finally settled
on the destination that required the least travel time,
cheapest travel costs, moderate hotel costs, good availability,
and a large selection of activities for the whole family. From
that spot, Sally begins searching for the flights and hotels
that meet her criteria. She decides to save those results for
later because she wants to be sure the whole family is in
agreement before she makes the reservations with her credit
card.
Creating Scenarios
The topic of your scenario is your
foundation to build upon.
The topic should not be so broad that it
results in a 32-page scenario.
Similarly, it should not be so focused that it
represents only a small percentage of users
or tasks.
It will likely take several iterations before
you get it right.
Explore the Depths
explore interaction
what happens when

explore cognition
what are the users thinking

explore architecture
what is happening inside
Book Reference
Book: THuman Computer Interaction - 3rd
Edition by - ALAN DIX_ JANET FINLAY
Chapter: 5, 15

Book: Understanding Your Users, A

Practical Guide to User Requirements
Methods, Tools, and Techniques (2004)_2
Chapter: 1, 2