A Methodology for HMI Design

1. A Methodology forHMI Design

2. Overview 1. Mental Models2. Personas3. Scenarios4. Storyboarding5. Prototyping

3. Definition Methodology means: • a set or system of methods, principles, and rules for regulating a given discipline, as in the arts or sciences. • Education. a branch of pedagogics dealing with analysis and evaluation of subjects to be taught and of the methods of teaching them. (from http://dictionary.reference.com/browse/methodology)

4. Mental Models Alan Cooper presents three types of models:• Implementation Model: How it works• Mental Model: How the user thinks it works• Manifest Model: How the machine presents itself to the user[Alan Cooper, About Face: The Essentials of User Interface Design. 1995. IDG Books Worldwide. ISBN 1-56884-322-4. Chapter 3]Alan Cooper is also known as the father of VB.Watch Alan Cooper speaking about similarities between interaction design and agile programmers (2008): http://www.infoq.com/interviews/Interaction-Design-Alan-Cooper;jsessionid=444207C9CF4244422BA8738702B2E28A

5. Mental Models / Implementation Model The way the engineer must build the machine or software.Example:Keys are fabricated to be unique, butalso need to function correctly withrespect to the locking mechanism.The physics behind the lock (specifically, the various pins being activated by serrated edges of a key) illustrate the implementation model – technically, how things are really working.(illustration taken from The New Way ThingsWork by David Macaulay)

6. Mental Models / Implementation Model The way the engineer must build the machine or software.Example:Software is written in code; the engineer spends many years learning how to write “good code”.What is happening behind the scenes, inthat code, is the implementation model – technically, how things are really working.(Code taken from http://en.wikipedia.org/wiki/IOCCC) Guess what’s doing this code?

7. Mental Models / Mental Model The way the user thinks the machine or software works.For example:“I put my key in the lock and there is a big shape of the key inside; if the two match up, then it lets the knob turn.” For example: “I enter my username and password, and my computer talks to another computer which knows about my username and password, and if they match up, then it lets me continue.”

8. Mental Models / Manifest Model The way the machine presents itself to the user.For example:“Put your key here and turn”or“Go get various shaped really small wedges, and, one byone, stick them into the key hole; make sure to line up thewedges with the pins, so each pin contracts just enough;once you have all the pins contracted equally, turn all thewedges simultaneously until you can turn the knob; then,slowly remove the wedges one by one, letting the pins dropback into their expanded positions”

9. Mental Models / Manifest Model The way the machine presents itself to the user.For example:“Enter your name and password and press go”or“Enter your username and password; then, take yourpassword and compare it to this existing algorithm toencrypt it. Transfer the encrypted version of your passwordvia JDBC drivers to another server; if that server is busy,keep trying servers 1-100; when you find one that is free,log into the Oracle database and perform a query todetermine which user is accessing the system. Compare theencrypted password with the query results . . .”

10. Mental Models / Manifest Model • User Interfaces that conform to the implementation model are bad.• As a HMI designer, you have no control over the implementation model, and very little control over the mental model.However, you have almost complete control over the Manifest Model!• Your Challenge #1: Determine the user’s Mental Model(but remember – The User Is Not Like Me)• Your Challenge #2: Forget you’re a SW developer. When we ignore mental models, we often get stuck in a rut of “what’s been done before”.

11. Mental Models / Manifest Model (taken from Alan Cooper - About Face: The Essentials of User Interface Design)

12. .:: Exercise ::. Take five minutes and write down:• 3 examples of Manifest Models that are good (closely approximate the user’s Mental Model)• 3 examples of Manifest Models that are bad (closely approximate the engineer’s Implementation Model).

13. Personas An easy method to help us approximate the Mental Model is to create Personas of our users: “Develop a precise description of our user and what he wishes to accomplish” (Alan Cooper). precise : specific, detailed, verbose, in-depth user : a hypothetical individual, with concrete feelings, desires, skill levels and needs. wishes to accomplish : their work, goals, tasks

14. Personas / Why Use Them? • Personas become “real” – people can visualize and hypothesize about John Smith better than The User. • Personas help us understand varying skill levels. • Personas create a shared understanding of the end users – for the entire design team (including designers, marketing folk, engineers, executives, etc). • Personas emphasize that The User Is Not Like Me.

15. Personas / Aspects of a Successful Persona? • Specific • Hypothetical • Precise rather than Accurate • One per character (a project can have many Personas) • Use pictures!

16. .:: Exercise ::. • • Let’s come up with a Persona to help us design a new electronic toy for a 5-year old boy. • Where do they live? • What do they wear? • What kind of activities do they like? • What do they do on the spare time? • Do they have any computers in their house? .. How many?

17. Scenarios After we have developed our Personas, and we understand their Mental Models, we can create Scenarios: “A scenario is a concise description of a persona using a product to achieve a goal” (Alan Cooper). concise : short but complete; breadth instead of depth product : assume the product (software or physical device) exists, even if it doesn’t goal : the reason why we perform a task

18. Scenarios / Why Use Them? • Scenarios help us validate our design • Scenarios help us check our assumptions • Successful Scenarios help us transfer theoretical/conceptual design to “wire frame” design • Like Personas, Scenarios create a shared understanding of the end users – for the entire design team (including designers, marketing folk, engineers, executives, etc). • Like Personas, Scenarios emphasize that The User Is Not Like Me.

19. Scenarios / Writing Good Scenarios • Brainstorm, within the context of our problem domain, the goals our Personas will have • Write the Scenarios for a specific Persona • Go for breadth rather than depth – it is more important to describe things from start to finish rather than in exhaustive detail

20. .:: Exercise ::. • Considering our 5-years old boy Persona, what are the Scenarios they would go through while using the new electronic toy? • What are their goals? • What level of ability can we expect, based on their persona? • What steps would they go through to achieve their goals? • Can you start to imagine life without this new electronic toy for this Persona?

21. What Normally Happens … • We’ve collected data from real users and from competitive products • We’ve determined the Mental Models our users have by developing Personas • We have a good idea of the Scenarios of use that our users will attempt • It’s pretty tempting to go find a computer and start building something!

22. Put Down The Laptop! • No! Wait! Once we start using the computer (Photoshop, Coding, Alias)... • ... we stop thinking conceptually and start thinking pragmatically • ... we focus on the software tool’s constraints instead of the problem’s constraints • ... we pay attention to painstaking details (colors, font sizes, pixels) instead of overarching concepts (users, goals, needs)

23. Storyboarding / Overview • • Borrowed from the film/animation/comic industries • • One panel = One Scene • • Presented to a group of people • • Gauge their reactions, understanding • • Takes time up front, saves time later • (Go slow to go fast – an agile principle) • • Intended to visualize our scenarios • • Provide a mechanism to gracefully move from conceptual design to screen design • • Allow us to make mistakes early, in paper (cheap and quick), instead of later, in software (expensive and tedious)

24. Storyboarding / General Concepts • • Screens • • You are not designing the detailed interface yet • • Include general layout, navigation elements, core concepts • • Capture relevant information, remove extraneous information • • Scenes • • Personas in their physical context • • Cultural/Interpersonal relationships or handoffs • • Show sequencing of main ideas • • Although these can be quite visually attractive, they are not works of art: • • Black & white, pencil • • Quick • • No renderings!

25. Storyboarding / Tips Use your scenarios and personas! • Use long paper • Use one square per scene • Number each scene • Visually group similar scenes into conceptual tasks • Include a text description of each scene • Call out interesting or important aspects into the margins and annotate them

26. .:: Exercise ::. In groups of two or three, create storyboards for the following scenario: Ionut Popescu is going to update the songs on his MP3 player using his home computer. He’s exctied by some bands, like Rage Against the Machine and The Clash, that he just „discovered“. Start as Ionut enters his room at home; be sure to list your assumptions as you progress.

27. Prototyping / Overview • • A representation of the product • • Determining level of fidelity required is imperative! • • Iterative, so it’s hard to be “done”: • • Paper prototypes always come first. • • A progression and evolution of ideas and fidelity (level of finish)

28. Prototyping / A Progression / Paper • Quick • Portable • Easy to edit • Easy to annotate • Easy to copy • Can still focus on visualizing the concepts without being bogged down in the details • Sketches of main ideas, concepts, navigation paths • Important ideas are annotated for later reflection A progression

29. Prototyping / A Progression / Wireframe • Able to focus on navigation and composition while ignoring many other factors • Solidify concepts • Determine composition and layout • Identify navigation between pages as well as navigation on a specific page • Identify vocabulary used for main concepts; “greek” the rest of the content A progression

30. Prototyping / A Progression / Visual Elements • Focus attentions on intended emotional responses, giving the • interface human qualities • • Begin to add visual, emotional qualities (“womanly”, “childlike”, • “businesslike”) • • Refine font sizes, choices • • Refine vocabulary and content • Placement • • Solidify composition, navigation and layout A progression

31. Prototyping / A Progression / Style Refinement • Visually complete the interface to make it “sexy” • Add colors • Solidify vocabulary and content placement • Solidify font choices, visual style A progression

32. Prototyping / A Progression / A Cycle • But really, our progression is an iterative cycle. • It’s ok to go do more paper prototyping at any stage! Rule of thumb: You will become emotionally attached to your visual designs, and will be hesitant to change them – even when they are unusable! Push them off as long as you can! An interative cycle

33. Prototyping / Fidelity • Static vs. Dynamic • Level of “polish” • What is the purpose of the prototype?

34. Prototyping / Some Tricks • The photocopier is your friend • Spend as much time as possible on paper before moving to the computer • Scan your paper prototypes, add an Image Map in Dreamweaver, and get an instant clickthrough • Photoshop/Illustrator are great for wireframes – turn layers on/off as necessary • Powerpoint can also be used with “link hotspots” for a quick clickthrough

35. .:: Exercise ::. In groups of two or three, create prototypes for the following scenario: Prototype a tool that allows Ionut to update his MP3 player with music stored on his computer.

36. .:: Example ::. This methodology really works. See it applied : http://www.youtube.com/watch?v=nTemVD_xV7c http://www.youtube.com/watch?v=bQktEgZUGnY

37. References • Jon Kolko, http://www.jonkolko.com/projectFiles/scad/IACT315_03_MentalModelsPersonasScenarios.pdf • Jon Kolko, http://www.jonkolko.com/projectFiles/scad/IACT315_04_StoryboardingPrototyping.pdf • Alan Cooper, The Inmates are Running the Asylum: Why High Tech Products Drive us Crazy and How To Restore the Sanity. 1999. Sams. ISBN 0-67231-649-8. • Alan Cooper, About Face: The Essentials of User Interface Design. 1995. IDG Books Worldwide. ISBN 1-56884-322-4. Chapter 3. • Jakob Nielsen, et al, Usability Inspection Methods. 1994. John Wiley & Sons; ISBN 0-47101-877-5. Chapter 2. • Stuart K. Card & Thomas P. Moran, User Technology: From Pointing to Pondering. 1986. Reprinted in Human Computer Interaction: Towards the Year 2000; ISBN 1-55860-246-1. Page 587-602. • Jef Raskin. The Humane Interface: New Directions for Designing Interactive Systems. 2000. ACM Press. ISBN 0-201-37937-6.