Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Task Analysis

No description

Robert Griffin

on 26 October 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Task Analysis

Example Hierarchical Task Analysis (graphical)
Involves breaking a task down into subtasks, then sub-sub-tasks and so on. These are grouped as plans which specify how the tasks might be performed in practice

HTA focuses on physical and observable actions, and includes looking at actions not related to software or an interaction device

Start with a user goal which is examined and the main tasks for achieving it are identified

Tasks are sub-divided into sub-tasks
Hierarchical Task Analysis
Example use case diagram for travel organizer
1. The system displays options for investigating visa and vaccination requirements.
2. The user chooses the option to find out about visa requirements.
3. The system prompts user for the name of the destination country.
4. The user enters the country’s name.
5. The system checks that the country is valid.
6. The system prompts the user for her nationality.
7. The user enters her nationality.
8. The system checks the visa requirements of the entered country for a passport holder of her nationality.
9. The system displays the visa requirements.
10. The system displays the option to print out the visa requirements.
11. The user chooses to print the requirements.
Use case for travel organizer
an informal narrative story, simple, ‘natural’, personal, not generalisable

Use cases
assume interaction with a system
assume detailed understanding of the interaction

Essential use cases
abstract away from the details
does not have the same assumptions as use cases
Task descriptions
Getting requirements right is crucial

There are different kinds of requirement, each is significant for interaction design

The most commonly-used techniques for data gathering are: questionnaires, interviews, focus groups, direct observation, studying documentation and researching similar products

Scenarios, use cases and essential use cases can be used to articulate existing and envisioned work practices.

Task analysis techniques such as HTA and grids help to investigate existing systems and practices
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.
Example Hierarchical Task Analysis

It is important not to focus on superficial activities What are people trying to achieve?
Why are they trying to achieve it? How are they going about it?
Many techniques, the most popular is Hierarchical Task Analysis (HTA)
Task analysis
Start soon after data gathering session

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
Data interpretation and analysis
Task Analysis
Task analysis analyses what a user is required to do in terms of actions and/or cognitive processes to achieve a task.

Task analysis makes it possible to design and allocate tasks appropriately within the new system. The functions to be included within the system and the user interface can then be accurately specified.
Provides knowledge of the tasks that the user wishes to perform. Thus it is a reference against which the value of the system functions and features can be tested.

Task analysis can be a very time consuming activity if used with a high degree of detail on complex problems. ... It is possible to get caught in what is loosely termed ‘analysis paralysis’, where more and more detail is investigated.
Three scenarios for ATM usage
Thomas is 13 and gets pocket money each week. He spends it with his friends, so doesn’t make regular deposits. He does receive gifts for his birthday, Christmas, etc. and saves that money for special purchases, such as a computer games console or clothes. He has an ATM card allowing him to make withdrawals when needed for his purchases.
Sandra is 30, is married to Jason, has two children Todd(6) and Carly (18 months). They live in a subdivision that is about three miles from the town center, where the bank and stores are located.
Jason uses the car for work, and works long hours, leaving at 6:45 am and returning at 8:00 pm. Sandra does not drive, so has to use public transportation.

She tries to run errands and shop while Todd is in school, so she does only has to take Carly to town with her. She typically needs to make two trips to town each week to get everything done. She uses a buggy with Carly, and the bank is one flight up via escalator, so she prefers to use the ATM outside the first floor, even though there is no canopy to protect customers from bad weather.
Marvin is 68 years old, and his social security is deposited into his bank account at the start of each month. He goes to the bank every week, withdrawing enough cash for the week - for miscellaneous expenditure. Regular bills are paid by check. He stands in line for a live teller, as he prefers the social interaction to using an ATM, even though his new artificial hip makes standing in line uncomfortable. He does not have an ATM card.
Task Analysis Grid
Create scenarios for purchasing a gift.

Draw a HTA

Create a User Task Grid

Template is in my folder:
A scenario is a description of a person's interaction with a system. Scenarios help focus design efforts on the user's requirements, which are distinct from technical or business requirements. Scenarios can be understood by people who do not have any technical background. They are therefore suitable for use during participatory design activities.
When are scenarios appropriate?
Scenarios are appropriate whenever you need to describe a system interaction from the user's perspective. They are particularly useful when you need to remove focus from the technology in order to open up design possibilities

How do you write scenarios?
To write a scenario, you need a basic understanding of the tasks to be supported by the system. If you do not have access to such data, you can write scenarios based on prior knowledge or even 'best guess', provided the scenarios will be subject to review by users prior to being used as a basis for making design decisions.

To write a scenario, describe in simple language the interaction that needs to take place. It is important to avoid references to technology, except where the technology represents a design constraint that must be acknowledged. Include references to all relevant aspects of the interaction, even where they are outside the current scope of the technology. Such references may include cultural and attitudinal issues. For example, the fact that Jane is continually interrupted by telephone calls may be just as relevant as the software platform she uses. You should also have the scenario reviewed by users to ensure that it is representative of the real world.

How do you use scenarios?
Use scenarios during design to ensure that all participants understand and agree to the design parameters, and to specify exactly what interactions the system must support. Translate scenarios into tasks for conducting walk-through activities and usability tests.
Full transcript