1. D0107 Media Design and Integration Lecturer: Merja Bauters merjab@evtek.fi

2. Course Description Course: D0023/OJ/2000 Media Design and Integration (obligatory course) 3 credit weeks (points). Previous courses that should be completed: D0009 Visual Design Aim of the course: To understand the product process of different digital products from the user side namely to be able to understand the intertwined nature of technical software design process the user experience design process.

3. Course Description Design theories, cognitive, user-centred design (e.g., participatory), End-user development... Design methodologies (ethnographic, scenario-based, activity theory based) Some basic testing / evaluation methods of usability are introduced in the lifecycle of the product and practises made with this issue. The art and science of interface design will also be studied through examination of real case studies. Hands on practices related to the above Participation as end-users to test actual mock- ups/demos/products

4. Course Contents

5. Course Objectives After completing the course the student will understand the background for different methodologies for design and be able to choose and mix the appropriate ones for a particular product design Understand the design challenges Be able to see the need of testing as integrated to whole design process Integrate design of different elements into the product taking into account the context and the user as active actors Envision and judge the “hypes” in media design

6. How to pass the course Exam in the second period’s exam week. Labs every week. Activity during the course! (includes suggestion of visiting exhibitions etc, taking part in lecture discussions, providing idea for other topics....)

7. The Design Process - Objectives Software engineering provides a means of understanding the structure of the design process, and that process can be accessed for its effectiveness in interactive system design. Design rules in the form of standards and guidelines provide direction for design, in both general and more concrete terms, in order to enhance the interactive properties of the system. Usability engineering promotes the use of explicit criteria to judge success of a product in terms of its usability.

8. The Design Process – Introduction Software engineering addresses the management and technical issues of the development of software systems. Software life cycle describes the activities that take place from the initial concept formation for a software system up until its eventual phasing out and replacement. The issues from HCI affecting the usability of interactive systems are relevant within all the activities of the software life cycle.

9. The Software Life Cycle There are two parties in the development of a software product: Customer who requires the use of the product Designer who must provide the product Typically, the customer and the designer are groups of people and some people can be both customer and designer. It is important to distinguish between the customer who is the client of the designing company and the customer who is the eventual user of the system. (These roles can be played by different people.)

10. Activities in the Life Cycle Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Maintenance The analogy of the waterfall (in the next slide) is not completely faithful to the real relationship between these activities, but it provides a good starting point for discussing the logical flow of activity.

11. Waterfall Model Requirements Specification Architectural Design Detailed Design Coding and Unit Testing Integration and Testing Operation and Maintenance The activities in the waterfall model of the software life cycle

12. Interactive Systems and the Software Life Cycle - Iteration The traditional software life cycle does not promote the use of techniques which support the user’s perspective of the interactive system. (The purpose of validation and the formality gap.) No structured development process will entirely eliminate the formality gap, the particular techniques used can go a long way towards making validation of non-functional requirements feasible with expert assistance.

13. Project process/waterfall:iteration need of interaction between parties Guidelines Prototyping Design rules Standards Cyclical and iterative Involving users

14. Project process: cycle

15. Project Process- scenario based

16. Parties All parties involved in the product development cycle, including the executives (who must make decisions about strategic directions), the product managers (who must keep in constant communication with the customer community), and of course the development team, have a clear understanding of the business context where the product line lives. Thus, everyone is on the same page when discussing requirements, features, and product positioning. Furthermore, the development team finally has the means to achieve the customer orientation that is always asked of them. Having defined which parts of a process are common among all customers -- and which are implemented optionally -- also helps guide the prioritization of the product's features. Understanding the customer Understanding the users Conceptual design

17. Parties The process needed to implement the workload scheduling, including: what are the different activities how they are related who is responsible for each of them which artefacts are exchanged during the process The goals, set by the organization/institute etc, that the process supports. This includes understanding: what are the goals how each of them is measured who sets each goal

18. KP-Lab Design Approaches Anders Mørch, Anne Moen, Sten Ludvigsen InterMedia, University of Oslo KP-Lab WP2: Challenges, methodology, example Linz, April 20-21, 2006

19. Design techniques Scenario-based design Empirical-based design Participatory design Theory-based design Evolutionary design The techniques are partially overlapping and are often used in combination

20. Scenario-based design Simulation of future (envisioned) use A textual description with (or without) screen mock ups depicting an imagined sequence of interactions with a simulated system The context of the setting should be included in the description, so that the scenario is meaningful to as many as possible (see PD) Two types Generic (domain independent) Specific (domain specific)

21. Empirical-based design (also called iterative design, prototyping) Suggest answers to empirical questions Involving real users in order to support their needs, not primarily the needs of system developers Iterations of system building and evaluation with end users Evaluation is often done as testing in “usability labs”, but can also be done using other means (see PD)

22. Participatory design User participation in the early phases of system development Users are considered equal partners with developers at this stage Often referred to as “Scandinavian approach” to system development (stressing democratic design) Understand what goes on at a workplace and in interaction between workers and their tools Technology as “mediating artefact” alongside other artefacts, including profession-oriented languages Mutual learning and use of low-fidelity prototyping techniques (see SBD & EBD)

