Transcript How users reciprocate to computers:

Understanding and
Documenting the Context and
Problem
laura leventhal and julie barnes
1
Sources

Chapters 5 and 6, Protobook
2
Understanding and Documenting
Activities

Goals
• Analysis
– Understanding the context and the details of
the problem (ie. the UI) from the user’s
perspective.
• Specification
– Produce detailed documents that spell out as
specifically as possible what the UI for the
product will be like
3
Quality!

A quality specification is
• Complete
– Leaves no details out. Does not make developers
later guess what was meant.
• Correct
– Defines the right problem and context
• Unambiguous
– Means the same thing to all of the stakeholders.

A quality specification can only result
from good analysis!
4
Two Primary Types of
Activities



Context Setting
• Needs analysis and specification
• Feasibility studies
• Project Planning and Resource Scheduling
Analyzing and Specifying Problem
• Use Case Analysis and user profile specifications
• Task Analysis and specification
• Analysis and documentation of usability requirements (e.g.
identification and definition of what it means for your UI to be
“easy to learn”)
For our class purposes only, we will start with defining the
problem.
5
Hierarchical Task Analysis

A process of developing a description of tasks in
terms of operations – things which people do to attain
goals – and plans – statements of condition when
each of a set of operations has to be carried out to
attain an operating goal. The analyst begins by
stating a goal that a person has to achieve. This is
then converted into a set of sub-operations and
plan(s) governing when they are carried out.

Reference.
Kirwan, B. and Ainsworth, L.K. (Eds.). (1992). A Guide to Task
Analysis . London: Taylor & Francis Inc.
6
Task Analysis




Task analysis drives design. The tasks identified in
the analysis are the tasks to be supported in the
design.
HTA defines (extracts )a hierarchical set of tasks that
define how the users will use the system.
• Tasks also documented in text
Focus is generally on the activities that the user will
perform with the task
More generally, task analysis may focus on user
goals, tasks and/or methods to achieve goals.
7
Task Analysis and
Specification

Goal of our Task Analysis and Specification
• To understand the tasks that users will do with the
system (UI) well enough to produce a hierarchical
breakdown of these tasks . This description will
have enough information about those tasks that is
detailed enough to drive design.

Assumptions.
• Specification will be a stand - alone document.
• One or two levels of detail is not enough in the
hierarchical breakdown
• Each task entry in the breakdown also has a text
description
8
Task Analysis and
Specification

Structure of Task Specification Document
• Since the structure is hierarchical, can use
structure or organizational charts. Many drawing
tools support this type of work.
• Typically each “box” in hierarchy corresponds to a
task that user will perform with the interface.
• In project, details of format of text descriptions of
each task
9
Task Analysis Example

Think about baking a cake. Can you
break down the jobs into a hierarchical
structure
10
A Partial Solution
Bake Cake
Mix Ingredients
Prepare
Prepare Kitchen
Preheat Oven
Gather Ingredients
Grease Pans
Sift Dry
Stir Wet
Cook
Add Dry to Wet
Find Recipe
11
Task Analysis Example 2

Task is “paying bills”

• What are the
important steps?
• These steps
represent the tasks
from the user’s
perspective?


Find bills in bill drawer
Categorize payments for
taxes later (e.g.. Donations)
Pay bills
• Electronic submission
• By paper check



Verify $ in account
Record payments
Decide which bills to pay
12
Pay Bills
Prepare to
Pay Bills
Find Bills
In Drawer
Decide Which
Bills to Pay
Submit
Payment
Categorize
Bills for Taxes
Upload
Electronic
Payment
Write
Paper
Check
Update Balance
Pay by
Mail
Address and
Stamp Envelope
Mail
Payment
13
Task Analysis “Don’t Forgets”

Do:
• Use verbs to describe user actions
• Have details
14
Task Analysis “Don’t Forgets”

Don’t:
• Reproduce a hierarchical menu design
File
Open
Save
Save As
Manage your file
Make contents available
Preserve changes
Make a copy of file
15
Task Analysis Challenges - 1



