04-Task Analysis

1
 Topics
• User analysis
• Task analysis
• Domain analysis
• Requirements analysis

6.813/6.831 User Spring

Interface Design and 2011 2
Implementation
01-User Analysis
 Know Your User
• Identify characteristics of target user
population
– Age, gender, culture, language
– Education (literacy? numeracy?)
– Physical limitations
– Computer experience (typing?)
– Motivation, attitude
– Domain experience
– Application experience
– Work environment and other social context
6.813/6.831 User
– Relationships and communication
Interface Design
Implementation
and
Spring
2011 patterns 4
 Multiple Classes of Users
• Many applications have several kinds of users
– By role (student, teacher)
– By characteristics (age, motivation)
• Example: Olympic Message System
– Athletes
– Friends & family
– Telephone operators
– Sysadmins

6.813/6.831 User Spring

Interface Design and 2011 5
Implementation
 Personas
• A persona is a fictitious character used as a specific
representative of a user class
– Yoshi is a 20-year-old pole vaulter from Tokyo who speaks some
English
– Bob is an IBM sysadmin in New York
– Fritz is the 50-year-old father of a German swimmer
• Advantages
– Convenient handle for talking about user classes
– Focuses on a typical user, rather than an extreme
– Encourages empathy
• Disadvantages
– May be misleading
– Stereotype trap
6.813/6.831 User Spring
Interface Design and 2011 6
Implementation
 How To Do User Analysis
• Techniques
– Questionnaires
– Interviews
– Observation
• Obstacles
– Developers and users are sometimes
systematically isolated from each other
• Tech support shields developers from users
• Marketing shields users from developers
– Some users are expensive to talk to
6.813/6.831 User
• Doctors, executives, union
Spring
Interface Design and 2011members 7
Implementation
02-Task Analysis
 Task Analysis
• Identify the individual tasks the program
might solve
• Each task is a goal (what, not how)
• Often helps to start with overall goal of the
system and then decompose it hierarchically
into tasks

6.813/6.831 User Spring

Interface Design and 2011 9
Implementation
 Essential Parts of Task Analysis
• What needs to be done?
– Goal
• What must be done first to make it possible?
– Preconditions
• Tasks on which this task depends
• Information that must be known to the user
• What steps are involved in doing the task?
– Subtasks
– Subtasks may be decomposed recursively
6.813/6.831 User Spring
Interface Design and 2011 10
Implementation
 Example from OMS
• Goal
– Send message to another athlete
• Preconditions
– Must know: my country code, my username, my
password, the other athlete’s name
• Subtasks
– Log in (identify yourself)
– Identify recipient
– Record message
6.813/6.831 User Spring
– Hang up
Interface Design and
Implementation
2011 11
 Other Questions to Ask About a
Task
• Where is the task performed?
– At a kiosk, standing up
• What is the environment like? Noisy, dirty, dangerous?
– Outside
• How often is the task performed?
– Perhaps a couple times a day
• What are its time or resource constraints?
– A minute or two (might be pressed for time!)
• How is the task learned?
– By trying it
– By watching others
– Classroom training? (probably not)
• What can go wrong? (Exceptions, errors, emergencies)
– Enter wrong country code
– Enter wrong user name
– Get distracted while recording message
• Who else is involved in the task?

6.813/6.831 User Spring

Interface Design and 2011 12
Implementation
 How to Do a Task Analysis
• Interviews with users
• Direct observation of users performing tasks

6.813/6.831 User Spring

Interface Design and 2011 13
Implementation
 Example: Elevator Task Analysis
• Suppose we’re designing the Student Center
elevator interface
• What are the tasks?

6.813/6.831 User Spring

Interface Design and 2011 14
Implementation
03-Domain Analysis
 Domain Analysis
• Identify important things in the domain
– People (user classes)
• Athletes, friends & family, sysadmins
– Physical objects
• Namecard, telephone Account
– Information objects
• Messages, accounts
Athlete Sysadmin Namecard Message

6.813/6.831 User Spring

Interface Design and 2011 16
Implementation
 Domain Analysis
• Determine important relations between the things
– Athletes have accounts
– Accounts have messages
– Family & friends know athletes
– Sysadmins register athletes or create accounts
Sysadmin
create

Athlete account Account messages Message

6.813/6.831 User Spring

Interface Design and 2011 17
Implementation
 Domain Analysis