23. Theory-informed design Using theories to inform and ground a design Psychological theories in HCI have been used to create conceptual models and design principles, and this is often referred to as theory-based design The models or design principles can be used again and again to create designs When the theory (or theoretical idea) is taken all the way, we call it theory-informed design, in which the goal is to express a theory or idea in visual form, examples include Coordinator (speech act theory) Janus (reflection-in-action) FLE (progressive inquiry)

24. Evolutionary design Develop a new system based on existing system(s) This is often the default approach for many developers, even without being aware of it, because many developers have a repertoire of tools to build from Start from something that works, which is open to low level inspection and code reuse (API and/or source code) Find out what can be improved with the existing system and add the improvements to it Can be used in different ways within one system (e.g. extending a system into a new release); from one generation of system to another (e.g. product families); from one technology to another (mock up to computer display)

25. Example Integrating participatory design and evolutionary design, using scenarios and empirical-based design (LAP/Statoil case)

26. E-learning introduced with PD and evolutionary design techniques How can participatory design be useful for E-learning? Approach: Participatory design from beginning to end Users participated as designers in the beginning and as evaluators in the end

27. Mock-ups developed in Utopia project in the 1980s (early PD project) User interface in cardboard and paper Laser printer made from cardboard box

28. LAP project Learning and Knowledge Building at Work (LAP is the acronym in Norwegian) 3 year project among researchers and service industry companies in Norway (2001-2004) Goal: Introduce e-learning in two large corporations in Scandinavia (Statoil Detaljhandel and Visma Services) Empirical studies of the adoption process Analyze empirical and technical innovation

29. Statoil – The gas station division Goal: develop an e-learning system for gas station attendants and identify new learning opportunities to supplement traditional training The work at the gas stations is mostly manual labor; serving customers is the main task of the employees Young staff with average 12 months on the job Knowledge demand is high, ranging from how to prepare hot food to knowing the details about automobile products

30. Techniques employed Involving employees at multiple levels in a design workshop Intermediate abstractions: creating a smooth transition from user representations to software system Evolutionary design: transfer knowledge and code from one system to another in incremental steps

31. Design workshop Focus groups Learning scenarios Role playing Mock-ups Breakdown (constructive intervention)

32. Identifying work situations that can be improved (focus group)

33. Learning scenarios Create Collaborative design in groups of 4 Including station attendants and regional managers Half day session recorded on video Acting (demonstrated in 3 video clips) 1. Illustrate current work situation (and learn role playing technique) 2. Simulate a future situation that improves upon current work practice 3. Breakdowns and creative work-around (with drama instructor) to invent new ways of working and learning

34. Role playing situation

35. Mock-up information display created by one of the employee groups

36. Intermediate abstractions

37. Evolutionary design Transforming a mock- up to a computer prototype in multiple stages Intermediate abstractions aided the process, bridging informal and formal representations

38. Computer prototype v.1 First prototype crated by IT dept. in Statoil based on one of the intermediate abstractions Installed at pilot station for 3 months

39. Software prototype v.2 Using ColdFusion a Flash-like environment Vertical prototype of selected functionality

40. Third prototype: Laptop interface Third prototype has more functionality than its predecessors, but turned out to be less user friendly Company profile alignment became as important as local engagement Two-level grounding was accomplished: top-down (management) and bottom-up (user participation) System integrates well with the company ’ s advanced information and communication infrastructure Deployed at 25 gas stations as of 7/2004 Roll-out to more stations planned during 12/2004

41. Computer prototype v.3 Laptop located at the end of the counter, in- between two activities: Serving customers and back-office activities Lesser functionality than v.2, but better integration with company information infrastructure

42. Computer prototype v.4 (current) The system has been integrated as a separate screen in the cash register interface, early 2005 It has been deployed in 300 gas stations, some of them outside Norway We have not yet made any follow-up study of use Based on my own inquires at local stations it seems use is sporadic and for other purposes that was intended, no new practices has emerged A reported problem is that it interferes with the operation of the cash register, i.e “risky” to use Found that the co-existence of multiple generations of technologies for information finding works fine

43. Lessons learned Importance of interacting multiple design techniques Transformation from informal (user oriented) representations to software systems To generalise: Multiplicity and cross- disciplinary transformation and integration

44. Horizontal/vertical integration Technology Activity Social practice Hardware – tech. infrastructure Software - Interaction through shared objects about authentic issues Interaction and transformation Middle ware Infrastructure Tools and services Applications Design doc. Ontologies Specification Standards Examples

45. Week 37 (10.9) Opening of the deliverables needed in the process Background on scenario-based theory User-centres (EUD) Reading related today’s lecture: Cognitive theories: Norman, D.A. (1988) The psychology of everyday things. Basic Books. http://www.jnd.org/ Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S. & Carey, T. (1994) Humancomputer interaction. Addison-Wesley. Ben Shneiderman: http://www.cs.umd.edu/~ben/http://www.cs.umd.edu/~ben/ Jef Raskin: http://jef.raskincenter.org/home/index.html http://jef.raskincenter.org/home/index.html Sinkkonen, Irmeli, Kuoppala, Hannu, Parkkinen, Jarmo, Vastamäki, Raino: Psuchology of usability. IT Press (2006). Agile development http://www.versionone.net/Resources/AgileDevelopment.asp