CS252. User Interface Design

Lecture Outline for Feb. 14
Methods for User-Centered Design


1.     Design Iteratively with User Participation
     Case Study:  Participatory design of LCB tool
          Participatory design: users actually collaborate with software developers in design
          Phase 1: Descriptive prototype (product specification)
               Included the requirements we already discussed
               Also included a design approach: basic approach to initial design


               (A) Capitalize on phenomenon of attention as a searchlight




               (B) Capitalize on phenomenon of selective attention




               LCB design approach: 



2.     Using Visual Prototypes
     Case Study:  Appearance was based on the so-called "call graphs" we had observed at user sites
     How we used the prototypes:
          Single users or small groups (1-8 users)
          Transparencies of prototype used as basis for questions
          One evaluator showed, a second took notes on user responses
               Advantage:


               Disadvantage:


     Three levels of display:
          1.  Short-form, showing call chain to where the culprit CPU had crashed
          Questions posed to users:




          2.  Overview showing all (or most) of call graph, but each node was small
               Concept of color-coding:


               Availability of additional info:


          Questions posed to users:







          3.  Low-level display showing actual names of routines




          What we learned:  Reactions were generally positive, indicating that concept was easy to understand
          But there were some key concerns:
               Users wanted 2 interfaces, one graphical and one command-line


               Users mainly wanted ultra-quick access to the location of just the culprit, with no other info


               Users didn't want to see info on data storage, argument values, loop counters, etc.


               Our choice of "default screen" (culprit-only) wasn't what users wanted
               Users wanted the reason for failure to show, too, plus a textual description of where the program
                    failed 


     Other effective ways to use visual prototypes
          Make "paper" versions of interface components (menus, dialogs, screens, etc.)
               One evaluator role-plays the interface



               Advantage:


               Disadvantage:


          Create on-screen drawings and use like we did
               Advantage:


               Disadvantage:


3.     Using Interactive Prototypes
     Case Study: Interface was constructed with "phony" data; appearance was based on the feedback from the visual
          prototypes
          Used as basis for multiple cycles of iterative improvement
     How we used the prototypes:
          Had 1-4 users sit down and interact with the prototype
          Think-aloud protocol:





          Result from one session served as input to the next iteration of prototype improvement
     Example of prototype form   use slides  also had mockup of command-line interface
     Preparation of users:
          Minimal amount was told to user beforehand




          Each user was asked to apply the tool to determine where/why the program had crashed, verbalizing the
               entire process
     What we learned: Reactions to the command-line interface were very favorable
          Many users complimented us on providing this simple, fast alternative
          One said he would use this rather than GUI, even if GUI gave access to more info
     Reactions to the GUI over several iterations
          Users disagreed with our initial horizontal layout of the graph


          Users approved of visual feedback mechanisms:



          Asked for additional feedback


          Users had no trouble at all interpreting the purpose/meaning of messages


          Users had the most problem with some OSF/Motif-required aspects


          And users actually suggested shortcuts




          The ultimate compliment:


4.     Checklist for UCD


     User input alone isn't enough   it must be applied appropriately in re-design
          Experiences at Xerox [cited in Landauer 1995]


     The truth is that it's hard to apply feedback


     No checklist (however carefully crafted) can ensure that designers
          remain open to user criticisms/suggestions
          remain willing to modify their work in response   

     But user-centered design says that usability comes if-and-only-if it is true that users
           want to do this task, in this way