Presentation is loading. Please wait.

Presentation is loading. Please wait.

The design process IACT 403 IACT 931 CSCI 324 Human Computer Interface Lecturer:Gene Awyzio Room:3.117 Phone:4221 4090

Similar presentations


Presentation on theme: "The design process IACT 403 IACT 931 CSCI 324 Human Computer Interface Lecturer:Gene Awyzio Room:3.117 Phone:4221 4090"— Presentation transcript:

1 The design process IACT 403 IACT 931 CSCI 324 Human Computer Interface Lecturer:Gene Awyzio Room:3.117 Phone:4221 4090 Email:gene@uow.edu.au

2 Overview z Software engineering and the design process for interactive systems y Standards and guidelines as design rules y Usability engineering y Iterative design and prototyping y Design rationale

3 Introduction z Paradigms and principles concentrated on examining the product of interactive system design. z Now we focus on the process of design. z Software engineering is the emerging discipline for understanding the design process, or life cycle. z Designing for usability occurs at all stages of the life cycle, not as a single isolated activity

4 The software life cycle z The waterfall model Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and Maintenance

5 Activities in the life cycle z Requirements specification y designer and customer try capture what the system is expected to provide y can be expressed in natural language or more precise languages, such as a task analysis would provide z Architectural design y high-level description of how the system will provide the services required y factor system into major components of the system and how they are interrelated y needs to satisfy both functional and nonfunctional requirements

6 Activities in the life cycle z Detailed design y refinement of architectural components and interrelations to identify modules to be implemented separately y the refinement is governed by the nonfunctional requirements z Coding and unit testing y implementing and testing the individual modules in some executable programming language

7 Activities in the life cycle z Integration and testing y combining modules to produce components from the architectural description z Operation and maintenance y product is delivered to customer and any problems/enhancements are provided by designer while product is still live y the largest share of the life cycle

8 Verification and validation z Verification y designing the product right z Validation y designing the right product z The formality gap y validation will always rely to some extent on subjective means of proof z Management and contractual issues design in commercial and legal contexts

9 The life cycle for interactive systems z Cannot assume a simple linear sequence of activities as assumed by the waterfall model

10 Using design rules z Design rules suggest how to increase usability

11 Using design rules z Standards y set by national or international bodies to ensure compliance by a large community of designers y standards require sound underlying theory and slowly changing technology y hardware standards more common than software y high authority and low level of detail y ISO 9241 defines usability as effectiveness, efficiency and satisfaction with which users accomplish tasks

12 Using design rules z Guidelines y more suggestive and general y many textbooks and reports full of guidelines y abstract guidelines (principles) applicable during early life cycle activities y detailed guidelines (style guides) applicable during later life cycle activities y understanding justification for guidelines aids in resolving conflicts

13 Usability engineering z The ultimate test of usability based on measurement of user experience z Usability engineering demands that specific usability measures be made explicit as requirements

14 Usability engineering z Usability specification y usability attribute/principle y measuring concept y measuring method y now level/ worst case/ planned level/ best case z Problems usability specification requires level of detail that may not be possible early in design z satisfying a usability specification does not necessarily satisfy usability

15 Iterative design and prototyping z Iterative design overcomes inherent problems of incomplete requirements z Prototypes y simulate or animate some features of intended system y different types of prototypes x throw-away x Incremental x Evolutionary y Management issues x Time x Planning x non-functional features x Contracts

16 Techniques for prototyping z Storyboards y need not be computer-based y can be animated z Limited functionality simulations y some part of system functionality provided by designers y tools like HyperCard are common for these y Wizard of Oz technique z Warning about iterative design y design inertia – early bad decisions stay bad y diagnosing real usability problems in prototypes and not just the symptoms

17 Design rationale z Design rationale is information that explains why a computer system is the way it is. z Benefits of design rationale y communication throughout life cycle y reuse of design knowledge across products y enforces design discipline y presents arguments for design trade-offs y organizes potentially large design space y capturing contextual information

18 Design rationale z Process-oriented y preserves order of deliberation and decision-making z Structure-oriented y emphasizes post hoc structuring of considered design alternatives

19 Design rationale techniques z Issue-based information system (IBIS) y basis for much of design rationale research y process-oriented y hierarchical structure of issues, with one root issue y positions are potential resolutions of an issue y arguments modify the relationship between positions and issues y gIBIS is a graphical version

20 Design rationale techniques z Design space analysis y structure-oriented y QOC – hierarchical structure x questions (and sub-questions) represent major issues of a design x options provide alternative solutions to the question x criteria are the means of assessing the various options in order to make a choice y DRL – similar to QOC with a larger language and more formal semantics

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

22 Summary z The software engineering life cycle y distinct activities and the consequences for interactive system design z Using design rules y standards and guidelines to direct design activity z Usability engineering y making usability measurements explicit as requirements z Iterative design and prototyping y limited functionality simulations and animations z Design rationale y recording design knowledge y process vs. structure


Download ppt "The design process IACT 403 IACT 931 CSCI 324 Human Computer Interface Lecturer:Gene Awyzio Room:3.117 Phone:4221 4090"

Similar presentations


Ads by Google