User studies methods
1 / 60

User Studies Methods - PowerPoint PPT Presentation

  • Updated On :

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

PowerPoint Slideshow about 'User Studies Methods' - paul2

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

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

  • 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

  • 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