[HCI] 5. HCI in The Software Process

HCI in the software process

• Software engineering and the design process for interactive systems
• Usability engineering
• Iterative design and prototyping
• Design rationale

the Software Development Life-Cycle

• Software 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
• Four Essential Phases of any Software Development Process
  • Requirements Elicitation(끌어내기), Analysis, Specification
  • System Design
  • Program Implementation
  • Test

Activities in the Life Cycle

폰트와 같은 것도 굉장히 중요할 수 있다.(저작권 문제 등)

• Requirements specification
  • designer and customer try capture what the system is expected to provide
  • can be expressed in natural language or more precise languages, such as a task analysis would provide
• Architectural design
  • high-level description of how the system will provide the services required
  • factor system into major components of the system and how they are interrelated needs to satisfy both functional and nonfunctional requirements
• Detailed design
  • refinement of architectural components and interrelations to identify modules to be implemented separately
  • the refinement is governed by the non-functional requirements

Verification and validation

• Verification : product 제대로 작동하는 지 확인하는 단계
  • designing the product right
• Validation : requirement를 만족하고 있는지 확인하는
  • 잘못된 입력에 대해서 error를 만들어 내도록 하는
  • designing the right product
• The formality gap
  • validation will always rely to some extent on subjective means of proof
    • 검증은 항상 주관적인 증거 수단에 어느 정도 의존합니다.
• Management and contractual(계약상) issues
  • design in commercial and legal contexts such as patents

The Waterfall

The Life Cycle for interactive Systems

Iterative Models: Boehm Spiral Model

• An iterative model developed by Barry Boehm at TRW (1988), now Prof. at USC
• Iterates cycles of these project phases:
  • Requirements definition
  • Risk analysis
  • Prototyping
  • Simulate, benchmark
  • Design, implement, test
  • Plan next cycle (if any)

Boehm Spiral Model

바깥으로 나갈 수록 프로젝트의 마지막으로 가는 거임.

프로젝트 덩치가 커지면 커질수록 Spiral model이 더 나은 결과를 만들 확률이 높다.

• 수정에 수정을 거치기 때문

Comparison

• Waterfall Model
  • Risk factors are not considered
  • The requirements are freeze
  • Is linear sequential model (한 방향으로 쭉 감)
  • Not much costly
  • Communication level is not high
• Spiral Model
  • Risk factors are considered
  • The requirements are not freeze(계속해서 바뀜)
  • Works in loop
  • Costly as Risk factor is covered
  • Better communication between developer and customer

Usability(중요)

• Is it a “good” interface? In what ways?
• Usability:
  • How well users can use the system’s functionality
    • 사용자가 시스템의 기능을 얼마나 잘 사용하는지
  • The official ISO 9241-11 definition of usability is: “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”
• Dimensions of usability (quick look):
  • Learnability: is it easy to learn?
  • Efficiency: once learned, is it fast to use?
  • Memorability: is it easy to remember what you learned?
  • Errors: are errors few and recoverable?
  • Satisfaction: is it enjoyable to use?

effectiveness, efficiency, satisfaction 이 세 개는 항상 usability에 포함되는 내용

Usability Dimensions Vary In Importance

• So, what are the elements of usability?
• … It depends on the user (유저의 성향, 상황에 따라 중요도가 달라짐)
  • Novice users need learnability
  • Infrequent users need memorability
  • Experts need efficiency
• But no user is uniformly novice or expert. Users could have
  • Domain experience
  • Application experience
  • Feature experience

Usability Is Just One Attribute of a System

• BTW, in developing large systems, development process entails(수반하다) a (often large) team
• Software designers have a lot to worry about:
  • Functionality
  • Usability
  • Performance
  • Size
  • Cost
  • Reliability
  • Security
  • Standards
• Many design decisions involve tradeoffs among different attributes
• Which is the essence of the design process

Usability Goals

• In short, goals of increased “usability” of a system are that it is:
  • Effective to use
  • Efficient to use
  • Safe to use
  • Has good utility
  • Easy to learn
  • Easy to remember how to use
