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


                                   1
              Agenda

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


                                        2
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
  cheap)‫‏‬
 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
    instructions
   More for public
    education
   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
    away
              Better Yet
 Clear picture
 Simple words
 Yellow warning
  color
      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




                                        16
    Deliverables for this week

   Project Proposal

   User Visit Plans

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



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




                               18
             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
    ideas!
                                                             19
                    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
    on
•   Not tied to a specific interface

                                                             20
     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



                                           21
       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
                                              22
    At your TA meeting, be
     prepared to discuss
 What you learned from the analysis
 Any changes in your conception of the
  project




                                          23
    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,
      http://doi.acm.org/10.1145/175276.175288
                                                      24
              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




                                              25
        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 (jnd.org):
       “Affordances, Conventions, and Design”
       “Emotion and Design…”




                                                    26
          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



                                              27
    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)‫‏‬

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

                                            29
    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


                                          30
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
        tasks
   Phase 3 – Evaluation
       Walk through tasks to test the
        design
       Test with users                                   31
         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!
                                                    32
    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    33
         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.
                                                            34
            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
                                 35
    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,
        www.acm.org/dl)‫‏‬
       (More to come on this)‫‏‬




                                                       36
    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
        design/prototype
                                                          37
                    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?     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.

                                            39
        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.
                                             40
Fundamental role of tasks in
        TCUID
   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

                                                    41
             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

                                                  42
          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


                                            43
                         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, …
                                                                44
        Properties of Scenarios

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

   Take a look at the student section of
    www.OneStop.umn.edu
   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



                                                 47