• Identify multiplicities of things and relations
– Numbers are best, but simple multiplicity
indicators (!,?,+,*) help too

Sysadmin
100
create

Athlete account Account messages Message

10,000
! 10 [0-100]

6.813/6.831 User Spring

Interface Design and 2011 18
Implementation
 Feedback to User & Task Analysis
• People entities who really should be user
classes
• Missing tasks
– CRUD: Create, Read, Update, Delete

6.813/6.831 User Spring

Interface Design and 2011 19
Implementation
 Example: Twitter Domain Analysis
• Suppose we’re reimplementing Twitter.
• What are its entities, relationships, and
multiplicities?

6.813/6.831 User Spring

Interface Design and 2011 20
Implementation
04-Requirement Analysis
 Requirements Analysis
• Requirements: what should the system do?

Users

Requirements
Tasks

Domain

6.813/6.831 User Spring

Interface Design and 2011 22
Implementation
 Requirements:
what, how and why?

What: Two aims

• Understand as much as possible about users, task, context

• Produce a stable set of requirements

How:

• Data gathering activities

• Data analysis activities
• Expression as ‘requirements’
• All of this is iterative

23
 Requirements:
what, how and why?

Why

•Requirement's definition: the

stage where failure occurs most
commonly
•Getting requirements right is
crucial
24
 Volere Requirements Template
• Volere Requirements Specification is a
Template used as a basis for discovering and
communicating requirements of software
systems.
• Requirements as belonging to a type

25
Volere Requirements Template

26
 Establishing requirements
What do users want? • Requirements need clarification, refinement,
What do users need? completion, re-scoping

Input • Requirement's document (maybe)

Output • Stable requirements

• Requirements arise from understanding users’ needs

Why establish? • Requirements can be justified & related to data

27
 Different kinds of requirements
• Functional:
– What the system should
do
– Historically the focus of
requirements activities
– A functional
requirement for a word
processor may be that it
should support a variety
of formatting styles

28
 Different kinds of requirements
• Non-Functional:
– Portability, response
time, etc.
– A non-functional
requirement for a
word processor
might be that it must
be able to run on a
variety of platforms
such as PCs, Macs
and Unix machines
29
 Different kinds of requirements
• Data:
– Data requirements
capture the type,
volatility, size,
amount, persistence,
accuracy, and value
of the amounts of
the required data
– How will they be
stored (e.g.,
database)?
30
Environment or context of use

Physical
• dusty, noisy, vibration, light, heat,
humidity, …. (e.g., ATM)

Social
• sharing of files, view of files
synchronously across great distances,
work individually, privacy for clients

Organizational
• hierarchy, IT department’s attitude,
user support, communications
structure and infrastructure,
availability of training

31
 Users: Who are they?

Characteristics

• ability, background, attitude to computers

System use: novice, expert, casual, frequent

• Novice: step-by-step (prompted), constrained, clear

information
• Expert: flexibility, access/power
• Frequent: short cuts
• Casual/infrequent: clear instructions, e.g., menu paths

32
 What are the users’ capabilities?
Size
• of hands may affect the size and positioning of input buttons

motor abilities
• may affect the suitability of certain input and output devices

Height
• if designing a physical kiosk

Strength
• a child’s toy requires little strength to operate, but greater strength to change batteries

Disabilities
• (e.g., sight, hearing)

33
 Requirements Vary
• What factors (environmental, user, usability)
would affect the following systems?
– Self-service filling and payment system for a petrol
(gas) station
– On-board ship data analysis system for geologists
searching for oil
– Fashion clothes website

34
 Personas

A personal facade
Capture user
that one presents to
characteristics
the world

Not real people, but

Should not be
synthesized from real
idealized
user characteristics

Bring them to life

with a name,
characteristics, goals,
personal background

35
Personas

36
 Data gathering for requirements
• Interviews
– Props, e.g., sample
scenarios of use,
prototypes, can be
used in interviews
– Good for exploring
issues
– But are time
consuming and may be
infeasible to visit
everyone

37
 Data gathering for requirements
• Focus groups interviews
– Group interviews
– Good at gaining a
consensus view
and/or highlighting
areas of conflict
– But can be
dominated by
individuals

38
Data gathering for requirements

Questionnaires

• Often used in conjunction with other techniques

• Can give quantitative or qualitative data
• Good for answering specific questions from a
large, dispersed group of people

Researching similar products

• Good for prompting requirements

