SIMS 213: User Interface Design & Development

1. SIMS 213: User Interface Design & Development Marti Hearst Tues, Feb 1, 2005

2. Today • Finish Task Analysis example • Personas

3. Task Analysis • Characterize what happens when users perform typical tasks • Tools: • table of user communities vs. tasks • Who x What • table of task sequences • flowchart or transition diagram • videotape depicting scenario Slide adapted from Ben Shneiderman

4. User-centered Design Example Interview Questions & Summary Results

5. How Often Do Users Perform the Tasks? • Frequent users remember more details • Infrequent users may need more prompting • Which function is performed • most frequently? • by which users? • optimize system for tasks that will improve perception of its performance Slide adapted from James Landay's

6. User-Centered Design Example Task Analysis Table

7. User-Centered Design Example Task Analysis Table

8. Augment Table with Percentages(What percentage of the is this task done by this person)(Numbers are only suggestive, adapted from Shneiderman 98)

9. User-Centered Design Example • The next step: • Use Task Matrix to Create Scenarios • Scenarios indicate the sequence of steps the personas go through to complete certain tasks • A more recent development • First create Personas • Use these to create Scenarios

10. Cooper on Designing for Goals • We do tasks to achieve goals – don’t equate them! • Traveling safely in 1849 vs. 1999 • Goal of good design: help users achieve practical goals while not violating their personal goals • No “unnatural acts” • Distinctions: • Personal goals • Corporate goals • Practical goals • False goals • Example: goal-directed tv news system

11. Think Outside-in versus Inside-out • Do not expect others to think or behave • as you do • as you would like them to • Assess the meaning of the displays and controls based on what a user can be assumed to know, not based on what you know

12. Example: Playing Pictionary Getting into someone else’s head

13. Observation (from Cooper) • Being a victim of a problem does not necessarily bestow the power to see the solution • An individual is not always representative • Company president example

14. Personas (from Cooper) • “Hypothetical Archetypes” • Archetype: (American Heritage) • An original model or type after which other similar things are patterned; a prototype • An ideal example of a type; quintessence • A precise description of a user and what they want to accomplish • Imaginary, but precise • Specific, but stereotyped • Real people have non-representative quirks

15. The Essence of Personas • Describe a person in terms of their • Goals in life (especially relating to this project) • Capabilities, inclinations, and background • People have a “visceral” ability to generalize about real and fictional people • We can have detailed discussions about what Harry Potter, Scarlett O’Hara, or Colin Powell will think or do. • They won’t be 100% accurate, but it feels natural to think about people this way

16. Reasons for Personas • A compromise design pleases no-one • The broader you aim, the more likely you miss the bulls-eye • 50% of the people 50% happy doesn’t work • Car example – soccer mom, carpenter, dot-com exec • “Every time you extend functionality to include another constituency, you put another speed bump of features and controls across every other user’s road.” • A targeted design can achieve • 10% people 100% ecstatic • Examples: • Ram pickup truck • Sony aibo • There is no such thing as an average user

17. Reasons for Personas Examples of results of targeted design • Dodge Ram pickup • Roller suitcases • Sony Aibo • Isn’t useful for anything • Not fuzzy and warm • Too delicate to let children use it, but • Passionate fan clubs • Brisk sales despite steep price – and prices now coming down

18. Reasons for Personas • Avoid the “elastic user” • If the description is not specific, it can easily wiggle to suit the design needs of the moment Piston analogy • Helps prevent designer / programmer from imagining they are the user Image from www.howstuffworks.com

19. Reasons for Personas • Puts an end to feature debates • Makes hypothetical arguments less hypothetical • Q: “What if the user wants to print this out?” • A1: “The user won’t want to print often.” • A2: “Emilee won’t want to print often.” • User Persona, not Buyer Persona • This is one way HCI differs from marketing • Eventually it pays off in more sales

20. Next Time • Practice Persona development • Holtzblatt on Task Analysis