1. Task-Centered User Interface Design: An Introduction

2. Hall of Shame: AC Remote

3. Giant button in the middle affords pushing, but it’s not actually a button Buttons are similarly shaped, do different things. Bad visibility. Button layout could be improved (fan buttons grouped together, fan arrows unnecessary, etc)

4. Hall of Shame Ashley Perkins

5. Ceiling Fan

6. Current Solutions

7. User Visit Plans Due Friday Written, but informal – specific goals, approaches, people, dates, and times – general ‘script’ indicating who will ask or observe what in what sequence – what types of notes you will take (do you need note-taking forms?) Grade – How clearly you have thought through what you need to learn from the visits and how you’ll gather this knowledge

8. Exercise Consider the general task of voting –A voter chooses one (or more) candidate from a set of candidates for a particular office –In a given election, voters may have to make choices for multiple offices

9. Exercise – Part 1 Consider users –Who are they? –What are relevant user characteristics? Result  write personas describing two users

10. Some example users Voter Poll worker Vote counter Party official / candidate representative

11. TCUID Principles The interface should be tailored to the users and their tasks The development process should use the users’ tasks throughout design and evaluation

12. System-Centered Design What I find interesting or cool to work on What’s easy to do using: html, Visual Basic, Java Swing, or whatever 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)

13. Instead: User-Centered System Design Base design on real people: –Abilities –Needs –Work context –Tasks they are trying to accomplish Golden Rule of UI Design: –“Know Thy User”

14. User-Centered System Design The design process is a collaboration between designers and customers The design evolves and adapts to their changing concerns Designer and customer are in constant communication throughout the process

15. Key Components of TCUID Phase 1 – Identification/definition –Users and tasks – figure out who’s going to use the system for what –Create specific scenarios Phase 2 – Design –Select tasks to support –Create designs (mockups first, then prototypes) to support these tasks Phase 3 – Evaluation –Walk through tasks to test the design –Test with users What we’ll cover today iterate as necessary

16. 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 designer” is not a good user –“the VP” is rarely the user –“purchasing” is rarely the user –And you sure aren’t the user!

17. Why “you” don’t count as a user You almost certainly aren’t typical –You’re too technically savvy –You don’t care (just) about the task It’s “cheating” –Remember: Design model  System Image  User’s Model –But you know the Design Model, so you can’t test whether the System Image leads users to form an appropriate model

18. Spend time with users Go talk with the users –Are they too busy? Then how will they have time to evaluate/use it? Are there good surrogate users? Observe the user at work –Content – what they’re trying to accomplish –Context – physical workplace, organizational setting, etc.

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? –new tasks

20. Users aren’t perfect either 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 envision possible new ways of doing things They aren’t designers –You must learn about the tasks from the users –Then use your design skills to create a design –Finally, get user feedback on the design/prototype

21. Tasks A detailed description of a complete job that specific users want to accomplish Doesn’t specify how they would do the job – separate the What from the How; concentrate on the What Must specify typical details Complete job –Not just feature lists –Cover transitions between sub-tasks, so you have to consider how different components work together –Specify inputs/outputs – where does information come from, where does it go?

22. Sample Task - Poor The user selects the stories that will be in the “news” section of the website.

23. Sample Task - Better The user selects from a collection of stories the stories that will be in the “news” section of the website. The user has the ability to edit the list including ordering, and adding/removing incorrect stories.

24. Sample Task - Detailed Rita Neus, the on-line production coordinator for the paper sits down at 1:30 AM before going home for the night, and –Selects the stories stokeef.xy, stguns.xy, stvet.xy, stwres.xy, stcomp.sy (in that order) for the “news” section of the website. –She decides that stvet.xy should be the lead story –She realizes that stwres.xy is actually a sports story and moves it to that department.

25. Sample Task - Poor The user sets up a schedule for a guest visitor and makes it available for others.

26. Sample Task - Better The user sets up a schedule for a guest visitor. This schedule includes 4 or 5 “template” events (some fixed time and some variable time). The schedule is announced so that others can sign up.

27. Sample Task - Detailed Dr. Schafer, head of the search committee, is in charge of setting up the schedule for the campus visit of a job candidate (Sal Lammy) on February 7 th. He schedules –time to take the candidate to lunch, and dinner. –3:30-4:30 PM for the candidate’s research talk. –4:30-5:30 for the “wine and cheese reception.” –A 90-minute block for a campus tour which ends with a meeting with the Dean (check with the Dean on availability). He contacts the other members of the department and allows them to schedule 30 minute meetings with the candidate for any time slot not yet taken and to join meals.

28. Why Tasks? Tasks are fundamental to TCUID –represent who actually uses the system –set goals for system functionality –basis for system design Thomas: “Let’s add this cool new feature!!!” Sharon: “Why? Which task does it support?” –basis for comparative evaluation of different design alternatives –basis for user testing

29. Defining Tasks Concentrate on frequent and infrequent-but- important tasks 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

30. Exercise Consider the general task of voting –A voter chooses one (or more) candidate from a set of candidates for a particular office –In a given election, voters may have to make choices for multiple offices

31. Exercise – Part 1 Consider users –Who are they? –What are relevant user characteristics? Result  write personas describing two users

32. Some example users Voter Poll worker Vote counter Party official / candidate representative

33. Exercise – Part 2 Now consider tasks –Write 2 task descriptions Who are the users? What are they trying to do?

34. Next Steps For next time (next week) –Continue discussion of the task-centered user interface design process –Spend some time talking about the UIDP readings Project –Friday will be our first official studio –Project Proposal –Site Visit Plan