1 / 36

The Design Process

The Design Process. Lecture 6. Overview. Life-Cycle Models in HCI 4 basic activities in HCI Requirements Design Develop/Build Evaluation. Lifecycle Models. Show how activities are related to each other Lifecycle models are: management tools simplified versions of reality

ervin
Télécharger la présentation

The Design Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Design Process Lecture 6 www.desiamore.com/ifm

  2. Overview • Life-Cycle Models in HCI • 4 basic activities in HCI • Requirements • Design • Develop/Build • Evaluation www.desiamore.com/ifm

  3. Lifecycle Models • Show how activities are related to each other • Lifecycle models are: • management tools • simplified versions of reality • Many lifecycle models exist, for example: • from software engineering: waterfall, spiral, JAD/RAD • from HCI: Star, usability engineering Life-Cycle Models www.desiamore.com/ifm

  4. A simple interaction design model Identify needs/ establish requirements (Re)Design Evaluate Build an interactive version Final product Exemplifies a user-centered design approach Life-Cycle Models www.desiamore.com/ifm

  5. Traditional ‘waterfall’ lifecycle Requirements analysis Design Code Test Maintenance Life-Cycle Models www.desiamore.com/ifm

  6. A Lifecycle for RAD (Rapid Applications Development) Project set-up JAD workshops Iterative design and build Engineer and test final prototype Implementation review Life-Cycle Models www.desiamore.com/ifm

  7. Spiral Model (Barry Boehm) • Important features: • Risk analysis • Prototyping • Iterative framework allowing ideas to be checked and evaluated • Explicitly encourages alternatives to be considered • Good for large and complex projects but not simple ones Life-Cycle Models www.desiamore.com/ifm

  8. Spiral Lifecycle Model From cctr.umkc.edu/~kennethjuwng/spiral.htm Life-Cycle Models www.desiamore.com/ifm

  9. The Star Lifecycle Model • Suggested by Hartson and Hix (1989) • Important features: • Evaluation at the centre of activities • No particular ordering of activities. Development may start in any one • Derived from empirical studies of interface designers Life-Cycle Models www.desiamore.com/ifm

  10. The Star Model (Hartson and Hix, 1989) Implementation task/functional analysis Requirements specification Prototyping Evaluation Conceptual/ formal design Life-Cycle Models www.desiamore.com/ifm

  11. Usability engineering Lifecycle Model • Reported by Deborah Mayhew • Important features: • Holistic view of usability engineering • Provides links to software engineering approaches, e.g. OOSE • Stages of identifying requirements, designing, evaluating, prototyping • Can be scaled down for small projects • Uses a style guide to capture a set of usability goals Life-Cycle Models www.desiamore.com/ifm

  12. Usability engineering Lifecycle Model REQUIREMENTS ANALYSIS UE Task T Development Task User Profile Contextual Task Analysis Platform Capabilities/ Constraints General Design Principles Decision Point Documentation DESIGN/TESTING/DEVELOPMENT Complex Application Usability Goals Simple Application LEVEL 3 Function/Data Modeling OOSE: Requirements Model Detailed UI Design Style Guide INSTALLATION LEVEL 1 Unit/System Testing OOSE: Test Model Work Reengin- eering Iterative DUID Evaluation LEVEL 2 Installation Conceptual Model Design Screen Design Standards Met Usability Goals? NO User Feedback Enhancements CM Mockups SDS Prototyping YES Style Guide All Issues Resolved? Style Guide NO Style Guide Iterative CM Evaluation Iterative SDS Evaluation YES All Functionality Addressed? YES Eliminated Major Flaws? Met Usability Goals? NO YES NO YES NO DONE! Start Application Architecture OOSE: Analysis Model Start App. Design/Development OOSE: Design Model/Imp. Model Life-Cycle Models www.desiamore.com/ifm

  13. Design Model Requirements Design Build/Develop Evaluate Design Model www.desiamore.com/ifm

  14. Requirements A requirement is something the product must do or a quality that the product must have Requirements www.desiamore.com/ifm

  15. Requirements Different kinds of requirements: • Functional: • What the system should do • Historically the main focus of requirements activities • Non-functional: • memory size, • response time.. • Data: • What kinds of data need to be stored? • How will they be stored (e.g. database)? • Usability: • learnability • throughput • flexibility • attitude Requirements www.desiamore.com/ifm

  16. Requirements Determining Usability Requirements: • Task Analysis • User Analysis • Environment Analysis Requirements www.desiamore.com/ifm

  17. Requirements 1. Task Analysis • Task analysis describes the behavior of a system • Determine cognitive and other characteristics required of users by system • Observe existing work practices • Create scenarios of actual use • new ideas before building software! • Get rid of problems early in the design process Requirements www.desiamore.com/ifm

  18. Requirements Task Analysis • Who is going to use the system? • What tasks do they now perform? • What tasks are desired? • How are the tasks learned? • Where are the tasks performed? • What’s the relationship between user & data? Requirements www.desiamore.com/ifm

  19. Requirements Types of Task Analysis • Task Decomposition (top-down) • Select a task • Divide the task into sub-tasks • If your stopping rule has not been reached, repeat steps 1-3 for each of the new sub-tasks. • Knowledge Based Analysis (bottom-up) • List all of the objects and actions that are relevant to the task • Groups based on similarity or shared traits • The groups themselves are then grouped together, building progressively more abstract categories • Entity-Relationship Based Analysis (bottom-up) • concerns itself with objects, actions, and their relationship Requirements www.desiamore.com/ifm

  20. Requirements 2. User Analysis • Who are they? • Characteristics: ability, background, attitude to computers • System use: novice, expert, casual, frequent • Novice: step-by-step (prompted), constrained, clear information • Expert: flexibility, access/power • Frequent: short cuts • Casual/infrequent: clear instructions, e.g. menu paths Requirements www.desiamore.com/ifm

  21. Requirements 3. Environment Analysis • Physical: dusty? noisy? vibration? light? heat? humidity? …. (e.g. OMS insects, ATM) • Social: sharing of files, of displays, in paper, across great distances, work individually, privacy for clients • Organisational: hierarchy, IT department’s attitude and remit, user support, communications structure and infrastructure, availability of training Requirements www.desiamore.com/ifm

  22. Design Model Requirements Design User-centred design Build/Develop Evaluate Design Model www.desiamore.com/ifm

  23. User-Centred Design • Why involve users at all? • What is a user-centered approach? • Understanding user’s work • Ethnographic observation • Participatory design • PICTIVE • CARD User-Centred Design www.desiamore.com/ifm

  24. Why involve Users? • Expectation management • Realistic expectations • No surprises, no disappointments • Timely training • Communication, but no hype • Ownership • Make the users active stakeholders • More likely to forgive or accept problems • Can make a big difference to acceptance and success of product User-Centred Design www.desiamore.com/ifm

  25. What is a User-Centred Approach? User-centered approach is based on: • Early focus on users and tasks: directly studying cognitive, behavioural, anthropomorphic & attitudinal characteristics • Empirical measurement: users’ reactions and performance to scenarios, manuals, simulations & prototypes are observed, recorded and analysed • Iterative design: when problems are found in user testing, fix them and carry out more tests User-Centred Design www.desiamore.com/ifm

  26. Ethnographic Observation • Preparation • Understand organisation policies and work culture. • Familiarise yourself with the system and its history. • Set initial goals and prepare questions. • Gain access and permission to observe/interview. • Field Study • Establish rapport with managers and users. • Observe/interview users in their workplace and collect subjective/objective quantitative/qualitative data. • Follow any leads that emerge from the visits. User-Centred Design www.desiamore.com/ifm

  27. Ethnographic Observation • Analysis • Compile the collected data in numerical, textual, and multimedia databases. • Quantify data and compile statistics. • Reduce and interpret the data. • Refine the goals and the process used. • Reporting • Consider multiple audiences and goals. • Prepare a report and present the findings. User-Centred Design www.desiamore.com/ifm

  28. Participatory Design User-Centred Design www.desiamore.com/ifm

  29. Participatory Design • Participatory design is an approach to design that attempts to actively involve the end users in the design process. • It assumes that users should play an active role in the creative process: users envision the future by identifying the defining moments from their perspective User-Centred Design www.desiamore.com/ifm 29

  30. Participatory Design • Controversial • More user involvement brings: • more accurate information about tasks • more opportunity for users to influence design decisions • a sense of participation that builds users' ego investment in successful implementation • potential for increased user acceptance of final system User-Centred Design www.desiamore.com/ifm

  31. Participatory Design • However, extensive user involvement may: • be more costly • lengthen the implementation period • build antagonism with people not involved or whose suggestions rejected • force designers to compromise their design to satisfy incompetent participants • build opposition to implementation • exacerbate personality conflicts between design-team members and users • show that organisational politics and preferences of certain individuals are more important than technical issues User-Centred Design www.desiamore.com/ifm

  32. Participatory Design PICTIVE • Plastic Interface for Collaborative Technology Initiatives through Video Exploration • Intended to empower users to act a full participants in design • Materials used are: • Low-fidelity office items such as pens, paper, sticky notes • Collection of (plastic) design objects for screen and window layouts • Equipment required: • Shared design surface, e.g. table • Video recording equipment User-Centred Design www.desiamore.com/ifm

  33. Participatory Design PICTIVE (cont.) • Before a PICTIVE session: • Users generate scenarios of use • Developers produce design elements for the design session • A PICTIVE session has four parts: • Stakeholders all introduce themselves • Brief tutorials about areas represented in the session (optional) • Brainstorming of ideas for the design • Walkthrough of the design and summary of decisions made User-Centred Design www.desiamore.com/ifm

  34. Participatory Design CARD • Collaborative Analysis of Requirements & Design • Similar to PICTIVE but at a higher level of abstraction: explores work flow not detailed screen design • Uses playing cards with pictures of computers and screen dumps • Similar structure to the session as for PICTIVE • PICTIVE and CARD can be used together to give complementary views of a design User-Centred Design www.desiamore.com/ifm

  35. Summary of Lecture • Lifecycle models • Software engineering lifecycle models • HCI lifecycle models   • Usability Engineering Lifecycle Model • Star Lifecycle Model • HCI design models • Requirements • Design • User-centred design • Develop/Build • Evaluation www.desiamore.com/ifm

  36. Terms of Reference • Preece, J. et al. (2002) Interaction Design • Shneiderman, B. & Plaisant, C. (2005) Designing the User Interface • Benyon, D. et al (2005) Designing Interactive Systems • Helander, M. et al (1997) Handbook of Human-Computer Interaction • Hartson, R. & Hix, D. (1989) Towards Empirically Derived Methodologies and Tools for HCI Development • Mayhew, D. (1995) The Usability Engineering Lifecycle • Alan Dix et al (1993) Human Computer Interaction References www.desiamore.com/ifm

More Related