Flashcards
HCI final
Cards in this deck (59)
- 1The software lifecycleSoftware engineering is the discipline for understanding the software design process, or life cycle
Designing for usability occurs at all stages of the life cycle, not as a single isolated activity - 2Why ‘establish’?Requirements arise from understanding users’ needs
Requirements can be justified & related to data - 3Different kinds of requirementsFunctional: What the system should do
Non-functional: security, response time, etc
Data: What kinds of data need to be stored? How will they be stored (e.g. database)? - 4Users: Who are they?Characteristics: nationality, educational background, attitude to computers
System use: novice, expert, casual, frequent
Novice: prompted, constrained, clear
Expert: flexibility
Frequent: short cuts
Casual/infrequent: clear menu paths - 5Requirement - Functionalthe product will calculate the total cost of purchases
- 6Requirement - Datathe product must have access to the price of products in the cafeteria
- 7Requirement - Environmentalcafeteria users will be carrying a tray and will most likely be in a reasonable rush. The physical environment will be noisy and busy
- 8Requirement - User characteristicsthe majority of users are likely to be under 25 and comfortable dealing with technology
- 9Requirement - Usability goalthe product needs to be easy to learn so that new users can use it immediately, and memorable for more frequent users
- 10Requirement - User experience goalssatisfying, helpful, and enhancing sociability
- 11Usability engineeringThe ultimate test of usability based on measurement of user experience
Usability engineering demands that specific usability measures be made explicit as requirements - 12ISO usability standard 9241effectiveness–can you achieve what you want to?
efficiency–can you do it without wasting effort?
satisfaction–do you enjoy the process? - 13Iterative design and prototypingThe problem with usability metrics is that they rely on measurements of very specific user actions in very specific situations.
- 14Iterative design and prototypingIterative design overcomes inherent problems of incomplete requirements by cycling through several designs, incrementally improving upon the final product with each pass
- 15What is a Prototype?“A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from.” –Wikipedia
In short, it's a working representation of a final artifact - 16Prototype dimensionsRepresentation: form of the prototype
Precision: level of detail
Interactivity: watch-only vs. fully interactive
expected life cycle of prototype - 17Throw-away prototypeThe prototype is built and tested. The design knowledge gained is used to build the final product. The actual prototype is discarded
- 18Incremental prototypeThe final product is built as separate components, one at a time. There is one overall design for the final system, but it is partitioned into independent and smaller components. The final product is then released as a series of products
- 19Evolutionary prototypeThe prototype is not discarded and serves as the basis for the next iteration of design. In this case, the actual system is seen as evolving from
- 20Fidelity in PrototypingHigh fidelity - prototype looks like final product (wireframe render)
Low fidelity - artist rendition of prototype (usually drawn on paper) - 21Techniques for prototypingStory boards - need not be computer-based and can be animated
Limited functionality simulations - some part of system functionality provided by designers - 22Design rationaleDesign rationale is information that explains why a system/application is the way it is
- 23Benefits of design rationalecommunication throughout life cycle
reuse of design knowledge across products
enforces design discipline
organizes potentially large design space - 24Goals of EvaluationAssess extent of system functionality
Assess effect of interface on use
Identify specific problems - 25Evaluation through Expert AnalysisCognitive Walkthrough
Heuristic Evaluation
Model-Based
Review-based evaluation - 26Evaluation through User ParticipationLaboratory studies
Field studies - 27Cognitive WalkthroughProposed by Polson et al
evaluates design on how well it supports user in learning task
usually performed by expert in cognitive psychology
focuses on goals and knowledge: does the design lead the user to generate the correct goals? - 28Cognitive consFew ethical & practical issues to consider because users not involved
Can be difficult & expensive to find experts - 29Heuristic EvaluationProposed by Nielsen and Molich
Usability criteria (heuristics) are identified
design examined by experts to see if these are violated
Heuristic evaluation 'debugs' design - 30Why do user testing?Helps understand how effective your UI is
hard to predict what a real user would do - 31Laboratory studiesAdvantages:
specialist equipment available
Uninterrupted environment
Disadvantages:
lack of context
difficult to observe several users cooperating - 32Field studiesAdvantages:
natural environment
context retained
Disadvantages:
distractions
noise - 33Four roles during user testingGreeter–puts users at ease
Facilitator–only team member who speaks
computer–knows application logic & controls it
Observers–take notes - 34Types of data to collect in user testingProcess data - observations of what users are doing & thinking
Bottom-line data - summary of what happened - 35Think aloud evaluationUsers observed performing task:
user asked to describe what he/she is doing and why, what he/she thinks is happening etc - 36Cooperative evaluationVariation on think aloud:
user collaborates in evaluation
both user and evaluator can ask each other questions throughout - 37Measuring bottom-line usabilitySituations in which numbers are useful:
time requirements for task completion
successful task completion %
compare two designs on speed or # of errors - 38Between group experimenttwo groups of test users
each group uses 1 of the systems - 39Within group experimentone group of test users
each person uses both systems - 40Measuring user feedbackHow much users like or dislike the system
what they liked, disliked, where they had trouble, best part, worst part, etc
redundant questions are OK - 41Heuristic EvaluationDeveloped by Jakob Nielsen
Helps find usability problems in a UI design
Small set (3-5) of evaluators examine UI - 42H2-1: Visibility of system statusThe system should always keep users informed about what is going on, through appropriate feedback within reasonable time
- 43H2-2: Match between system and the real worldThe system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms
- 44H2-3: User control & freedomUsers often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue
- 45H2-4: Consistency & standardsUsers should not have to wonder whether different words, situations, or actions mean the same thing
- 46H2-5: Error preventionEven better than good error messages is a careful design which prevents a problem from occurring in the first place
- 47H2-6: Recognition rather than recallMinimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another
- 48H2-7: Flexibility and efficiency of useAccelerators —unseen by the novice user —may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users
- 49H2-8: Aesthetic & minimalist designDialogues should not contain information which is irrelevant or rarely needed
- 50H2-9: Help users recognize, diagnose, and recover from errorsError messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution
- 51H2-10: Help and documentationEven though it is better if the system can be used without documentation, it may be necessary to provide help and documentation
- 52How to perform evaluationAt least two passes for each evaluator
first to get feel for flow and scope of system
second to focus on specific elements - 53Severity rating of problems0-4 with 0 being; don't agree this is a problem and 4 being; huge problem
- 54Personas and user storiesUsed as an aid to help express, discuss and validate design questions and decisions
- 55Scenarios and use casesScenarios are stories that help us understand interactions
- 56RequirementsWhat does the client want to do?
- 57Likert-scale
- 58Avoid these types of questionsBiased questions:
Don't you agree that campus parking is a problem?
Double-barreled questions:
Do you agree that campus parking is a problem and that the administration should be working diligently on a solution?
confusing questions and unrelated questions - 59QuestionnaireA well designed questionnaire is essential to a successful survey
A poorly designed questionnaire renders results meaningless
Information
- Description
- Computer Science Flashcards on HCI final, created by Duncan Levings on 11/12/2020.
- Created by
- Duncan Levings
- Views
- 2
- Rating