1

Understanding and Documenting the Context and

Problem

laura leventhal and julie barnes

2

Sources

Chapters 5 and 6, Protobook

3

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

4

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!

5

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.

6

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.

7

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.

8

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

9

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

10

Task Analysis Example

Think about baking a cake. Can you break down the jobs into a hierarchical structure

11

A Partial SolutionBake Cake

Prepare Mix Ingredients Cook

Prepare Kitchen Gather Ingredients

Preheat Oven Grease Pans Find Recipe

Sift Dry Stir Wet Add Dry to Wet

12

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

13

Pay Bills

Find BillsIn Drawer

Categorize Bills for Taxes

SubmitPayment

UploadElectronicPayment

Pay by Mail

WritePaperCheck

Address andStamp Envelope

MailPayment

Update Balance

Decide Which Bills to Pay

Prepare to Pay Bills

14

Task Analysis “Don’t Forgets”

Do:• Use verbs to describe user actions• Have details

15

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

16

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

17

Task Analysis Challenges - 2

• squeezing data out of shape• do not account for wider interaction

context• handling group tasks• verifying an analysis

18

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.

19

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.

20

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?

21

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

22

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.

23

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

24

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"

25

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 real-world interactions.

Producing an effective set of tasks will be a real test of the designer's understanding of the users and their work.

26

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.

27

How to synthesize...

The trick is to identify what is common across scenarios.

We will look at a simple strategy to accomplish this.

28

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 into subtasks.

29

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.

30

Example, continued

Use case models show interactions between external actors or roles (represented by stick people) and the use case (enclosed in the oval)

31

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.

32

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 theequipment that she needs. For example, she collectsa shovel, mulch, watering bucket (filled) and seeds.

• AJ gets seeds. He spreads seeds onto the flower bed.

33

Example, continued

Corresponding use case models for each scenario Collect

Equipment

DigElsa

Collect Seeds

Spread Seeds AJ

34

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

Spread seedsFlower Planter

35

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.

36

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.

37

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.

38

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.

39

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

40

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.

41

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.

42

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!

43

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

44

Nielsen Exercise

Purpose: learn about iteration Steps

• Read introduction (p.32-36)• Case Studies - one per group

– Home banking– Cash register– Security hypertext

45

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

46