39
 Data gathering for requirements
• Direct observation
– Gain insights into
stakeholders’ tasks
– Good for understanding
the nature and context
of the tasks
– But it requires time and
commitment from a
member of the design
team, and it can
result in a huge amount
of data

40
 Data gathering for requirements
• Indirect observation
– It largely involves analyzing
textual material generated
indirectly, e.g.,
• Diaries
• Interaction logging (key
presses, mouse /
device movements)
– Not often used in
requirements activity
– Good for logging current
tasks

41
 Data gathering for requirements
• Studying documentation
– Procedures and rules are often written down in
manuals
– Good source of data about the steps involved in
an activity, and any regulations governing a task
– Not to be used in isolation
– Good for understanding legislation, and getting
background information
– No stakeholder time, which is a limiting factor on
the other techniques

42
 Data gathering for requirements
• Contextual Inquiry
– An approach to ethnographic study (scientific
description of individual human societies) where
user is expert, designer is apprentice
– A form of interview, but
• at users’ workplace (workstation)
• 2 to 3 hours long
– Four main principles:
• Context: see workplace & what happens
• Partnership: user and developer collaborate
• Interpretation: observations interpreted by user and
developer together
• Focus: project focus to understand what to look for
43
 Problems with data gathering

Identifying • users, managers, developers, customer

stakeholders: reps?, union reps?, shareholders?

Involving • workshops, interviews, workplace

studies, co-opt stakeholders onto the
stakeholders: development team

‘Real’ users, • traditionally a problem in software

not managers engineering, but better now

44
 Problems with data gathering
Requirements management:

• version control, ownership

Communication between parties:

• within development team

• with customer/user
• between users… different parts of an organization use different terminology

Domain knowledge distributed and implicit:

• difficult to dig up and understand

• knowledge articulation (extraction of knowledge from individuals )
• Availability of key people

45
Problems with data gathering
Political problems
within the organization
Dominance of certain
stakeholders
Economic and business
environment changes
Balancing functional
and usability demands
46
Some basic guidelines
Focus on Focus on identifying the stakeholders’ needs

Involve Involve all the stakeholder groups

Involve more than one representative from

Involve each stakeholder group

Use a combination of data gathering

Use techniques

47
 Some basic guidelines
Support the process with props such as prototypes and task descriptions

Run a pilot session

You will need to compromise on the data you collect and the analysis to be
done, but before you can make sensible compromises, you need to know what
you’d really like

Consider carefully how to record the data

48
Data interpretation and analysis
This phase starts soon after data
gathering phase

Initial interpretation before deeper

analysis

Different approaches emphasize

different elements e.g., class
diagrams for object-oriented
systems, entity-relationship
diagrams for data intensive systems

49
 Task descriptions

Scenarios Use cases Essential use cases

an informal narrative story, assume interaction with a abstract away from the
simple, ‘natural’, personal, system details
not generalizable assume detailed does not have the same
understanding of the assumptions as use cases
interaction

50
 Scenario: university admissions
office
• You walk in, and are greeted the supervisor,
who starts by saying something like:
– “Well, this is where the admissions forms arrive.
We receive about 50 a day during the peak
application period. Brian here opens the forms and
checks that they are complete, that is, that all the
documentation has been included. You see, we
require copies of relevant school exam results or
evidence of work experience before we can
process the application. Depending on the result
of this initial inspection, the forms get passed to…”

51
Use Case Diagram

52
Use Case Diagram

53
 Task analysis
Task descriptions are often used to envision new systems or
devices

Task analysis is used mainly to investigate an existing

situation

What are people trying to achieve?

It is important not to focus on Why are they trying to achieve it?
superficial activities How are they going about it?

Many techniques, the most popular is Hierarchical Task

Analysis (HTA)

54
 Hierarchical Task Analysis
Involves breaking a task down
HTA focuses on physical and
into subtasks, then sub-sub-
observable actions, and
tasks and so on. These are
includes looking at actions not
grouped as plans which
related to software or an
specify how the tasks might
interaction device
be performed in practice

Start with a user goal which is

Tasks are sub-divided into sub-
examined and the main tasks
tasks
for achieving it are identified

55
 Hierarchical Task Analysis
0. In order to buy a DVD

1. locate DVD

2. add DVD to shopping basket

3. enter payment details

4. complete address

5. confirm order

plan 0:

• If regular user do 1-2-5.

