Agenda
• Software engineering and the classic model Lecture 12 • Iterative design and prototyping
– Taking a user centered approach HCI in the software • When is each best? process • Self study – read and take your own notes
Dix Chapter 6 – Usability engineering
The software lifecycle The classic waterfall model
RequirementsRequirements specificationspecification • we know for sure that the • Software engineering is the discipline for waterfall model doesn’t understanding the software design ArchitecturalArchitectural work process, or life cycle design design • But it is a useful model to describe the steps DetailedDetailed • Designing for usability occurs at all stages designdesign of the life cycle, not as a single isolated
activity CodingCoding andand unitunit testingtesting
• There are many models of the software IntegrationIntegration life cycle we will look at the classic andand testingtesting waterfall model and user centered design OperationOperation andand maintenance Detailed design & Activities in the life cycle Implementation
• Detailed design of the interface • Requirements specification • Move from informal to formal specification – designer and customer try capture what the system is expected to provide can be expressed in natural of software language or more precise languages, such as a task Separation of layers is important at this stage analysis would provide • A layered approach to software development will • Architectural design provide for more flexibility –Data – High-level decisions on the technologies (both –Logic hardware and software) to be used – for example –Interface single user gui – to – web-based multi-user with • Implementation – writing the programs etc databases, middleware ….. etc
Testing The life cycle for real systems
RequirementsRequirements specificationspecification • Testing is not only about functionality cannot assume a linear of code ArchitecturalArchitectural sequence of activities designdesign as in the waterfall model • Usability testing DetailedDetailed – There are some basics that are nearly designdesign always important CodingCoding andand • Layout unitunit testingtesting • Language IntegrationIntegration • Number of click/steps to perform task andand testingtesting • Choose rather than remember lots of feedback and iteration! OperationOperation andand maintenance Iterative design and prototyping User centered approach • Iterative design overcomes inherent problems of incomplete requirements • Real users involved at each step of the process Users Needs – Find out about users before first and Goals requirements spec Requirements • Create personas and scenarios – Design and implement with users needs at the fore Review Design – Review (usability test) with users
Implement
Prototypes Techniques for prototyping • simulate or animate some features of intended system Storyboards – different types of prototypes need not be computer-based •throw-away can be animated • incremental Limited functionality simulations •Evolutionary some part of system functionality provided by designer • Really primitive initial prototypes are very “Wizard of Oz” technique powerful Warning about iterative design – Freeform demo design inertia – early bad decisions stay bad –Inkkitvideo diagnosing real usability problems in prototypes…. …. and not just the symptoms Research example Waterfall or Prototype
• We wanted to build a paperless • Waterfall • Prototype – Interaction paradigm – The interaction assignment grading product with pen ‘standard’ and well paradigm new or poorly annotation of assignments. understood? understood? – The problem is well – The problem definition – New paradigm understood? is incomplete or poorly –Few studies defined? – Interface centric – Technical challenges – Data centric systems • Information systems • Build a prototype systems •games • Data warehouse • Modelling • Design tools
Waterfall or prototype Summary
• It doesn’t have to be a one or the The type of software engineering other decision life cycle • Many systems are a blend – distinct activities and the – With some parts are prototyped to elicit consequences for system design requirements – regardless of life cycle consideration of user needs • There isn’t one ‘best way’ should be central • Nor is there a ‘silver bullet’