Task-Centered User Interface Design: An Introduction

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.

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

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.

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

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)

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”

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

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

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!

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

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.

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

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

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?

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

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.

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.

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

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.

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.

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

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

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

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

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

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

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