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

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

Post on 22-Dec-2015




3 download

Embed Size (px)


<ul><li> Slide 1 </li> <li> Review Intro- HCI / Interaction Design History of HCI Design Life Cycle Bin-IT case study Design Principals Don Norman User Centered Design Evaluation - Assignment </li> <li> Slide 2 </li> <li> Designing from Scratch </li> <li> Slide 3 </li> <li> 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. </li> <li> Slide 4 </li> <li> 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? </li> <li> Slide 5 </li> <li> 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? </li> <li> Slide 6 </li> <li> Trade-offs Choosing which goals and constraints can be relaxed so that others are meet. </li> <li> Slide 7 </li> <li> 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.. </li> <li> Slide 8 </li> <li> How to establish the Goals and Constraints. Observe, talk to, interview, collaborate with, involve, ASK, THE END USER. </li> <li> Slide 9 </li> <li> 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 competitors 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 </li> <li> Slide 10 </li> <li> Rem tutorial question, who are the Stakeholders at a club??? </li> <li> Slide 11 </li> <li> 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 childs toy requires little strength to operate, but greater strength to change batteries disabilities (e.g. sight, hearing, dexterity) </li> <li> Slide 12 </li> <li> How to establish the Goals and Constraints. Observe, talk to, interview, collaborate with, involve, ASK, THE END USER. </li> <li> Slide 13 </li> <li> This can be difficult.. Users rarely know what is possible Users cant 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? </li> <li> Slide 14 </li> <li> Rem observation interviews questionaires focus groups Also. Use tools to help get the information </li> <li> Slide 15 </li> <li> Slide 16 </li> <li> Slide 17 </li> <li> Slide 18 </li> <li> RCA Cultural Probs ref. William Gaver </li> <li> Slide 19 </li> <li> 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. </li> <li> Slide 20 </li> <li> Evaluate (Re)Design Prototype Identify needs/ establishrequirements Final product </li> <li> Slide 21 </li> <li> 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 </li> <li> Slide 22 </li> <li> 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 </li> <li> Slide 23 </li> <li> Facing Problems Political problems within the organisation Dominance of certain stakeholders Economic and business environment changes Balancing functional and usability demands Identify needs/ establishrequirements </li> <li> Slide 24 </li> <li> 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 </li> <li> Slide 25 </li> <li> 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 youd really like Consider carefully how to record the data Identify needs/ establishrequirements </li> <li> Slide 26 </li> <li> Data Interpretation and Analysis Start soon after data gathering session Initial interpretation before deeper analysis Identify needs/ establishrequirements </li> <li> Slide 27 </li> <li> 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 </li> <li> Slide 28 </li> <li> 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 peoples 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 </li> <li> Slide 29 </li> <li> 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 </li> <li> Slide 30 </li> <li> 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 </li> <li> Slide 31 </li> <li> Example use case diagram for shared calendar Identify needs/ establishrequirements </li> <li> Slide 32 </li> <li> arrangeMeeting USER INTENTION SYSTEM RESPONSIBILITY arrange a meeting request meeting attendees &amp; constraints identify meeting attendees &amp; constraints search calendars for suitable dates suggest potential dates choose preferred date book meeting </li> <li> Slide 33 </li> <li> 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 </li> <li> Slide 34 </li> <li> 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 </li> <li> Slide 35 </li> <li> 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 </li> <li> Slide 36 </li> <li> 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 isnt 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 Graphical HTA </li> <li> Slide 37 </li> <li> 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 </li> <li> Slide 38 </li> <li> (Re)Design Prototype Evaluate (Re)Design Prototype Identify needs/ establishrequirements Final product </li> <li> Slide 39 </li> <li> Prototyping (Re)Design Prototype </li> <li> Slide 40 </li> <li> 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 </li> <li> Slide 41 </li> <li> (Re)Design Prototype </li> <li> Slide 42 </li> <li> (Re)Design Prototype </li> <li> Slide 43 </li> <li> 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 </li> <li> Slide 44 </li> <li> (Re)Design Prototype </li> <li> Slide 45 </li> <li> 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 </li> <li> Slide 46 </li> <li> LOW FIDELITY PROTOTYPES Form simple, normally pencil and paper non-functional (Re)Design Prototype </li> <li> Slide 47 </li> <li> LOW FIDELITY PROTOTYPES Use design team can reason about the design can be presented to sample users, although require a facilitator (Re)Design Prototype </li> <li> Slide 48 </li> <li> 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 </li> <li> Slide 49 </li> <li> 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 </li> <li> Slide 50 </li> <li> 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 </li> <li> Slide 51 </li> <li> 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 </li> <li> Slide 52 </li> <li> now you could choose to return to the storyboard and provide some detail (Re)Design Prototype </li> <li> Slide 53 </li> <li> 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 </li> <li> Slide 54 </li> <li> 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 </li> <li> Slide 55 </li> <li> Low fidelity prototypes.more Low fidelity prototyes can be simply stories that explain how a user interacts with an imaginary interfacein narrative form. Called Scenario-Based Design (Re)Design Prototype </li> <li> Slide 56 </li> <li> Low fidelity prototypes Low fidelity prototypes can be used in co-design sessions with end users to extract requirements.. (Re)Design Prototype </li> <li> Slide 57 </li> <li> 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 </li> <li> Slide 58 </li> <li> Medium fidelity prototypes Wizard of Oz prototyping is a useful prototyping technique (Re)Design Prototype </li> <li> Slide 59 </li>...</ul>