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
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