CS5714 Usability Engineering Systems Analysis Copyright © 2003 H. Rex Hartson and Deborah Hix.

SA 2 Topics Ethnographic field studies Product concept statement Business process model Needs analysis User class definitions Task analysis Usability goals Constraints

SA 3 Introduction to Systems Analysis Revisiting the usability engineering life cycle

SA 4 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]

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

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

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

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

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

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

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

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

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

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

SA 15 Product Concept Statement Product concept statement-brief descriptive summary of product, typically 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

SA 16 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?

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

SA 18 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.

SA 19 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)

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

SA 21 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!

SA 22 Example: Needs Analysis Goal of system: manage appointments Assumption: 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

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

SA 24 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)

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

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

SA 27 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!

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

SA 29 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)

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

SA 31 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!

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

SA 33 Example: User Class Definition – Domain skills Know how to use calendar – Computer skills Broad range At least some typing skills Familiar with GUI/mouse

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

SA 35 Example: User Class Characterization Matrix User class AUser class B Computer knowledge Domain knowledge Complexity of domain content Discretionary or captive?

SA 36 Example: User Class Characterization Matrix User class AUser class B Receptive/ resistant? Usage frequency, duty cycle With whom do they interact (outside system)

SA 37 Example: User Class Characterization Matrix User class AUser class B What information is exchanged (outside system)? Training? Culture of work context?

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

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

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

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

SA 42 Task Analysis Hierarchical task decomposition (key ideas) – Task names: Examples: add appointments, configure parameters – User-centered wording, not system centered Example: view appointment, not display appointment

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

SA 44 Task Analysis Hierarchy does not show sequencing – Incorrect attempt at hierarchical relationship: Drive car Start engine Select gear Press gas pedal

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

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

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

SA 48 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)

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

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

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

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

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

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

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

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