• If new user do 1-2-3-4-5.

56
Hierarchical Task Analysis

57
 Best Practices For Writing User
Requirements
Understand the User Perspective:
1.Gain a deep understanding of the target
user group, their characteristics,
preferences, and goals.
2.Identify the user personas and their specific
needs, roles, and responsibilities within the
system.

58
 Best Practices For Writing User
Requirements

Involve Users and Stakeholders:

1.Collaborate closely with users and relevant
stakeholders throughout the requirement-
gathering process.
2.Conduct user interviews, surveys, or
usability tests to gather insights and
validate requirements.

59
 Best Practices For Writing User
Requirements
Use User-Centric Language:
1.Express user requirements in user-centric
language, using terms and concepts familiar
to the intended users.
2.Avoid technical jargon or complex
terminology that may confuse or alienate
the users.

60
 Best Practices For Writing User
Requirements
Focus on User Goals and Tasks:
1.Identify the goals and tasks users need to
accomplish using the software system.
2.Frame requirements around the specific
actions or functionalities that support user
goals and tasks.

61
 Best Practices For Writing User
Requirements
Be Specific and Concrete:
1.Clearly define the desired behavior or
outcomes from the user’s perspective.
2.Use concrete examples, scenarios, or
stories to illustrate the desired interactions
or workflows.

62
 Best Practices For Writing User
Requirements
Consider User Experience (UX) Design:
1.Address the user experience aspects such
as ease of use, intuitiveness, and efficiency
in completing tasks.
2.Specify requirements related to navigation,
layout, interaction design, and visual
aesthetics.

63
 Best Practices For Writing User
Requirements
Include Performance Expectations:
1.Define user requirements related to system
responsiveness, speed, and efficiency.
2.Specify performance targets or thresholds
that contribute to a satisfactory user
experience.

64
 Best Practices For Writing User
Requirements
Prioritize User Needs:
1.Assign priorities to user requirements to
ensure the most critical needs are
addressed first.
2.Prioritization helps in resource allocation,
decision-making, and trade-off analysis.

65
 Best Practices For Writing User
Requirements
Validate with User Feedback:
1.Regularly validate user requirements with
user representatives or usability experts.
2.Seek feedback on prototypes, mock-ups, or
design iterations to ensure that
requirements align with user expectations.

66
 Best Practices For Writing User
Requirements
Consider Accessibility and Inclusivity:
1.Incorporate requirements to address
accessibility and inclusivity considerations.
2.Ensure the software system accommodates
diverse user needs, including those with
disabilities or different cultural
backgrounds.

67
 Best Practices For Writing User
Requirements
Review and Iterate:
1.Conduct regular reviews and iterations of
user requirements with stakeholders and
the development team.
2.Ensure that the requirements are complete,
accurate, and align with the overall project
goals.

68
 Managing User Requirements throughout
the UI Development Lifecycle
Requirements Elicitation
• To gather user requirements effectively, employ various
techniques during the requirements elicitation phase.
Consider these practices:
• Conduct interviews with users, stakeholders, and subject
matter experts to understand their needs, preferences, and
expectations.
• Utilize surveys or questionnaires to collect feedback from a
broader user population, allowing for a comprehensive
understanding of their requirements.
• Conduct observations or user shadowing sessions to gain
insights into how users interact with existing systems or
69
perform their tasks.
 Managing User Requirements throughout
the UI Development Lifecycle
• Analysis and Refinement
• Once user requirements are gathered, analyzing and
refining them is essential to ensure clarity,
completeness, and consistency. Consider these
practices:
• Organize and categorize user requirements based on
their similarities or related functionalities to identify
patterns or commonalities.
• Remove any duplicate or conflicting requirements to
eliminate ambiguity and ensure consistency.
• Collaborate with users and stakeholders to validate
and refine the requirements, ensuring they accurately
capture the desired functionality and user experience.70
 Managing User Requirements throughout
the UI Development Lifecycle
• Traceability and Impact Analysis
• Establishing traceability between user requirements and
other project artifacts is crucial for impact analysis and
change management. Consider these practices:
• Use unique identifiers or tags to link user requirements to
design decisions, test cases, and other project artifacts.
• Maintain a traceability matrix that shows the relationships
between user requirements and other project elements,
enabling impact analysis during changes.
• Assess the impact of proposed changes on user
requirements to understand the potential consequences
and make informed decisions.
71
 Managing User Requirements throughout
