INF385P – Intro to Usability

1. INF385P – Intro to Usability Week 3 – Usability Life Cycle

2. Course web site . . . • http://courses.ischool.utexas.edu/Bias_Randolph/2011/Spring/385P/index.html • Thanks, Jessica.

3. Design of Everyday Things • It ain’t rocket science. • You’ve already read the book. • Let me hit just the high points from my point of view • While I’m presenting this, see if you can characterize your good and bad web designs that you’ve discovered this week in Norman’s terms.

4. Chapter 1 • The PsychoPATHOLOGY of everyday things • Assumption: We blame ourselves for errors, but the real culprit is faulty design. • Assumption: There’s nothing special about computers. They have the same sorts of design problems as simpler, everyday things.

5. Good Design • Well designed objects . . . • are easy for the mind to understand • contain visible cues to their operation • Poorly designed objects . . . • provide no clues, or • provide false clues.

6. Natural Signals • Natural signals lead to natural design. • A metal plate “naturally” is to be pushed. • Visible hinges “naturally” indicate attachment, and that the other side swings open. (And swings open TOWARD me?)

7. Mapping • Mapping is a relationship between two things (e.g., between what you want to do and what is possible). • Good design allows for a clear (visible) mapping between . . . • intended actions and • actual operations. • Now -- think of what this might mean in a web site.

8. Good Design • Principles of good design • the importance of visibility • appropriate clues • feedback of ones actions. • Just so you’ll know -- others have proposed OTHER principles of good design. Go check out the web site of Bruce Tognazzini: http://www.asktog.com/basics/firstPrinciples.html

9. Affordance • Affordance is the perceived and actual properties of a thing. • Primarily those fundamental properties that determine how a thing could possibly be used. • “Affords” means, basically, “is for.” • A chair affords support, therefore affords sitting. • Affordances provide strong clues to things’ operations. • When affordances are taken advantage of, the user knows what to do just by looking. • No label, picture, or instruction (“Push”) is required. • When simple things need pictures, labels, or instructions, the design has failed.

10. The Paradox of Technology • Added functionality generally comes along at the price of added complexity. • The same technology that simplifies life by providing more functions also complicates life by making the device harder to learn and use. • The Paradox of Technology should never be used as an excuse for poor design. • Added complexity cannot be avoided when functions are added, but with clever design they can be minimized.

11. Chapter 2 -- Psy of Everyday Actions • Norman’s credo on errors -- if an error is possible, someone will make it. • The designer must design so as to: • minimize the chance of errors in the first place • minimize the effects of an error • make errors easy to detect • make errors reversible, if possible.

12. Models • Mental Models = our conceptual models of the way . . . • objects work • events take place • people behave • Mental models result from our tendency to form explanation of things. • Models are essential in helping us . . . • understand our experiences • predict the outcomes of our actions • handle unexpected occurrences.

13. Models (cont’d.) • We base our models on whatever knowledge we have: • real or imaginary • naïve or sophisticated • even fragmentary evidence. • Everyone forms theories (mental models) to explain what they have observed. • In the absence of feedback to the contrary, people are free to let their imaginations run free. • More on models in Chapter 3.

14. 7 Stages of Action • On p. 47 is a series of four figures that illustrate Norman’s view of the structure of action. • Actions have two major aspects: • Doing something (execution) • Checking (evaluation)

15. Chapter 3 - Knowledge in the Head and in the World • Not all knowledge required for precise behavior must be in the head. It can be distributed: • partly in the head • partly in the world • partly in the constraints of the world.

16. Constraints • The power of constraints -- the “memory” for epic poetry is found to be mostly reconstruction, with the aid of the constraints of rhyme, meter, etc. • We use constraints to simplify what we must remember. • For example, putting mechanical parts together. • Some are constrained by what will and will not fit together. • Also cultural constraints -- screws tighten clockwise.

17. Memory • . . . is knowledge in the head. • Think of all you can remember. Phone numbers, postal codes, passwords, SSN, birthdays, etc., etc. • It’s tough! • So, we put memory in the world. (Daytimers. Smartphones. Address books. Stickies.)

18. Tradeoff . . . • . . . between info in the world and in the head. • Knowledge in the world acts as its own reminder. • Knowledge in the head is efficient. (You can travel light.) • Knowledge in the world is easier (no learn time), but often difficult to use. Relies heavily on the physical presence of info. • See Fig. 3.6, p. 79.

19. Ch. 4 -- Knowing what to do • When we encounter a novel object, either • We’ve dealt with something similar before, and we transfer old knowledge, or • We get instruction. • Thus, information in the head.

