Design of Everyday Things, Intro to User Research, Project Pitches and Brainstorming

1. Design of Everyday Things, Intro to User Research,Project Pitches and Brainstorming CS 5115 Fall 2012 September 12

2. Agenda for today • Course status update • Review project schedule • Finish Design of Everyday Things • Intro to User Research • Project pitches and brainstorming

3. Standardization • Fewer things to memorize • Quicker to learn • Clocks should run clockwise • But note that standards are culture-dependent!

4. “Standards” and cultures • What does the color red mean? • US – danger, warning, … • India – purity • What color should a wedding dress be? • US – white • India – red & yellow • How do you turn on a faucet? • US – counter-clockwise • UK – clockwise • Icons – mailboxes, trashcans, …

5. Standards and Intellectual Property • Uh oh

6. From Principles to Checklist

7. Design Checklist • Conceptual Models • What is the user’s model of the application? • How will the user get a correct model?

8. Design Checklist • Affordances • Do interface objects afford their operations? • Do interface objects afford illegal operations? • Is it easy to tell what can be done with objects?

9. Design Checklist • Visibility of Controls • Are all controls clearly visible on the screen or in menus? • Can users easily distinguish one control from another? • Is it easy to tell how to do something? • Are there critical parameters hidden away?

10. Design Checklist • Feedback • Does every input provide appropriate feedback? • Is it easy to determine the effect after an operation?

11. Design Checklist • Mappings • Are there clear correspondences between controls and their objects? • Is graphical layout exploited (horizontal,vertical)?

12. Design Checklist • Constraints • Does the application constrain the user to legal operations? • Do constraints help the user simplify the problem?

13. Design Checklist • Knowledge in the World • Is the user expected to remember many things? • Is the user expected to remember things from screen to screen? • Is relevant information kept on the screen?

14. Design Checklist • Error Avoidance/Handling • Is there an undo operation? Multi-level undo? • Are irreversible actions harder to perform? • Do forcing functions prevent errors?

15. Design Checklist • Standardization • When making choices, does the application follow existing standards? • Is there a standard look-and-feel? • Was the application built using a standard set of tools?

16. User Research • Mathis, Chapters 1 and 2

17. Learning / Goals • What people are doing now • What people don’t like to do / find hard to do • What people would like to do • Make what they’re doing easier/faster • Make these things obsolete (or fun) • Make it possible for users to do these things

18. How? • Ask

19. How? • Ask – Why this isn’t enough • People may not be able to identify their problems • People are not good at coming up with solutions • People are really bad at predicting whether and how they’d use a new product

20. How? • Ask • Watch • Listen • Dialog

21. Some terms • Interviews • Focus Groups • Surveys • Job Shadowing • Contextual Interviews • Ethnography

22. You need real users You may think your idea for a new system is so wonderful that everyone will want it, though you can’t think of a really specific example, and that it will be useful in some way to people, even though you can’t say how. But history suggests that you will be wrong. (Lewis and Rieman, Chapter 2)‏

23. Project Pitches