LECTURE 7

DESIGN PROCESS FOR

INTERACTIVE SYSTEMS
 The Design Process

 Software Engineering and the design process for interactive

systems

 Standards and guidelines as design rules

 Usability engineering

 Iterative design and prototyping

 Design rationale
 Introduction

• Paradigms and principles concentrated on examining

techniques & guidelines for usability

• Now we focus on the process of design.

• Software engineering is the discipline concerned with

understanding the design process/life cycle of software

• Designing for usability occurs at all stages of the life cycle, not
as a single isolated activity
 The software life cycle
Requirements
specification

Architectural
design

Detailed
design

Coding and
unit testing

Integration
and testing
The waterfall model
 
Operation and
Maintenance
 Activities of the life cycle
• Requirements specification
Capture of what the system is expected to provide -can be expressed in natural
language or more precise language such as UML notation
• Architectural design
High-level description of how the system will provide the services required -
major components of the system and how they are interrelated
• Detailed design
Refinement of architectural components and interrelations to identify modules to
be implemented separately
• Coding & unit Testing _Implementation & testing of individual components
• Integration & testing Integration of components & testing of integrated
system
• Operation & maintenance Project manag’t & manag’t of usage support
 The life cycle for interactive systems

Requirements
specification

cannot assume a linear

Architectural sequence of activities
design
as in the waterfall model
Detailed
design

Implementation
and unit testing

Integration
and testing

Operation and
Maintenance
 Using design rules

• Design rules suggest how to increase usability

• ISO 9241 defines usability as effectiveness, efficiency and

satisfaction with which users accomplish tasks

Standards
• Set by national or international bodies to ensure compliance by a

large community of designers

• Require sound underlying theory and slowly changing technology

• Hardware standards more common than software

 Using design rules (cont'd)
 
Guidelines
•More suggestive and general

•Many textbooks and reports full of guidelines

•Abstract guidelines (principles) applicable during early life

cycle activities

•Detailed guidelines (style guides) applicable during later life

cycle activities

•Understanding justification for guidelines aids in resolving

conflicts between different guidelines
 Usability Engineering
• The ultimate test of usability is based on measurement of user
experience
• Usability engineering demands that specific usability measures be
made explicit as requirements
• Usability specification-measures performance of particular aspects of a
system.
Problems
• Usability specification requires level of detail that may not be possible
early in design e.g. specific actions & their sequence
• Satisfying a usability specification does not necessarily satisfy usability.
 Iterative Design and Prototyping

Purposeful design process which tries to overcome problems of

incomplete requirements specifications. by cycling thru several
designs incrementally improving upon final product.
Prototypes (tech. side of describing iterative design) i.e.
Artifacts that represent/simulate/animate some features of intended
system
 Iterative Design and Prototyping
Types of prototypes
•Rapid throw-Away-Design knowledge gained used to build final product but
actual prototype discarded

• Incremental-Final product built as separate components/one at a time thought

there’s overall design for final system

• Evolutionary-Prototype serves as basis for next iteration of design. actual

system evolves from prototype thru iterations to final product

Importance –projected realism to test requirements by evaluating impact with

real users
Management issues
• Time e.g. for throwaway prototypes
• Planning for prototyping less valued/underlooked
• Non-functional features including usability features neglected in testing
prototypes
 Techniques for Prototyping
• Limited functionality simulations

Attach behavior to graphical and textual interaction objects to mimic the

system’s functionality. This can be evaluated & quickly changed to
reflect results of evaluation study with various users
• 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.
Benefits of design rationale

• Communication throughout life cycle

• Reuse of design knowledge across products

• Enforces design discipline

• Presents arguments for design trade-offs/alternatives

• Organizes potentially large design space for big projects

• Capturing contextual information about various aspects of the

project
 Design rationale (cont’d)

Types of DR:
 Process-Oriented
• Preserves order of deliberation and decision-making

 Structure-Oriented
• Bases on more stable functional structure than
multiple design meetings
Two examples:
• Issue-based information system (IBIS)

• Design space analysis

 Issue-Based information System (IBIS)

• Basis for much of design rationale research

• Process-oriented

• Hierarchical structure of issues, with one root issue

• Positions are potential resolutions of an issue

• Arguments modify the relationship between positions

and issues
• Gibis is a graphical version
 Design Space Analysis

• Structure-Oriented
• Hierarchical structure

Questions (and sub-questions)

Represent major issues of a design options
Options provide alternative solutions to the question
Criteria the means to assess the options in order to make a choice
 Psychological Design Rationale

• To support task- 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