• More later …

Creating usable systems

• It aims to achieve
• Usability (Useful, Usable, Used)
  • Useful – accomplish what is required ; Effective, Safe
  • Usable – do it easily and naturally ; Efficient
  • Used – make people what to use it ; Enjoyable system
• A usable interface has three main outcomes:
  • Easy for the user to become familiar with and competent in using the user interface during the first contact.
  • Easy for users to achieve their objective through using the interface.
  • Easy to recall the user interface and how to use it on subsequent(후속) visits.

Creating usable systems

• HCI focuses on user needs by assessing interface design & implementation according to usability criteria.
• Makes use of new, novel techniques & technologies.
• It applies usability design principles to achieve more productive & usable systems and more satisfied users.

Why Usability Engineering?

• Usability engineering is a structured approach to building systems that meet the needs of users in various environments with varying levels of computer experience.
• Waterfall models of development do not work
  • too many unknowns (Dr. Brooks: No Silver Bullet)
• Need an iterative discovery-oriented process
  • but at the same time need to manage it
• Demands well-defined process with metrics
  • specifying usability goals as objectives
  • assessing and redesigning to meet these objectives
  • manage usability as a quality characteristic, much like modularity or nonfunctional requirements

Usability Engineering

• The ultimate test of usability based on measurement of user experience
• Usability engineering demands that specific usability measures be made explicit as requirements
• Usability specification
  • usability attribute/principle
  • measuring concept
  • measuring method
  • now level/ worst case/ planned level/ best case
• Problems
  • usability specification requires level of detail that may not be possible early in design
  • satisfying a usability specification does not necessarily satisfy usability

Part of a usability spec. for an Action Cam

Attribute: Backward recoverability

• Measuring concept
  • Undo an erroneous(잘못된) programming sequence
• Measuring method
  • Number of explicit user actions to undo current program
  • 현재 프로그램을 실행 취소하기 위한 명시적 사용자 작업의 수
• Now level
  • No current product allows such an undo
• Worst case
  • As many actions as it takes to program in mistake
• Planned level
  • A maximum of two explicit user actions
• Best case
  • One explicit cancel action

ISO usability standard 9241

• Adopts traditional usability categories:
• Effectiveness
  • can you achieve what you want to?
• Efficiency
  • can you do it without wasting effort?
• Satisfaction
  • do you enjoy the process?

some metrics from ISO 9241

Usability Engineering Is a Process

• … an iterative process
  • Design
  • Implement
  • Evaluate
• Look at the “spiral” model of software engineering, which systematically incorporates iteration and change

Usability Engineering Is a Process

DESIGN

• Task analysis
  • “Know thy user”
  • “Know thy domain”
• Design principles
  • Overarching (대단히 중요한, 무엇보다)
• Design guidelines
  • Avoid obvious mistakes
  • May be vague(모호한) or contradictory(모순된)

Usability Engineering Is a Process

IMPLEMENT

• Prototyping
  • Cheap, throw-away implementations
  • Low-fidelity(낮은 충실함): paper, Wizard of Oz
  • Medium-fidelity: HTML, Visual Basic
• GUI implementation techniques
  • Input/output models
  • Toolkits
  • UI builders

Usability Engineering Is a Process

EVALUATE

• Evaluation tests prototypes, using …
  • Expert evaluation
    • Heuristics and walk-throughs
  • Predictive evaluation
    • Testing against an engineering model (simulated user)
  • Empirical evaluation
    • Watching users do it

Principles of Design – Big Picture

• … of pretty much everything …and enumeration helps
• What to design
  • Need to take into account:
    • Who the users are
    • What activities are being carried out
    • Where the interaction is taking place
    • What goal of interactions is
  • Need to optimize interactions between users and a product such that they match the user’s activities and needs
• Understanding users’ needs
  • Need to take into account what people are good and bad at
  • Consider what help people in way they currently do things
  • Listen to what people want and get them involved
  • Use tried and tested user-based methods

Norman’s design principles for usability

