Download presentation
Presentation is loading. Please wait.
Published byHester Heath Modified over 8 years ago
1
Lecture 7 Design Process for Interactive Systems
2
The design process z Software engineering and the design process for interactive systems z Standards and guidelines as design rules z Usability engineering z Iterative design and prototyping z Design rationale
3
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
4
The software life cycle The waterfall model
5
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
6
The life cycle for interactive systems cannot assume a linear sequence of activities as in the waterfall model
7
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
8
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 btn different guidelines
9
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. Consists of 7 issues: - usability attribute/principle e.g. backward recoverability for VCR -measuring concept e.g. undo an erroneous operational sequence of VCR -measuring method e.g. number of user actions to undo current operation -now level e.g. no current product allows such undo -worst case e.g. as many actions as it takes to program in mistake -planned level e.g. a maximum of two explicit user actions -best case e.g. one explicit cancel action 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 e.g. in the VCR ex., its assumed that fewer action make the undo operation easier Solution-Combine it with other methods like task analysis-scenarios, personas etc.
10
Iterative design and prototyping Purposeful design process which tries to overcome probs of incomplete requir’ts spec. by cycling thru several designs incrementally improving upon final product with each pass Prototypes (tech. side of describing iterative design) i.e. Artifacts that represent/simulate/animate some features of intended system: Types of prototypes throw-away-design knowledge gained used to build final prdct but actual prototype discarded incremental-final prdct 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 contracts-hard to make prototypes part of contract
11
Techniques for prototyping Storyboards-can be paper based or computer-based can be animated
12
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 e.g. why a user could not use a 12hr clock on a microwave oven Look for More techniques
13
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
14
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 Design rationale (cont’d)
15
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
16
Design space analysis structure-oriented QOC – 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
17
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
18
Reference Dix et al HCI 2 nd edition, chap.5 Revision Qn: a)Choose an example of a system of your choice and develop a usability specification for one of its core functions b)Choose an organization or community need that can be partly or wholly addressed through a web based system and develop a storyboard for this system.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.