1. Review Intro- HCI / Interaction Design History of HCI Design Life Cycle – Bin-IT case study Design Principals – Don Norman User Centered Design Evaluation - Assignment

2. Designing from Scratch

3. What is Design? Simply put, its Achieving Goals within Constraints It is your job to figure out what the goals are, and what the constraints are….

4. Imagine you want to build a wireless personal DVD player… Goals Who is it for? Why do they want it? What is it for? Where will they use it? When will they use it?

5. Imagine you want to build a wireless personal DVD player… Constraints How does user interact with it? What materials are used? What standards must be adopted? Do we need to build in copyright protection?

6. Trade-offs Choosing which goals and constraints can be relaxed so that others are meet.

7. eg Sharing the view of the DVD on the monitor is a goal…… Eye mounted display is the most stable while walking, stability is a constraint…… You might decide that sharing is a priority, while walking around busy streets watching video might be too distracting to be safe..

8. How to establish the Goals and Constraints. Observe, talk to, interview, collaborate with, involve, ASK, THE END USER.

9. Who are the USERS / STAKEHOLDERS Not as obvious as you think: — those who interact directly with the product — those who manage direct users — those who receive output from the product — those who make the purchasing decision — those who use competitor’s products Three categories of user — primary: frequent hands-on — secondary: occasional or via someone else — tertiary: affected by its introduction, or will influence its purchase

10. Rem tutorial question, who are the ‘Stakeholders’ at a club???

11. Humans vary in many dimensions: — size of hands may affect the size and positioning of input buttons — motor abilities may affect the suitability of certain input and output devices — height if designing a physical kiosk — strength - a child’s toy requires little strength to operate, but greater strength to change batteries — disabilities (e.g. sight, hearing, dexterity)

12. How to establish the Goals and Constraints. Observe, talk to, interview, collaborate with, involve, ASK, THE END USER.

13. This can be difficult.. Users rarely know what is possible Users can’t tell you what they ‘need’ to help them achieve their goals Instead, study/observe existing tasks: –their context –what information do they require? –who collaborates to achieve the task? –why is the task achieved the way it is?

14. Rem – observation interviews questionaires focus groups Also…. Use tools to help get the information

18. RCA Cultural Probs ref. William Gaver

19. A research team matches the appropriate methods for gathering user information with, the people they are designing for the environment/context they are designing for and the product they are designing.

20. Evaluate (Re)Design Prototype Identify needs/ establishrequirements Final product

21. Data Gathering Facing Problems Identifying and involving stakeholders: users, managers, developers, customer reps?, union reps?, shareholders? Involving stakeholders: workshops, interviews, workplace studies, co-op stakeholders onto the development team ‘Real’ users, not managers: traditionally a problem in software engineering, but better now Identify needs/ establishrequirements

22. Facing Problems Requirements management: version control, ownership Communication between parties: —within development team —with customer/user —between users… different parts of an organisation use different terminology Domain knowledge distributed and implicit: —difficult to dig up and understand —knowledge articulation: how do you walk? Availability of key people Identify needs/ establishrequirements

23. Facing Problems Political problems within the organisation Dominance of certain stakeholders Economic and business environment changes Balancing functional and usability demands Identify needs/ establishrequirements

24. Some basic guidelines Focus on identifying the stakeholders’ needs Involve all the stakeholder groups Involve more than one representative from each stakeholder group Use a combination of data gathering techniques Identify needs/ establishrequirements

25. Some Basic Guidelines Support the process with props such as prototypes and task descriptions Run a pilot session You will need to compromise on the data you collect and the analysis to be done, but before you can make sensible compromises, you need to know what you’d really like Consider carefully how to record the data Identify needs/ establishrequirements

26. Data Interpretation and Analysis Start soon after data gathering session Initial interpretation before deeper analysis Identify needs/ establishrequirements

27. Task descriptions Scenarios an informal narrative story, simple, ‘natural’, personal, not generalisable Use cases —assumes interaction with a system —assumes detailed understanding of the interaction Essential use cases —abstract away from the details —does not have the same assumptions as use cases Identify needs/ establishrequirements

