1. Task-Centered User Interface Design: An Introduction

2. Some thoughts from the wall talks on Friday
Make sure you are focusing on problems that are interface in nature
If all you are doing is focusing on porting a web interface to an app or providing data not currently available in a certain format, you MAY hit a wall in the design process or may lose “difficulty points” during the final project grading.

3. Some thoughts from the studio this week
Make sure you approach the process in the right order.
Personas come AFTER interviews
Prototypes come a ways after that

4. Some thoughts from the studio this week
Don’t get TOO locked to reality:
This is a design project and (likely) won’t actually go anywhere.
Don’t worry about things like “How are we going to know how many parking places are available?”
You can just pretend you have this data and it is accurate
Having said that “how could admins link to sensors or updated information” is a valid question.

5. 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

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

7. 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”

8. 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

9. 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

10. 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!

11. 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

12. Spend time with users Go talk with the users Observe the user at work
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.

13. Talking with users What do they know? What do they do?
systems, skills, etc.
What do they do?
tasks
How do they do it now?
scenarios
What do they want to do?
new tasks

14. 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

15. 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?

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

17. Sample Task - Better
The user views a collection of stories. The user selects 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.

18. 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.

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

20. 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.

21. 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 7th.
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.

22. 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

23. 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

24. 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

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

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

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

28. Next Steps For next time
Continue discussion of the task-centered user interface design process