knowing when to stop the analysis activity:
grain size
deciding what constitutes a task can be
problematic
many task analysis methods look at “ideal”,
expert performance
• therefore can’t deal with errors (but evidence
suggests that ‘errors’ constitute a large amount of
activity
16
Task Analysis Challenges - 2
•
•
•
•
squeezing data out of shape
do not account for wider interaction context
handling group tasks
verifying an analysis
17
Task Analysis Errors

Typical Errors to Avoid:
• Inconsistencies between the items in the chart and your written
descriptions.
• Tasks which appear in only the chart or written description.
• Spelling errors
• Grammatical errors. Your description of the task should be from
the perspective of the user, not yourself.
• Not enough detail!
• For most of you this phase will be the most conceptually difficult.
Give yourself lots of time to complete this phase.
18
Tasks vs. Implementation

Avoid the trap of "multiple inheritance."
– user wants to be able to cut and paste
information while viewing a recipe and while
viewing a shopping list.
– While both of these tasks are cut and paste,
they are potentially different because the
context is different.
– it is imperative to show that these two flavors of
cut and paste are different and thus preserve
the context information that your user provided.
19
Format for text description

A written description of its function. Discuss the following issues:
•
•
•
•
•
What is the goal of this task?
What sub-tasks define this task?
Is this task a subunit of a larger task?
What non-interface functions does this task require?
What kinds of inputs or actions does this task require from the
user?
• What kind of outputs or results occur by virtue of performing this
task?
• What automatic actions does this task expect from the system?
• What special characteristics of this task should we record?
20
Format for text description

Additional issues:
• Sequencing:
– In this subtree, is there a task that must be before this one?
– In this subtree, is there a task that must come after this one?
•
•
•
•
•
•
Which primary classes are involved in this subclass?
How can this task fail or end in non-completion?
How frequently is this task performed?
How open is this task in terms of sequence or inputs?
What usability expectations are there?
See Chapter 5, pp. 105-108
21
Identifying User Tasks?

How do I determine user tasks for the
hierarchical breakdown?
• Possibility One -> User tells gives me a list of the
tasks
• Possibility Two -> User describes specific tasks or
scenarios that illustrate how they will use the
target system. Note user says “how” they will use
system, not what it will do.
• Possibility Three -> User describes the data and
its structure that is used in the target system.
22
What if you have scenarios?

How to get information from users that
describe scenarios, task lists...
• Take similar software and derive tasks
• User describes a situation (scenario_
• Ask user, but if user can’t tell you
– Observe user in naturalistic setting
23
Examples

Here are a few examples:
• for a word processor: "transcribe a memo
and send it to a mailing list"
• for a spreadsheet: "produce a salary
budget for next year"
• for a communications program: "login to
the office via modem"
• for an industrial control system: "hand over
control to next shift"
24
If my task analysis is derived from
scenarios….Some rules of thumb




There should also be a mixture of simple and more
complex tasks.
Simple tasks, such as "check the spelling of
'occasional'," will be useful for task analysis
Many interface problems will only be revealed
through complex tasks that represent extended realworld interactions.
Producing an effective set of tasks will be a real test
of the designer's understanding of the users and their
work.
25
Why is it hard to build a task
analysis from scenarios?
Scenarios are specific.
 The tasks in a task analysis are
abstract.
 The developer must synthesize
potentially several specific scenarios
into abstract tasks.

26
How to synthesize...
The trick is to identify what is common
across scenarios.
 We will look at a simple strategy to
accomplish this.

27
Example: Scenario --> Task

Here is a narrative description of a simple user task.
 A CS major at Bowling Green State University is going to plant
flowers outside of Hayes Hall.

Here are some sample scenarios of the tasks that someone will do as part of
this task.
 Elsa is going to plant some flowers. To get started she digs up the
flower bed in front of Hayes Hall and collects the equipment that she
needs. For example, she collects a shovel, mulch, watering bucket
(filled).
 AJ gets seeds. He spreads seeds onto the prepared flower bed.
 Julio waters the flower bed.

At a high level, the user task in this case is “plant flowers.” However, this
level of detail for a task description usually is inadequate, so we break the task
28
into subtasks.
Example, continued



We are going to borrow a concept from the Unified
Software Development Process called “use case
models”
Use case models are a software analysis and
specification technique.
Their purpose is to show the ways that a piece of
software can interact with the outside world.
29
Example, continued

Use case models show interactions between external
actors or roles (represented by stick people) and the
use case (enclosed in the oval)
30
Example, continued




Develop a high-level use case model for each
scenario showing the tasks that the user performs as
indicated by the scenario. In other words, abstract the
scenarios, one scenario at a time.
Combine/rebuild the original, scenario-by-scenario
use case models into a single, more abstract model.
The actors are aggregates of the roles played by
specific users.
The use cases suggest high level tasks for the
hierarchical task analysis.
31
Example, continued

Reconsider our scenarios about
planting flowers.
• Elsa is going to plant some flowers. To get started
she digs up the flower bed outside and collects the
equipment that she needs. For example, she
collects
a shovel, mulch, watering bucket (filled) and
seeds.
• AJ gets seeds. He spreads seeds onto the flower
bed.
32
Example, continued

Corresponding use case models for
each scenario
Collect
Equipment
Elsa
Dig
Collect Seeds
Spread Seeds
AJ
33
Example, continued




Can we consolidate and abstract from these two use cases?
Yes. We can form an aggregated actor, Flower Planter. Note that the only attribute of this
actor that we know is the students’ names, because they were referred to by name in the
scenario.
How about the use cases - can we consolidate them? Yes again. Note that both AJ and Elsa
are collecting equipment and supplies when they collect shovels, buckets and seeds.
Collecting equipment and digging are all part of preparing for planting.
Note that the actor’s role, relative to these interactions is “Flower Planter”. The use cases
are abstractions of the actions from the specific scenarios.
Prepare
Flower Planter
Spread seeds
34
User Analysis and Generation of User Profiles


To get a good interface you have to figure out
who is going to use it to do what.
Characteristics of users can be used as the basis
of design decisions.
• For example, we may select a different interaction style for
novices as compared to experts

What information to gather
• Measurements and definitions of Eason (1984) variables of user
knowledge, user motivation and user discretion.
• Other user variables including learning and problem solving styles,
attitudes toward automation, special needs and so on.
• User feedback about their job and how this system would impact
them
• Other organizational and workflow considerations.
35
Identifying Usability
Requirements





This is a problem definition activity and is particularly
important if your customer has some global usability
concerns.
For example, if your customer wants the user interface to
be “easy to use”.
You should understand (analyze) what exactly that means
to the customer and what the protocol will be to measure
“easy to use.
Then you need to document this (specification)
The more detailed this information, the easier it will be for
you to do usability assessment later, because you will be
able to construct your assessment to test these previously
established goals.
36
Where to start in User
Analysis?








You may start by conducting interviews or asking questions of target users.
These interviews may be structured if you already know what you are looking for
or unstructured if you are exploring.
6 categories of questions come to mind when thinking of “communication”:
• who, what, when, where, why, how
Your demeanor is important - try not to be too chauvinistic
You may ask about knowledge of computers and programming languages,
skills, background, age, culture
You might get a reaction to device
• would this simplify your life?
Responses different than what you would have answered are to be expected
You may also try paired interviews to reduce the anxiety of the interviewee and
establish a more natural conversational setting.
Focus groups can also provide good information, although one or two people
may dominate the conversation.
37
Structure of User Profile
(specification)
• Some Information to Document
– User Characteristics
• defining characteristics of users; how will they use this
system?
– User Skills
• computer skills, skills in the problem domain
– How did you get your information
• Who did you interview, how were they chosen, goals or
approaches did you take
– Conclusions
• What did you learn that should be taken into consideration
or given special consideration in design.
38
Back to Context Setting Needs Analysis
Document to establish that a new
system is needed..
 Assume this is a stand - alone
document.
 Gives the user the total feature list of
the product

39
Structure of Needs Analysis
Document

Goal
• short statement of the expected use of the system

Assumptions/Constraints
• How is the use of the system constrained by
reality.

Features
• What are the specific things that a user could do
with this system.
40
Other Context Setting
Activities

Feasibility Study – In the environment for the project can
you complete the project? Can the customer afford your
services?

Planning and scheduling of resources. There are a number
of strategies from Software Engineering that can be used.
• A common strategy is to identify the longest time path
through the activities (called a Critical Path).
• Activities are scheduled around the Critical path, with
special attention on things that can happen in parallel.
41
What is the Process? What
are the steps?




Sell your idea and determine if it is feasible
• Customer agrees to specification of Needs Analysis.
• Perform a feasibility study to determine if the project is feasible (for
you and customer)
Plan and schedule the project and its resources
• Customer signs off on your schedule, costs and resource
requirements.
Understand and Specify the Problem
• Analyze and specify user task requirements
• Analyze user characteristics and generate user profiles
• Analyze and specify usability requirements
• Customer signs off on these specification documents
Note you may meet with the customer many times during this process.
Ultimately your goal is to establish a contract with the customer that very
precisely defines what and when you will deliver and how much the
customer will pay you for your services!
42
Where Do I Begin?: Ensuring Usability in Your Development Environment. From
Hix and Hartson (1993)























1. Start small: small project, low risk, expect rough spots, warn mgmt.
2. Produce only a few usability spec the first time you try them
e.g., try two objective measures and one subjective
document your results and show to mgmt.
3. Prototype and evaluate only a core set of functions the first few times you try formative evaluation.
i.e., don't get hung up in prototype development (Note: See tiny fingers article for an alternative.)
4. Find someone with whom you can apprentice
5. Begin building a UI development team of appropriately skilled people.
at the minimum, one half-time person
6. Get a commitment from the development team to try the new ideas
7. Get training for development team members
8. Set up a usability lab
9. Do some kind of observations of users with a prototype of the UI design - this is the minimum if all else fails
10. Have developers and mgmt. watch at least one participant from an evaluation session.
- they must promise to remain *quiet*, no matter how painful
11. Get consulting help when needed, especially during start-up.
"If you think experts are expensive, wait until you bring in the amateurs." Red Adair (oil-well firefighter)
12. Generate a success story, no matter how small.
13. Start a UI brown-bag lunch group
14. Start a small internal newsletter and/or electronic bulletin board on HCI
15. Encourage attendance at HCI conferences
16. Get management commitment
17. Focus on the process, not just the product
43
Nielsen Exercise
Purpose: learn about iteration
 Steps

• Read introduction (p.32-36)
• Case Studies - one per group
– Home banking
– Cash register
– Security hypertext
44
Nielsen Continued
Describe system
 How was iteration used to improve UI?
 How do you know that iteration helped?
 Each group gives five minute
presentation of their report

45
46