Software Engineering 5115 User Interface Design & Evaluation

1. Software Engineering 5115User Interface Design & Evaluation Joseph A. Konstan konstan@cs.umn.edu Loren G. Terveen terveen@cs.umn.edu

2. Today’s Issues • Course Introduction • Introduction to HCI • Project/Group Introduction • Task-Centered User Interface Design SEng 5115

3. Introductions • Me • Background • Experience • Current Interests and Activities • Carol • Loren (next week) • You • Who you are • What you do • Your experience with UI/HCI SEng 5115

4. Introduction to User Interfaces • User Interfaces are Everywhere • telephone systems • automobiles • automated teller machines • doors! • Bad User Interfaces are Everywhere SEng 5115

5. Do Interfaces Matter? • A Two-Person Game • Start with the numbers 1, 2, 3, ..., 9 • Alternate turns, taking one number at a time • A player wins with any 3 numbers that sum to 15 • e.g., 1, 3, 9, 5 wins because 1+9+5 equals 15 • Draw if numbers used up without a winner SEng 5115

6. Do Interfaces Matter? • Lost Productivity • Real Disasters • Three Mile Island • Airplane Cockpits • But, Won’t the Users Complain? SEng 5115

7. Course Objectives • Understand UI problems, issues, and challenges • Learn and apply basic principles of design psychology • Become familiar with basic underlying principles and models SEng 5115

8. Course Objectives • Learn and do user and task analysis • Learn and practice task-centered approach to UI design • Learn and practice several methods of interface evaluation SEng 5115

9. Course Objectives • Experience prototype/iterate interface design process • User and Task Analysis • Design • Evaluation • without users • with users • Re-design SEng 5115

10. Course Objectives • Learn enough about implementation to work with implementers • Understand usability engineering vs. software engineering • Become familiar with important HCI research issues and technology trends • Become aware of design challenges and appropriate methods for “non-traditional” UIs • Learn where to go for more information SEng 5115

11. Course Features and Highlights • Let’s look at the web site • Schedule, textbooks, grading, etc. • Good and Bad UI Presentations • Group project • groups of 4-5 • real users, real problems • design and prototype -- not implement • presentations • In-class activities • Special topics SEng 5115

12. Teaching/Learning Approach • Motivate • Read • Present • Discuss • Practice • Discuss • Do Your experiences are a valuable learning tool SEng 5115

13. A Few Required Thoughts • Be in the right course • Don’t cheat • Get help if you need it • Have fun! • OK, that one wasn’t required SEng 5115

14. Task-Centered User Interface Design • Intuitive methodology • Easy to apply • Easy to teach others later • Online text by Lewis and Rieman SEng 5115

15. TCUID Principles • The interface should be tailored to the users and what they are trying to accomplish • The development process should use the user tasks throughout design and evaluation • The process is a collaboration between designers and users; the design evolves and adapts in response to changing concerns SEng 5115

16. Key Components of TCUID • Users • Represented by descriptions, personas • Tasks • Walkthrough Scenarios • The term “scenario” is used both for this purpose and for interface design stories SEng 5115

17. Who are the Users? • You need to identify real people who will (at least potentially) use your system • if you can’t find users, you’re in trouble • “everyone” is not a user • “the VP” is rarely the user • “purchasing” is rarely the user • “designers” (you) are not a good user SEng 5115

18. Spend Time with Users • Go talk with the users • too busy? • Then how will they have time to evaluate/use it? • are there good surrogate users? • Observe the users at work • Content – what • Context – where, how SEng 5115

19. Talking with Users • What do they know? • systems, skills, etc. • What do they do? • tasks • How do they do it now? • scenarios • What do they want to do? • problems, new tasks SEng 5115

20. Develop Personas • Detailed descriptions of specific users to help guide the design process • Based on research • Fleshed out to feel “real” Fred Fish is the manager of a group of cafeteria managers at corporate offices in eastern Massachusetts. He uses a computer in his work, but he’s a chef by trade. A computer is just another tool for getting his administrative tasks done. SEng 5115

21. But users aren’t perfect • Users aren’t all-knowing • they may have a very narrow view • they may not be able to articulate what they do and what they know • they may not be able to envision possible new ways of doings things • They aren’t designers • learn about the tasks from the users • use your design skills to create a design • get user feedback on the design/prototype SEng 5115

22. Tasks • What is a task? • a specific description of a complete job that specific users want to accomplish • not tied to how they would do the job • Detailed • some typical details are important • Complete job • covers transitions between sub-tasks SEng 5115

23. Example Task Professor Konstan receives an email telling him that the first MSSE User Interface course is scheduled to meet starting Friday, January 22, and then each week, alternating Friday and Saturday, through May 1. No class is scheduled for March 19 or 20. He should enter these dates into their calendar, scheduling 10 – 12:45 am for the class, and 9:30 – 10 and 12:45 – 1:00 for slack. He also should produce a list of conflicting appointments, if any, so that he can re-schedule them. SEng 5115

24. Why Tasks • Tasks are fundamental to TCUID • reminds us how actually uses the system • sets goals for system functionality • basis for system design • basis for comparative evaluation • basis for user testing SEng 5115

25. How Many Tasks? • Depends on nature of problem • 3-5 general-purpose tasks for a very simple system • separate tasks for special-purpose cases (maintenance, installation) • 10+ tasks for complex systems • depth/quality more important than number of tasks SEng 5115

26. From Task to Design • Write up tasks, circulate among users • clarify missing details • Rough out an interface, using existing systems or designs where possible • Sketch out how each task would be accomplished in the interface: develop walkthrough scenarios SEng 5115

27. Walkthrough Scenarios • Specific instance of system use • for a particular task • for a particular interface • what would the user do, in detail • enough detail for a user to complete without task knowledge • Example • click on the “Download” link on the screen, ... SEng 5115

28. Properties of Scenarios • Interface-dependent • Detail appropriate to user, task, interface • Brings forward issues • how components work together • design arguments • tricky parts of the interface • First step in evaluation SEng 5115

29. The Rest of TCUID • Evaluate • without users • with users • Revise and Re-Evaluate • Deliver! SEng 5115

30. Your Project • Key non-negotiable issue • participation of real users outside the project design team • prototype, not implement • Timeline and deliverables (on web site) • Project groups • Project questions and discussion • Project ideas SEng 5115