28. Scenario for Shared Calender “ The user types in all the names of the meeting participants together with some constraints such as the length of the meeting, roughly when the meeting needs to take place, and possibly where it needs to take place. The system then checks against the individuals’ calendars and the central departmental calendar and presents the user with a series of dates on which everyone is free all at the same time. Then the meeting could be confirmed and written into people’s calendars. Some people, though, will want to be asked before the calendar entry is made. Perhaps the system could email them automatically and ask that it be confirmed before it is written in.” Identify needs/ establishrequirements

29. Use case for a Shared Calendar 1. The user chooses the option to arrange a meeting. 2. The system prompts user for the names of attendees. 3. The user types in a list of names. 4. The system checks that the list is valid. 5. The system prompts the user for meeting constraints. 6. The user types in meeting constraints. 7. The system searches the calendars for a date that satisfies the constraints. 8. The system displays a list of potential dates. 9. The user chooses one of the dates. 10. The system writes the meeting into the calendar. 11. The system emails all the meeting participants informing them of them appointment Identify needs/ establishrequirements

30. Some alternative courses: 5.If the list of people is invalid, 5.1The system displays an error message. 5.2The system returns to step 2. 8.If no potential dates are found, 8.1 The system displays a suitable message. 8.2 The system returns to step 5. Identify needs/ establishrequirements

31. Example use case diagram for shared calendar Identify needs/ establishrequirements

32. arrangeMeeting USER INTENTION SYSTEM RESPONSIBILITY arrange a meeting request meeting attendees & constraints identify meeting attendees & constraints search calendars for suitable dates suggest potential dates choose preferred date book meeting

33. Task Analysis Task descriptions are often used to envision new systems or devices Task analysis is used mainly to investigate an existing situation It is important not to focus on superficial activities What are people trying to achieve? Why are they trying to achieve it? How are they going about it? Many techniques, the most popular is Hierarchical Task Analysis (HTA) Identify needs/ establishrequirements

34. HTA Involves breaking a task down into subtasks, then sub-sub-tasks and so on. These are grouped as plans which specify how the tasks might be performed in practice HTA focuses on physical and observable actions, and includes looking at actions not related to software or an interaction device Start with a user goal which is examined and the main tasks for achieving it are identified Tasks are sub-divided into sub-tasks Identify needs/ establishrequirements

35. HTA example 0.In order to borrow a book from the library 1.go to the library 2.find the required book 2.1 access library catalogue 2.2 access the search screen 2.3 enter search criteria 2.4 identify required book 2.5 note location 3.go to correct shelf and retrieve book 4.take book to checkout counter Identify needs/ establishrequirements

36. Borrow a book from the library go to the library find required book retrieve book from shelf take book to counter 3214 0 access catalog access search screen enter search criteria identify required book note location plan 0: do 1-3-4. If book isn’t on the shelf expected, do 2-3-4. plan 2: do 2.1-2.4-2.5. If book not identified from information available, do 2.2-2.3-2.4-2.5 2.12.22.32.42.5 Graphical HTA

37. SUMMARY Getting requirements right is crucial There are different kinds of requirement, each is significant for interaction design The most commonly-used techniques for data gathering are: questionnaires, interviews, focus groups and workshops, naturalistic observation, studying documentation Scenarios, use cases and essential use cases can be used to articulate existing and envisioned work practices. Task analysis techniques such as HTA help to investigate existing systems and practices Identify needs/ establishrequirements

38. (Re)Design Prototype Evaluate (Re)Design Prototype Identify needs/ establishrequirements Final product

39. Prototyping (Re)Design Prototype

40. Write a Design Brief using the requirements established… -Who? -Why? -What? -Where? -When? -How? A design breif will state the goals, the constraints and the trade-offs… (Re)Design Prototype

41. (Re)Design Prototype

42. (Re)Design Prototype

43. – we did not have to consider the actual iron or, fork to see the design flaws, we only considered pictures of them – prototyping is concerned with the design process leading up to production of the final system – our prototypes are not the final system, but representations of it – we talk about the fidelity of user interface prototypes The low fidelity - high fidelity continuum… (Re)Design Prototype Why Prototype

44. (Re)Design Prototype

