User Studies Methods - PowerPoint PPT Presentation

User studies methods l.jpg
Download
1 / 60

User Studies Methods Feb 01, 2007 Case Studies Chameleon Case Study: Chameleon Design proposal introducing new user interface metaphor Case Study: Chameleon Iterative Design Paper prototype -> Visual Basic -> Implement Increasingly refined prototypes Evaluation of each prototype

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

User Studies Methods

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


User studies methods l.jpg

User Studies Methods

Feb 01, 2007


Case studies l.jpg

Case Studies

  • Chameleon


Case study chameleon l.jpg

Case Study: Chameleon

  • Design proposal introducing new user interface metaphor


Case study chameleon4 l.jpg

Case Study: Chameleon

  • Iterative Design

    • Paper prototype -> Visual Basic -> Implement

    • Increasingly refined prototypes

    • Evaluation of each prototype


Chameleon study 1 l.jpg

Chameleon Study #1

  • Understand feasibility of basic idea

    • How people used security features

    • Explicit vs implicit role switching

  • Used paper prototype

  • Recruited 10 people from campus

    • Unclear, but presumably typical users w/o extensive computer experience


Chameleon study 16 l.jpg

Chameleon Study #1

  • “We recruited 10 people from around our campus to use the paper prototype while we observed them ad listened to their comments about what they found confusing, easy, difficult, helpful, etc.”

  • “Participants also filled out a web-based questionnaire about their experiences using the prototype”


Chameleon study 17 l.jpg

Chameleon Study #1

  • Fairly typical of an early formative study

    • Formative means early stages of design

    • Summative means later stages (timing data)

  • Lots of qualitative feedback

    • Useful for early stages

    • Should be able to notice major issues w/o having to do extensive analysis

  • Little unclear what the tasks were

    • Specific tasks to understand usability

    • Freeform tasks to understand utility


Chameleon study 18 l.jpg

Chameleon Study #1

  • Web survey useful too

    • Lots of positive and negative comments

    • Always a good idea to do a survey

  • Helped flesh out major issues

    • Switching roles needed to be improved

    • User motivation issues

    • Names of roles


Chameleon study 19 l.jpg

Chameleon Study #1

  • Comments:

    • Good to show alternative designs after such a study

    • People not as good evaluating a single design, better to show alternatives and have them compare differences


Chameleon study 2 l.jpg

Chameleon Study #2

  • Drilling down on the UI

    • How people should perform key operations

    • Ex. Moving a file from one role to another

  • Roughly three designs per operation

    • Within-subjects design (each person tries all)

    • How to address learning effects?


Chameleon study 3 l.jpg

Chameleon Study #3

  • Visual Basic prototype

    • More refined prototype let them study issuesmore in-depth than possible with paper

  • Injected an “attack”, window that appeared to be in certain role but was in another

    • One issue with security studies is timing, may want people to become comfortable and then see if they notice and how they react

    • Few participants noticed 


Chameleon general comments l.jpg

Chameleon: General Comments

  • Start simple and with big issues first

    • Progressively refine the prototypes

    • Don’t drill down to small issues until needed

  • UI design studies should inject an attack

    • See whether people notice

    • Can try various UIs to compare effectiveness


Kazaa file sharing study l.jpg

Kazaa File Sharing Study

  • Good and Krekelberg, CHI 2003

  • Could people understand what files were downloadable by others?

    • Found lots of people sharing inbox.dbx

    • Found that some people were downloading a fake inbox.dbx file


Kazaa cognitive walkthrough l.jpg

Kazaa Cognitive Walkthrough

  • Cognitive Walkthrough

    • Put yourself in shoes of users and try to use the interface from their perspective

    • Somewhat effective approach, depends on ability of person to see other perspectives

  • Problem #1: Multiple names for similar things

    • My Shared Folder- a folder + all shared files

    • My Media- all shared files by media type

    • My Kazaa- all shared files by media type

    • Folder for downloaded files - root folder of all shared files


Kazaa cognitive walkthrough15 l.jpg

Kazaa Cognitive Walkthrough

Problem 2: Downloaded files

are also shared files

Problem 3: Kazaa recursively

shares folders


Kazaa cognitive walkthrough16 l.jpg

Kazaa Cognitive Walkthrough

Problem 4: Can select a folder,

but what files are inside?

Error-prone approach. Also risk

with recursive folders.


Kazaa cognitive walkthrough17 l.jpg