20. Design • How can the design of an object (NOTE: info in the world) signal the appropriate actions? • Natural (physical) constraints • Affordances, that convey messages about the item’s possible uses, actions, and functions • “The thoughtful uses of affordances and constraints together in design lets a user determine readily the proper course of action even in a novel situation.”

21. Ch. 5 - To err is human • Errors come in several forms • Slips -- result from automatic behavior, when subconscious actions get waylaid en route (“performance errors”) • Mistakes -- result from conscious deliberations (“competence errors”)

22. Ch. 6 -- The Design Challenge • Norman talks about what forces work against evolutionary, or natural design (pp. 142-143). • The demands of time (quick product cycles) • The pressure to be distinctive (related to the curse of individuality)

23. Pitfalls • Three reasons why designers go astray: • Putting aesthetics first • Designers aren’t typical users • Designers’ clients may not be the users

24. Ch. 7 - UCD • Chapter 7 is the “punch line” of the whole book. • User-Centered Design • Most of the chapter is given over to describing “seven principles for transforming difficult tasks into simple ones.”

25. Etc. • He goes on to offer a section on why you might want to design something to be hard to use ON PURPOSE. • And he ends with a few sections on writing, the home of the future, and a concluding section.

26. Now . . . • Let’s try to put it in Norman’s terms why the good designs were good and the bad designs were bad. (“Some important feature was, or was not, visible.”)

27. Homework – Now remember, WHY are we looking at these? For the yucks? http://courses.ischool.utexas.edu/Bias_Randolph/2011/Spring/385P/design_examples.html

28. General, kinda, process flow • Someone has an idea for a product/site. • Maybe there was a problem that needs to be fixed, or an identified efficiency • Gotta figure out WHAT to build – Gather user requirements • Build something – Scientific underpinnings, Design support • Don’t be satisified with the first design – employ iterative design approach -- Evaluation • Don’t just thrown your findings “over the transom” -- Advocacy

29. User Profiles • Or “personas.” • From www.uxmatters.com: “In the UX world, we know the value of personas. Personas do all of this for us: • They lend a personal face to our user population. • They provide guidance for design. • They help us understand who it is we are designing for. • They fill in for users when you can’t—or it isn’t practical to—talk to them.

30. Some resources • http://www.uxmatters.com/mt/archives/2009/09/whats-my-persona-developing-a-deep-and-dimensioned-character.php • Building A Data-backed Persona by Andrea Wiggins, boxesandarrows.com • http://www.boxesandarrows.com/view/building-a-data • Getting Started with Building Personas by Howard Kaplan, FutureNow Inc. • http://www.futurenowinc.com/resources/FutureNow_Getting_Started_with_Building_Personas.pdf

31. Not just demographics • BUT ALSO • Knowledge • Interests • Goals • Activities • Expectations • Influencers • Frustrations • Pain points

32. Checklist for creating personas From “Personas: Focusing on getting the design right – Part 1” by: Fiona Meighan http://www.apogeehk.com/articles/Personas_Focusing_on_getting_the_design_right_Part1.html • Find out about user goals through interviews and observing real end users • Ensure personas are created based on primary data you've collected • Ensure personas are specific • Include the key user goals only • Ensure each persona has a name, age, family and occupation. • The persona data should provide enough information for decisions to be made and feature creep to be avoided. • Design for a primary persona and possibly a secondary persona. The goal is to narrow down who your team is designing for

33. General resources • http://courses.ischool.utexas.edu/Bias_Randolph/2010/Fall/INF385P/index.html • www.useit.com • http://www.usability.gov/ • http://www.upassoc.org/ and http://www.upassoc.org/usability_resources/index.html • http://www.stcsig.org/usability/ • http://www.hfes.org/web/Default.aspx • http://www.sigchi.org/ • http://hcibib.org/ • You’ll find others!

34. Class wiki (template) . . . • http://courses.ischool.utexas.edu/rbias/wiki/ • Username: seven • Password: plusorminustwo

35. Let’s do some work on the wiki • Pick one of these general categories • Go look at what’s already up there. THAT’S NOT ENOUGH. • See what else you might find to add. • Check out DocuWiki guide for help with how to add info. • Scientific Underpinnings • Requirements Gathering • Design support • Evaluation • Advocacy/Business

36. So, my vision . . . • Over the next 3 or 4 or 5 weeks you wiki “teams” will: • Find all sorts of pertinent resources, link to them from our wiki • Incorporate book reviews and white papers as appropriate • Come up with some design-a-rama for the wiki – maybe some visuals, some IA • At some point we’ll “go live” – ooh, first perhaps one team of two will do as their final project a usability evaluation of the usability wiki!

37. For next week • Send me your white paper topics. Due 4 weeks from today. • Book reviews due in 2 weeks. • More reading per syllabus. • Usability test plan (for your final project) due in 6 weeks. Will help with pointers to templates.