CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.
-
Upload
harold-allen -
Category
Documents
-
view
225 -
download
0
Transcript of CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.
![Page 1: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/1.jpg)
CS5714 Usability Engineering
Systems Analysis
Copyright © 2003 H. Rex Hartson and Deborah Hix.
![Page 2: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/2.jpg)
SA2
Topics
Ethnographic field studies
Product concept statement
Business process model
Needs analysis
User class definitions
Task analysis
Usability goals
Constraints
MENU
![Page 3: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/3.jpg)
SA3
Introduction to Systems Analysis
Revisiting the usability engineering life cycle
![Page 4: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/4.jpg)
SA4
Ethnographic Field Visit
In anthropology and sociology, ethnography is:
– Participating, “overtly or covertly, in people’s daily
lives for an extended period of time, watching what
happens, listening to what is said, asking questions” [Hammersley & Atkinson 1983, as quoted by Shneiderman, p. 107]
![Page 5: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/5.jpg)
SA5
Ethnographic Field Visit
For user interaction requirements gathering:– UI designers limit study to days or
even hours, but have to obtain needed data
“Quick and dirty ethnography”
– Cannot obtain needs information by just brainstorming in your own office
– Cannot substitute market research for ethnographic studies
![Page 6: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/6.jpg)
SA6
Ethnographic Requirements Gathering
Process for UI ethnography includes:– Preparation for field study
Start with “brainstorming” of user task statements Understand organization’s policies & culture Check out their website Know current system & history Prepare script of questions for interview Select appropriate users to observe and/or interview Obtain permission to observe and/or interview
![Page 7: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/7.jpg)
SA7
Ethnographic Requirements Gathering
– Perform field study Establish rapport with managers and clients Observe and/or interview users in workplace Collect quantitative and qualitative data Collect artifacts (e.g. paper forms) as available Follow leads from visits, if any Document and characterize user classes Document work flow/user task analysis
– Keep focus of activities user centered!
![Page 8: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/8.jpg)
SA8
Ethnographic Requirements Gathering
Cannot just ask “What objects do you interact with?”
Explain to users why you are there Have to “tease out” needed
information Have initial questions scripted in
advance Be ready to modify, explore, be
ready to modify, explore, branch out
Customers
![Page 9: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/9.jpg)
SA9
Ethnographic Requirements Gathering
Seems easy, but it’s not
– Hidden traps, surprises (e.g. what to wear,
different perceptions of managers vs.
users, different use of language/technical
terms)
Reqts changing
![Page 10: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/10.jpg)
SA10
Ethnographic Requirements Gathering
Equally important as data collected: rapport/relationships with client, users established during process
What if client is reluctant to give access to users?– Ask for a couple of hours– Establish necessity for usability
![Page 11: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/11.jpg)
SA11
Ethnographic Requirements Gathering
Caution: Difficult for users to tell developers what they want or need– Do not expect users to do design!– Important to observe users in their typical work
environment
Developer: I try to tell users what they need, but they don’t want to listen to me
![Page 12: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/12.jpg)
SA12
Ethnographic Requirements Gathering – In Sum
The “User Interface Requirements Detective”
– Goal of ethnography for UI designer is to discover, extract, and collect the “clues” needed to ensure usability of design
![Page 13: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/13.jpg)
SA13
Introduction To Example System
Calendar System– Simple automated version of a
paper calendar– Goal is to learn the development
process, not to produce a marketable calendar product
– Working assumptions: some boundaries (e.g., hardware) set by management, customers, marketing, etc., there is a need for this product
![Page 14: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/14.jpg)
SA14
Example: System Analysis
Goal:– To make a fast tour through the process of
determining basic user and system requirements
Activities:– A sampling of product concept statement, needs
analysis, business process model, user class definition, task analysis, usability goals, and constraints
![Page 15: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/15.jpg)
SA15
Product Concept Statement
Product concept statement-brief descriptive summary of product, typically 50-75 words
Mission statement for a product, to help focus product development
Writing a good product concept statement is not easy and is not done once, highly iterative
![Page 16: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/16.jpg)
SA16
Product Concept Statement
Answer the following questions:– What is the product name?– Who are the product users?– What will the product do?– What problem(s) will the product solve?
![Page 17: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/17.jpg)
SA17
Product Concept Statement
A possible product concept statement for Calendar:– Our calendar will have automated support for
scheduling appointments, to improve customer satisfaction.
Too vague
![Page 18: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/18.jpg)
SA18
Product Concept Statement
A better product concept statement (47 words):– The Calendar will allow a broad variety of users to
schedule and manage appointments. These users can range from professionals using the system to run an office to casual users keeping track of personal information. Automated support will reduce scheduling effort and increase awareness of appointments.
![Page 19: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/19.jpg)
SA19
Product Concept Statement
Example of being more specific
– ‘Automated support will reduce scheduling effort
and increase awareness of appointments.’
Reduce scheduling by supporting recurring appointments.
Increase awareness by giving alarm (visual and/or audible)
![Page 20: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/20.jpg)
SA20
Team Exercise – Product Concept Statement
Overall goal: On-going exercise in developing the interaction design for a specific Web application: A public ticket buying kiosk
Exercise goal: Write a concise product concept statement for your ticket kiosk system
![Page 21: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/21.jpg)
SA21
Team Exercise – Product Concept Statement
Activities: – Assemble in project teams– Talk about your approach to
the kiosk– Write a product concept statement– Iterate and polish it
Deliverables– Your “final” product concept statement, hand-written
on plastic overhead– Schedule: Due yesterday!
![Page 22: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/22.jpg)
SA22
Example: Needs Analysis
Goal of system: manage appointmentsAssumption: Some boundaries set by
management, marketing, customer, etc. (e.g., hardware); determination made that product is novel, market not yet saturated
Features– Appointment means information on:
Date Time Place
![Page 23: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/23.jpg)
SA23
Example: Needs Analysis
Appointment description– Manage means
Add new appointment Delete existing appointment Modify existing appointment
– Plus, need ability to view/display appointments
(Task=user, function=system)
Follows from talking with client, users; not just developers’ ideas
![Page 24: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/24.jpg)
SA24
Example: Needs Analysis
After observing users, someone thinks of “alarm” idea (the needs don’t come all at once, up front)
– Do we want to actively inform of appointments (maybe ask or observe users)
– Decision: Yes, very useful; a way to beat paper– Iterate and revise needs
New feature: Active reminder (increased functionality)
![Page 25: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/25.jpg)
SA25
Business Process Modeling
Understand application domain Important for non-UI software, too Goal is to capture
– What gets done to run business– Who does what and how it gets done– How it relates to other things that get done
![Page 26: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/26.jpg)
SA26
Business Process Modeling
How to capture it– Look for both computer-supported and non-
computer tasks– Gather and study work artifacts (e.g., paper work,
tickets, slips)– Describe work flow, task flow, data & document flow– Flow charts are good (e.g., tasks are flow lines
to/from people (users) and data objects
![Page 27: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/27.jpg)
SA27
Team Exercise – Business Process Model
Goal: a one-page diagram illustrating high-level business process (obviously an over-simplification) for your ticket kiosk operation
Activities: – Sketch out a diagram showing business roles,
information flow, information repositories, transactions, etc.
Deliverable: one sheet plastic overhead Schedule: Now!
![Page 28: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/28.jpg)
SA28
User Class Definition
“Know thy user”—and it is not you!– Important to have representative user(s) on
development team and/or have access to representative user(s)
Most of system analysis (e.g., task analysis, usability goals, usability specifications) is done for each user class
Used car
User classes are about roles, not individuals
![Page 29: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/29.jpg)
SA29
User Class Definition
User knowledge of application/work domain User knowledge of computers Training and application-related experiences Frequency of use User goals Job- or task-related factors (e.g., job
description, location, level of responsibility)
![Page 30: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/30.jpg)
SA30
User Expertise Level
Expertise levels don’t necessarily define user classes, but can occur within user classes– Novice or first-time user: may know application
domain but not specifics of application– Intermittent user: uses several systems from time
to time; knows application domain but not details of different applications
![Page 31: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/31.jpg)
SA31
User Expertise Level
– Experienced user: “power” user, probably uses application daily and knows both application and task domain very well
Design may have to account for each of these expertise levels
Remember: experienced users for some systems are novices for others
These are not the specific user class types you should identify for your project!
![Page 32: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/32.jpg)
SA32
Example: User Class Definition
What are characteristics of users of Calendar system?– General Characteristics
Busy people Keep schedule for self and others Professional and personal use Calendar is very small part of job Need ‘transparent’ tool High general skill level, literate
![Page 33: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/33.jpg)
SA33
Example: User Class Definition
– Domain skills Know how to use calendar
– Computer skills Broad range At least some typing skills Familiar with GUI/mouse
![Page 34: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/34.jpg)
SA34
Example: User Class Definition
Conclusion– Keep it simple– Usability as important as functionality (or more)– Try to get functionality greater than paper calendar– Minimize typing– Users must learn quickly
User class characterization matrix– First, decide on most appropriate set of parameters
for your domain and context
![Page 35: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/35.jpg)
SA35
Example: User Class Characterization Matrix
User class A User class B
Computer knowledge
Domain knowledge
Complexity of domain content
Discretionary or captive?
![Page 36: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/36.jpg)
SA36
Example: User Class Characterization Matrix
User class A User class B
Receptive/resistant?
Usage frequency, duty cycle
With whom do they interact (outside system)
![Page 37: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/37.jpg)
SA37
Example: User Class Characterization Matrix
User class A User class B
What information is exchanged (outside system)?
Training?
Culture of work context?
![Page 38: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/38.jpg)
SA38
Culture of Work Context
Culture of work context is the overall flavor, philosophy, ambience, and environment of user’s work– It’s about thought processes and mind set, policies,
terminology – Example: steel mill floor is about noise, dust, hot
temperatures, safety concerns, making iron and steel
– Doctor’s office is very different culture
![Page 39: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/39.jpg)
SA39
Team Exercise – User Class Definition
Goal: Define characteristics of your major user classes
Activities: fill out form on plastic overhead Schedule: Do it now, in class
![Page 40: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/40.jpg)
SA40
Task Analysis
What developers observe that users need, not what developers think that user need
Task analysis gives inventory of user needs; feeds scenarios in design
Task analysis is probably the most overlooked and shortchanged activity in the whole user interaction development process
Used car
![Page 41: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/41.jpg)
SA41
Task Analysis
Hierarchical task analysis (HTA)
– Structured, organization, and relationships of tasks users
perform with system
– Not timing, precedence, order of task performance, work flow,
etc.
– Only what users can do, not must do
Psychic
![Page 42: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/42.jpg)
SA42
Task Analysis
Hierarchical task decomposition (key ideas)
– Task names: <action object>
Examples: add appointments, configure parameters
– User-centered wording, not system centered
Example: view appointment, not display appointment
![Page 43: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/43.jpg)
SA43
Task Analysis
Hierarchical task decomposition (key ideas)
– Hierarchical relationships
means A is a super-task of B, B is a sub-task of A
– Semantics: Doing B is part of doing A (a "litmus" test for this
characteristic
– Example: Task a is filing out form; task B is filling out name
field
A
B
![Page 44: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/44.jpg)
SA44
Task Analysis
Hierarchy does not show sequencing– Incorrect attempt at hierarchical relationship:
Drive car
Start engine
Select gear
Press gas pedal
![Page 45: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/45.jpg)
SA45
Example: Task Analysis
What tasks will users perform with this system?– For highest-level tasks, start with goal of system:
Manage appointments – Appointment means information on: Date, time,
place, appointment description – Manage means
Add new appointment Change/delete existing appointment Plus ability to view appointments
– This all follows from user interviews/observations, not just developer’s ideas
![Page 46: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/46.jpg)
SA46
Example: Task Analysis
What tasks will users perform with this system?– Tasks are performed by user (e.g., view)– Initial list of major sub-tasks
Add new appointment
View existing appointments
Modify existing appointments
Delete existing appointments
Set alarm
View calendar
![Page 47: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/47.jpg)
SA47
Example: Task Analysis
Task analysis iterated– As thinking about viewing appointments, realize the
need for different levels or scopes of view
For example, by month, by week, by day, by hour
Implication: add “control view” task to list
![Page 48: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/48.jpg)
SA48
Example: Task Analysis
– Also discovered need to search appointment database to retrieve by content
Implication: add to needs, tasks, functions, requirements
Note: from here on, “requirements” means interaction
design requirements (but cannot separate entirely from system, functional
requirements)
![Page 49: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/49.jpg)
SA49
Example: Task Analysis
– Another example of iteration: Alarm feature will lead to user tasks (to
set parameters)
Decision: for now, hard wire for 10
minutes before appointment; no user
tasks
Good example of early simplistic design decision; needs iteration
![Page 50: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/50.jpg)
SA50
Example: Task Analysis
Example of possible quasi-hierarchical user task structure for Calendar
– Structure diagram is accompanied by brief description of what each box means
manage calendar
access
appt.
add
appt.
update
appt.
delete
appt.
establish
alarm
set
alarm
set alarm
params
edit
appt.
search access
month
access
week
access
day
access
time slot
scroll
up
scroll
down
select (any
time slot)select (object)
select (any
month)
move foward
by month
move backward
by month
![Page 51: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/51.jpg)
SA51
Usability Goals
Usability evaluation design driven by usability goals Usability goals driven by business objectives Determine usability goals in terms of
– User classes– User task content, special tasks– Walk-up-and-use learnability– High performance for expert users– User errors– User satisfaction
![Page 52: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/52.jpg)
SA52
Usability Goals
Example usability goals for Calendar– Fast walk-up-and-use for simple tasks– High learnability for more advanced tasks– Low error rate for rescheduling appointments– Increased effectiveness of calendar by
helping users avoid missed appointments
![Page 53: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/53.jpg)
SA53
Usability Goals
High-level objectives in terms of usability and design of user interaction
– Reflect real use of product in real world
– Determine what is important to
organization and to users
– Example: Learnability for new users,
power performance for experts, avoiding
errors
– Usability goals can be market driven
![Page 54: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/54.jpg)
SA54
Team Exercise – Task Analysis, Usability Goals
Goal: Simple task analysis and usability goal statement for your kiosk system
Activities: – Sketch a simple HTA diagram– Write down a few usability goals for your kiosk
Deliverable: HTA diagram, usability goals statement, each on a sheet of plastic overhead
Schedule: Now
![Page 55: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/55.jpg)
SA55
Constraints
Cost and budget Schedule and development time
– What restrictions do budget and schedule impose on product scope?
Size and/or weight– Will product be on portable or mobile equipment?
Integration with existing or other developing systems
Security or privacy issues
![Page 56: CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.](https://reader035.fdocuments.net/reader035/viewer/2022062221/56649e395503460f94b2a8f8/html5/thumbnails/56.jpg)
SA56
Constraints
Example constraints for Calendar System:– Prod will be used in wide variety of environments,
from factory floors to open offices to homes– Product will run on wide variety of
platforms, but mostly PCs, laptops with no special devices
– Budget is highly limited– Schedule is one semester!
Systems analysis