Kazaa Cognitive Walkthrough

Note: Gives one-time warning

if you select an entire hard drive


Kazaa cognitive walkthrough18 l.jpg

Kazaa Cognitive Walkthrough

  • Problem 5: Inconsistent views

    • Two UIs for doing similar tasks, but show different information about state of system


Cognitive walkthru discussion l.jpg

Cognitive Walkthru Discussion

  • Fairly effective technique

  • May be useful to apply multiple times from multiple perspectives

    • Parent who has things to protect

    • Teen who wants to download music

  • May have false positives

    • Probably best to do cog walkthru with multiple people, combine issues, and triage

    • Importance (not a problem -> catastrophe)

    • Cost (trivial -> major rework)


Kazaa file sharing study20 l.jpg

Kazaa File Sharing Study

  • 12 users, 10 had used file sharing before

  • Figure out what files being shared by Kazaa

    • Download files set to C:\ (ie all files)

  • Results

    • 5 people thought it was “My Shared Folder”

      • which one UI did suggest


Kazaa file sharing study21 l.jpg

Kazaa File Sharing Study

  • 12 users, 10 had used file sharing before

  • Figure out what files being shared by Kazaa

    • Download files set to C:\ (ie all files)

  • Results

    • 5 people thought it was “My Shared Folder”

      • which one UI did suggest

    • 2 people used Find Files to find all shared files

      • This UI had no files checked, thus no files shared?


Kazaa file sharing study22 l.jpg

Kazaa File Sharing Study

  • Results

    • 5 people thought it was “My Shared Folder”

      • which one UI did suggest

    • 2 people used Find Files to find all shared files

      • This UI had no files checked, thus no files shared?

    • 2 people used help, said “My Shared Folder”

    • 1 person couldn’t figure it out at all

    • Only 2 people got it right


Kazaa file sharing study23 l.jpg

Kazaa File Sharing Study

  • 12 participants a little low, though results strong enough to indicate big problems

  • Could have tried to verify cognitive walkthrough issues

  • Could have tried to test people’s ability to configure system (defaults important!)

  • Interesting point:

    • Had to set up system to prevent any actual sharing of files

    • We’ve had similar issues wrt phishing


Are people still accidentally sharing files l.jpg

Are people still accidentally sharing files?

  • A rough & ready experiment by your friendly instructor (2006)

    • eMule (open source)

    • Combines eDonkey and Kad file sharing Different from FastTrack (Kazaa file sharing)

  • eMule stats

    • Downloaded by over 85 million people

    • 5.3 mil people / 633 mil files on eDonkey

    • 1.7 mil people / 300 mil files on Kad


Emule file sharing ui l.jpg

eMule File Sharing UI


Putting them together l.jpg

Design Model

User Model

System Image

Putting Them Together

  • Lessons from Chameleon + Kazaa

    • Examples of how to run user studies

      • Not the most rigorous studies, but good enough to demonstrate main point

    • Examples of mental models


Other general comments l.jpg

Other General Comments

  • Inform people that it’s a security study?

    • Can’t get useful results if informed

  • Ethics of not informing people

    • Involves some element of deception

    • Phishing studies framed as email studies

    • Golden rule useful here: treat people as you would like to be treated


Heuristic evaluation l.jpg

Heuristic Evaluation

  • Mentioned in “Why Johnny Can’t Encrypt”

    • Similar to cognitive walkthrough

  • Helps find usability problems in a UI design

    • Can perform on working UI or on sketches

  • Small set (3-5) of evaluators examine UI

    • independently check for compliance with usability principles (“heuristics”)

    • different evaluators will find different problems

    • evaluators combine findings afterwards


Why multiple evaluators l.jpg

Why Multiple Evaluators?

  • Every evaluator doesn’t find every problem

  • Good evaluators find both easy & hard ones


Heuristic evaluation process l.jpg

Heuristic Evaluation Process

  • Evaluators go through UI several times

    • inspect various dialogs and screens

    • compare with heuristics and other usability principles

  • “Standard” set of heuristics

    • Can also create domain-specific heuristics

      • competitive analysis & user testing of existing products

  • Use violations to redesign/fix problems


Heuristic h2 1 l.jpg

searching database for matches

Heuristic H2-1

  • H2-1: Visibility of system status

    • keep users informed about what is going on

    • example: pay attention to response time

      • 0.1 sec: no special indicators needed, why?

      • 1.0 sec: user tends to lose track of data

      • 10 sec: max. duration if user to stay focused on action

      • for longer delays, use percent-done progress bars