45. LOW FIDELITY PROTOTYPES Purpose depict concepts present design alternatives suggest screen layouts/interface affordances enable rapid development and revision of designs demonstrate general look and feel of UI/object iron out usability issues as early as possible (Re)Design Prototype

46. LOW FIDELITY PROTOTYPES Form simple, normally pencil and paper non-functional (Re)Design Prototype

47. LOW FIDELITY PROTOTYPES Use design team can reason about the design can be presented to sample users, although require a facilitator (Re)Design Prototype

48. LOW FIDELITY PROTOTYPES – storyboards present sequences of activity in the interface – they indicate the flow from one state or screen to the next – to begin with they may not include much detail of the interface (Re)Design Prototype

49. – this example gives an overview of the layout without any detail - a good starting point – numerous alternatives can be quickly created without worrying about details – should be produced in pencil (easily changed) – should be hand-drawn (rulers take too much effort) (Re)Design Prototype

50. – it might be tempting to draw more 'tidy' pictures like this example – but it's difficult to change, even if in a drawing package – and there is no benefit over the hand- drawn sketches – it is highly unlikely that the first (or 2nd, 3rd or 4th) designs will be completely correct – but if they are hard to amend, they won't be amended (Re)Design Prototype

51. – once you are happy with your overview of the layout – (for multiple windows/dialogues) if necessary – you can start to focus on details of the design – such as example data values, menu content, buttons, labels etc – and more specific arrangement of interface objects (Re)Design Prototype

52. – now you could choose to return to the storyboard and provide some detail (Re)Design Prototype

53. – once you are happy with those details you can create your interface 'toolkit' – by cutting out each of the components into its own 'window' – e.g. windows, dialogues, menus etc – these can be used to dynamically simulate the interface – following the storyboard – perhaps with users in an evaluation (Re)Design Prototype

54. Advantages low development cost can evaluate multiple design concepts quickly useful communication device good for considering screen layout issues and user navigation through the interface Disadvantages not detailed enough to implement from need to be facilitated when presented to users do not address issues that arise from implementation (Re)Design Prototype

55. Low fidelity prototypes….more Low fidelity prototyes can be simply stories that explain how a user interacts with an imaginary interface…in narrative form. Called ‘Scenario-Based Design’ (Re)Design Prototype

56. Low fidelity prototypes Low fidelity prototypes can be used in co-design sessions with end users to extract requirements….. (Re)Design Prototype

57. Medium fidelity prototypes – provide a development path from the 'rough' low- fidelity prototypes – can provide more sophisticated simulations for users to try out – normally only for some of the system's features that need particular attention Disadvantages users need to realise that they aren't the final versions …to get correct level of critique can set focus on small details rather than larger flaws (Re)Design Prototype

58. Medium fidelity prototypes – Wizard of Oz prototyping is a useful prototyping technique (Re)Design Prototype

59. Medium fidelity prototypes Video Prototyping… (Re)Design Prototype

60. Medium fidelity prototypes (Re)Design Prototype

61. (Re)Design Prototype IDEO TECH BOX Library, database, website - all-in-one Contains physical gizmos for inspiration

62. IDEO TECH BOX (Re)Design Prototype

63. (Re)Design Prototype

64. High fidelity prototypes – have functionality and are interactive – may be programmed (e.g. Visual Basic) or created in a tool such as Macromedia Director Advantages user-driven provide look and feel can be used as a specification for final implementation Disadvantages expensive and time-consuming to develop not good for gathering requirements or for proof-of-concept designs (Re)Design Prototype

65. So at what point do you build prototypes? (Re)Design Prototype

66. How to choose which Prototype Evaluation with users or with peers, e.g. prototypes Technical feasibility: some not possible Quality thresholds: Usability goals lead to usability criteria set early on and check regularly —safety: how safe? —utility: which functions are superfluous? —effectiveness: appropriate support? task coverage, information available —efficiency: performance measurements (Re)Design Prototype

67. Evaluate (Re)Design Prototype Identify needs/ establishrequirements Final product

68. (Re)Design Prototype

69. (Re)Design Prototype

70. (Re)Design Prototype

71. (Re)Design Prototype

72. (Re)Design Prototype

73. (Re)Design Prototype

74. (Re)Design Prototype