An Introduction to Task-Centered User Interface Design

Document Sample
An Introduction to Task-Centered User Interface Design Powered By Docstoc
					An Introduction to Task-Centered
      User Interface Design

       Loren Terveen
      CS 5115, Fall 2008
        September 22


 General project check
 This week’s project deliverables
 Next week’s project deliverables
 Scheduling initial prototype
 Task-Centered User Interface Design
 But first…

Pop/Soda/Coke Bottle
  Evan Long (annglove)‫‏‬
     Jon McLachlan
Pop Bottle
    Fame of the plastic bottle
 can screw the top back on (some level of
  preservation for later use)‫‏‬
 prevents spills
 "easy" access - visible break (good security, and
 adopts the common convention "lefty loosey"
 irregardless of brand/contents, easy to use
 testable explosion (and stoppable, unlike the
  aluminum and glass counterparts)‫‏‬
    Glass Bottle (Hall of Shame)‫‏‬
   Glass bottle full of carbonated liquid
      requires  a new tool to remove
      using your shirt as a shield to the skin-pealing cap, if it
       explodes, it explodes in your shirt (can not prevent
       partial explosion
      cannot reseal
      glass is breakable
Hall of Shame / Fame

    Michael Raymond
      Alan Wyman
   September 22, 2008
Airport Wayfinding

       This sign is in Helsinki Finland
Airport Wayfinding

       This sign is in London England
               Hall of Shame
   These are both part of the Hall of Shame
     They don’t communicate universally
     Airports require accessibility
     Difficulty mapping text to action
Airport Wayfinding

         This sign is in Cancun Mexico
           Directional Signs - Warning Signs

   Must be read to
    understand that it
    contains emergency
   More for public
   Good mnemonic
   Except that the
    “steady state” alarm
    also pulses
        A Much Better Sign

   Grabs attention
    by jutting out
    from the wall
   Clear wording
   Picture is not bad
   Green color
    indicates a
    positive action
    rather than a
    warning to stay
              Better Yet
 Clear picture
 Simple words
 Yellow warning
      Project deliverables

 Please read the Project Guide
 Please review the Project Guide for
  the upcoming week(s)‫‏‬
 Let’s look at this week’s and next
  week’s deliverables

    Deliverables for this week

   Project Proposal

   User Visit Plans

   (Let’s look at Project Guide)‫‏‬

Deliverables for next week –
          Week 5
 User Visit Report
 5 Tasks
 2 Scenarios
 Other stuff

             User Visit Report
•   Summary of the process you carried out
•   A user description – relevant user characteristics
    you are considering in your design.
    •   expected range of computer and internet experience
    •   use environment
    •   special user concerns or motivations
    •   …
•   what users do today to fulfill the needs that your
    project aims to satisfy in a new way

•   You are finding out about their tasks and
    needs, not confirming your initial design
                    Task Analysis
•   Descriptions of at least five (TCUID) tasks that users
    would accomplish with your prototype
•   For each task description
    • who are the users
    • what are they doing
    • why are they doing it
•   At least three should be general tasks that users
    accomplish today
•   Detailed enough for users to understand and comment
•   Not tied to a specific interface

     Current Usage Scenarios

•   For two of the tasks, provide a detailed
    scenario explaining how users
    accomplish that task toda
•   These scenarios may involve
    computer software, paper, or other
    devices, in any combination

       Other Stuff To Include

•   Anything else you learned from the
    user visit not already covered
•   How effective was your process
•   Lessons learned – what you’d do
    different in the future
•   Any information you could not gather,
    along with either (a) plans for how you
    will get it or (b) how you’ll continue
    without it
    At your TA meeting, be
     prepared to discuss
 What you learned from the analysis
 Any changes in your conception of the

    Looking Ahead – deliverables
             for week 6
   Initial paper prototypes
     Two per project team – done independently!
     (Project guide slip: personas aren't until wk 7)‫‏‬
     See the schedule online
   Readings for next week
     Preece, chapter 11
     Preece, chapter 6 (just skim)‫‏‬
     Prototyping for Tiny Fingers,
              Question Time

 Any project questions?
 Hall of Fame/Shame presentations?
       Check the schedule – if you can’t
        present at your assigned time, send
        me email at once

        Reflections on DOET

   Was written 15+ years ago
   Talks about things like doors, slide projectors,
    refrigerators, not GUIs
   How well does it apply to designing GUIs in 2008?
   Consider Norman’s own writings (
       “Affordances, Conventions, and Design”
       “Emotion and Design…”

          TCUID Principles

   The interface should be tailored to the
    users and their tasks

   The development process should use
    the users’ tasks throughout design and

    System-Centered Design
   What I find interesting or cool to work on
   What’s easy to do using: html, php, 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)‫‏‬

        Instead: User-Centered
            System Design
   Base design on real people:
     Abilities and needs
     Work context
     Tasks they are trying to accomplish

   Golden Rule of UI Design:
    “Know     Thy User”

    User-Centered System
 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 usage stories
   Phase 2 – Design
       Select tasks to support
       Create designs (mockups first,       iterate as
        then prototypes) to support these    necessary
   Phase 3 – Evaluation
       Walk through tasks to test the
       Test with users                                   31
         Who are the users?

   You need to identify real people who
    will (at least potentially) use your
     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
   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
       But you know the Design Model, so you
        can’t test whether the System Image
        leads users to form an appropriate model    33
         Spend time with users
   Go talk with the users
       Are they too busy?
          Then   how will they have time to evaluate/use
          Are there good surrogate users?

   Observe the user at work
     Content – what they’re trying to
     Context – physical workplace,
      organizational setting, etc.
            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
    One way to work with users

   Contextual inquiry
       Beyer, Hugh, and Holtzblatt, Karen,
        "Apprenticing with the Customer: A Collaborative
        Approach to Requirements Definition,"
        Communications of the ACM, May 1995
        (available through ACM Digital Library,‫‏‬
       (More to come on this)‫‏‬

    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 be able to 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
   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?     38
              Example Task
Professor Terveen gets email telling him that
5115 is scheduled to meet every Monday
and Wednesday, starting September 3, and
ending December 10; the final will be
sometime during the week of December 10.
He should enter those dates into his
calendar, scheduling 9:45-11:0 for the class.
He should also produce a list of conflicting
appointments that need to be rescheduled.

        Another Example Task
Professor Terveen is flying on Northwestern
Airlines to Newark, NJ tomorrow. He wants
to check in for his flight. He wants to be sure
his frequent flier number has been entered.
He wants to be able to check on his seat
assignment and change to an aisle seat if he
isn’t already in one. He’d also like the seat
to be in a row no one else is sitting in. After
he’s got his seat assignment, he wants to get
a copy of his boarding pass.
Fundamental role of tasks in
   represent who actually uses the system
   set goals for system functionality
   basis for design decisions
     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
   Separate tasks for special-purpose cases
    (maintenance, installation)‫‏‬
   10+ tasks for complex systems
   Depth/quality more important than number
    of tasks

          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, then
  develop scenarios


   Specific instances of system use
       From the what to the how
            A particular task
            A particular interface
       What the user would do, in detail
            So someone could complete without task knowledge
   Example
       click on the “Check In” icon on the screen; on the
        next screen, click on the text box next to the
        “Please enter your first name” label and enter
        your first name, …
        Properties of Scenarios

 Interface-dependent
 Detail appropriate to user, task,
 Make certain issues obvious
     how components work together
     design arguments
     tricky parts of the interface
   First step in evaluation
         Important: tasks and
        scenarios are concrete
 Questions come in different kinds
 Some can be settled through abstract
       Are there more real numbers than natural
   Some only can be settled empirically
       Can students use to
        find out whether there is room to enroll in
        CS 5115?

   Take a look at the student section of
   Define 3 tasks (not scenarios)
                                          10 minutes
    students might try to accomplish with
    the site
       Remember what tasks are used for
   Present tasks, discuss, ask
    questions                              10 minutes