the UI Development Lifecycle
• User-Centric Design and Prototyping
• Incorporating user requirements into the design and
prototyping stages of the software development process
helps validate and refine the user experience. Consider
these practices:
• Create design mock-ups, wireframes, or interactive
prototypes that reflect the user requirements, allowing
users to provide feedback and validate the proposed
solutions.
• Conduct usability testing sessions with users to gather
insights and identify any usability issues or areas for
improvement.
• Iteratively refine the design and prototype based on user
feedback, ensuring that the final product meets user 72
expectations and needs.
 Managing User Requirements throughout
the UI Development Lifecycle
• User Acceptance Testing
• Involving users in the acceptance testing phase ensures
that the developed software meets their requirements and
expectations. Consider these practices:
• Develop user acceptance testing scenarios that align with
the documented user requirements.
• Collaborate with users to perform acceptance testing,
allowing them to validate whether the software meets their
needs and performs as expected.
• Address any identified issues or discrepancies between the
software and user requirements, ensuring necessary
adjustments are made before deployment.

73
 Common Errors in User Analysis
• Describing what your ideal users should be, rather than what they actually
are
– “Users should be literate in English, fluent in spoken Swahili, right-handed,
and color-blind”

6.813/6.831 User Spring

Interface Design and 2011 74
Implementation
 Common Errors in Task Analysis
• Thinking from the system’s point of view, rather than the user’s
– “Notify user about appointment”
– vs. “Get a notification about appointment”
• Fixating too early on a UI design vision
– “The system bell will ring to notify the user about an appointment…”
• Bogging down in what users do now (concrete tasks), rather than why
they do it (essential tasks)
– “Save file to disk”
– vs. “Make sure my work is kept”
• Duplicating a bad existing procedure in software
• Failing to capture good aspects of existing procedure

6.813/6.831 User Spring

Interface Design and 2011 75
Implementation
 Hints for Better User & Task
Analysis
• Questions to ask
– Why do you do this? (goal)
– How do you do it? (subtasks)
• Look for weaknesses in current situation
– Goal failures, wasted time, user irritation
• Contextual inquiry
• Participatory design

6.813/6.831 User Spring

Interface Design and 2011 76
Implementation
 Contextual Inquiry
• Observe users doing real work in the real work
environment
• Be concrete
• Establish a master-apprentice relationship
– User shows how and talks about it
– Interviewer watches and asks questions
• Challenge assumptions and probe surprises

6.813/6.831 User Spring

Interface Design and 2011 77
Implementation
 Participatory Design
• Include representative users directly in the
design team
• OMS design team included an Olympic athlete
as a consultant

6.813/6.831 User Spring

Interface Design and 2011 78
Implementation
DATA ANALYSIS

79
Qualitative vs Quantitative Data
Qualitative Data Quantitative Data
Overview: Overview:
•Deals with descriptions. •Deals with numbers.

•Data can be observed but •Data which can be

not measured. measured.

•Colors, textures, smells, •Length, height, area, volume,

tastes, appearance, beauty, weight, speed, time,
etc. temperature, humidity, sound
levels, cost, members, ages,
•Qualitative → Quality etc.
•Quantitative → Quantity
Example 1: Oil Painting Example 1: Oil Painting

Qualitative data: Quantitative data:

*red/green color, gold frame *picture is 10" by 14”

*smells old and musty •with frame 14" by 18”
*texture shows brush strokes of oil paint * weighs 8.5 pounds
*peaceful scene of the country •surface area of painting is 140 sq.
*masterful brush strokes in.
*cost $300
Example 2: Latte Example 2: Latte

Qualitative data: Quantitative data:

*robust aroma *12 ounces of latte

*frothy appearance *serving temperature 1500 F.
* strong taste *serving cup 7 inches in height
*glass cup *cost $4.95
Example 3: Freshman Class Example 3: Freshman Class

Qualitative data: Quantitative data:

*friendly demeanors *672 students

*civic minded *394 girls, 278 boys
*environmentalists *68% on honor roll
*positive school spirit *150 students accelerated in
mathematics
Make one qualitative observation about the picture above.
Explain why this is a qualitative observation.

Make one quantitative observation about the picture above.

Explain why this is a quantitative observation.
Make one qualitative observation about the picture above.
Explain why this is a qualitative observation.

Make one quantitative observation about the picture above.

Explain why this is a quantitative observation.