Heuristic h2 2 l.jpg

Heuristic H2-2

  • H2-2: Match between system & real world

    • speak the users’ language

    • follow real world conventions

  • Example: Mac desktop

    • Dragging disk to trash

      • should delete it, not eject it

      • finally fixed in Mac OS X


Heuristic h2 3 l.jpg

Heuristic H2-3

  • H2-3: User control & freedom

    • “exits” for mistaken choices, undo, redo

    • don’t force down fixed paths

      • like that BART machine…


Heuristic h2 4 l.jpg

Heuristic H2-4

  • H2-4: Consistency & standards


Heuristic h2 5 l.jpg

Heuristic H2-5

  • H2-5: Error prevention


Heuristic h2 6 l.jpg

Heuristic H2-6

  • H2-6: Recognition rather than recall

    • make objects, actions, options, & directions visible or easily retrievable


Heuristic h2 7 l.jpg

Heuristic H2-7

  • H2-7: Flexibility and efficiency of use

    • accelerators for experts (e.g., gestures, kb shortcuts)

    • allow users to tailor frequent actions (e.g., macros)


Heuristic h2 8 l.jpg

Heuristic H2-8

  • H2-8: Aesthetic and minimalist design

    • no irrelevant information in dialogues


Heuristic h2 9 l.jpg

Heuristic H2-9

  • H2-9: Help users recognize, diagnose, and recover from errors

    • error messages in plain language

    • precisely indicate the problem

    • constructively suggest a solution


Heuristic h2 10 l.jpg

Heuristic H2-10

  • H2-10: Help and documentation

    • easy to search

    • focused on the user’s task

    • list concrete steps to carry out

    • not too large


Phases of heuristic evaluation l.jpg

Phases of Heuristic Evaluation

1) Pre-evaluation training

  • give evaluators needed domain knowledge and information on the scenario

    2) Evaluation

  • individuals evaluate problems

  • then combine problems as a group

    3) Severity

  • each person rates severity, then combine

    4) Debriefing

  • discuss the outcome with design team


How to perform heuristic evaluation l.jpg

How to Perform Heuristic Evaluation

  • At least two passes for each evaluator

    • first to get feel for flow and scope of system

    • second to focus on specific elements

  • If system is walk-up-and-use or evaluators are domain experts, no assistance needed

    • otherwise supply evaluators with scenarios

  • Each evaluator produces list of problems

    • explain why with reference to heuristic or other information

    • be specific and list each problem separately


Examples l.jpg

Examples

  • Typography uses mix of upper/lower case formats and fonts

    • violates “Consistency and standards” (H2-4)

    • slows users down

    • probably wouldn’t be found by user testing

    • fix: pick a single format for entire interface

  • Note: agreeing on heuristic not as important as the problem itself


Severity rating l.jpg

Severity Rating

  • Used to allocate resources to fix problems

    • estimates of need for more usability efforts

  • Combination of

    • frequency (one time or repeating, few people or lots of people)

    • impact (minimal to lots)

  • Should be calculated after all evals. are in

  • Should be done independently by all judges


Severity ratings cont l.jpg

Severity Ratings (cont.)

0 - don’t agree that this is a usability problem

1 - cosmetic problem

2 - minor usability problem

3 - major usability problem; important to fix

4 - usability catastrophe; imperative to fix


Debriefing l.jpg

Debriefing

  • Conduct with evaluators, observers, and development team members

  • Discuss general characteristics of UI

  • Suggest potential improvements to address major usability problems

  • Dev team rates how hard things are to fix

  • Make it a brainstorming session

    • little criticism until end of session


Severity ratings example l.jpg

Severity Ratings Example

1. [H1-4 Consistency] [Severity 3][Fix 0]

The interface used the string "Save" on the first screen for saving the user's file, but used the string "Write file" on the second screen. Users may be confused by this different terminology for the same function.


He vs user testing l.jpg

HE vs. User Testing

  • HE is much faster

    • 1-2 hours each evaluator vs. days-weeks

  • HE doesn’t require interpreting user’s actions

  • User testing far more accurate (by def.)

    • takes into account actual users and tasks

    • HE may miss problems & find “false positives”

  • Good to alternate between HE & user testing

    • find different problems

    • don’t waste participants


  • Login