• Visibility – The more visible functions are, the more likely users will be able to know what to do next. In contrast, when functions are “out of sight,” it makes them more difficult to find and know how to use.
• Feedback – Feedback is about sending back information about what action has been done and what has been accomplished, allowing the person to continue with the activity. Various kinds of feedback are available for interaction design-audio, tactile, verbal, and combinations of these.
• Constraints – The design concept of constraining refers to determining ways of restricting the kind of user interaction that can take place at a given moment. There are various ways this can be achieved.
• Mapping – This refers to the relationship between controls and their effects in the world. Nearly all artifacts need some kind of mapping between controls and effects. An example of a good mapping between control and effect is the up and down arrows used to represent the up and down movement of the cursor, respectively, on a computer keyboard.
• Consistency – This refers to designing interfaces to have similar operations and use similar elements for achieving similar tasks. In particular, a consistent interface is one that follows rules, such as using the same operation to select all objects. For example, to highlight any graphical object at the interface, you always click the left mouse button.
• Affordance – is a term used to refer to an attribute of an object that allows people to know how to use it. For example, a mouse button invites clicking by the way it is physically constrained in its plastic shell. When the affordances of a physical object are perceptually obvious it is easy to know how to interact with it.

Iterative design and prototyping

• Iterative design overcomes inherent problems of incomplete requirements
  • 그래서 iterative design이 중요하다.
• Prototypes
  • simulate or animate some features of intended system
  • different types of prototypes
    • Throw-away: rapid prototypes
    • Incremental: combining prototypes
    • Evolutionary: improving prototypes
• Management issues
  • time
  • planning
  • non-functional features
  • contracts

Techniques for prototyping

• Storyboards
  • need not be computer-based
  • can be animated
• Limited functionality simulations
  • some part of system functionality provided by designers
  • tools like HTML Editors are common for these
  • Wizard of Oz technique
  • Prototyping tools are also available
• Warning about iterative design
  • design inertia(무력감) – early bad decisions stay bad
  • diagnosing real usability problems in prototypes….
    • …. and not just the symptoms

Design Rationale

• Design rationale is information that explains why a computer system is the way it is.
  • the explicit listing of decisions made during a design process, and the reasons why those decisions were made
• Benefits of design rationale
  • communication throughout life cycle
  • reuse of design knowledge across products
  • enforces design discipline
  • presents arguments for design trade-offs
  • organizes potentially large design space
  • capturing contextual information

Design Rationale (cont’d)

Types of DR:

• Process-oriented
  • preserves order of deliberation and decision-making
    • 심의 및 의사결정 질서를 유지하다.
• Structure-oriented
  • emphasizes post hoc structuring of considered design alternatives
    • 고려된 설계 대안들의 사후 구조를 강조한다.
• Two examples:
  • Issue-based information system (IBIS)
  • Design space analysis

Issue-based information system (IBIS)

• basis for much of design rationale research
• process-oriented
• main elements:
  • issues
    • hierarchical structure with one ‘root’ issue
  • positions
    • potential resolutions of an issue
  • arguments
    • modify the relationship between positions and issues
• gIBIS is a graphical version

structure of gIBIS

Design Space Analysis

• Structure-oriented
• QOC – hierarchical structure:
  • questions (and sub-questions)
    • represent major issues of a design
  • options
    • provide alternative solutions to the question
  • criteria
    • the means to assess the options in order to make a choice
• DRL (Decision Representation Language) – similar to QOC with a larger language and more formal semantics

the QOC notation

Psychological Design Rationale

• to support task-artefact cycle in which user tasks are affected by the systems they use
• aims to make explicit consequences of design for users
• designers identify tasks system will support
• scenarios are suggested to test task
• users are observed on system
• psychological claims of system made explicit
• negative aspects of design can be used to improve next iteration of design

Summary

• The software engineering life cycle
  • distinct activities and the consequences for interactive system design
• Usability engineering
  • making usability measurements explicit as requirements
• Iterative design and prototyping
  • limited functionality simulations and animations
• Design rationale
  • recording design knowledge
  • process vs. structure