Please enable JavaScript.

Coggle requires JavaScript to display documents.

Usability Evaluation - Coggle Diagram

- - - - Select target audience
    - - Prepare and arrive >= 15 minutes before participants, set up
    - - With a short paragraph, set the stage
      - Then write a numbered-list of tasks
      - Tasks should be realistic, doable, ethical, clear, succinct, and be focused on uncertain aspects of the design
      - Chain tasks so that one leads naturally to the next
    - - Put sheets down, not asking questions
  - - - Contextual is free flow, user controls
        Evaluation is you controlling the flow�
    - - Give the opening scenario
      - Then begin assigning tasks in order, ask user to perform
        
        Improvisation is okay
      - Observe task time, errors, breakdowns, workarounds, confusions, and success/failure
      - Make notes, video-record, audio-record
      - Think-aloud protocal
        
        basis for understanding users’ cognition and perception during testing
        
        Analyze
        
        Think-aloud for need-finding
        
        Synthesize
        
        Think-aloud for eliminating ideas
        
        Evaluate
        
        Think-aloud for usability testing
        
        Insight problem
        
        When people are trying to figure something out, and it requires “insight,” thinking-aloud can be very disruptive
        
        wait until a natural break, and then ask them, “What were you thinking just there?
        
        Retrospective think-aloud
        
        do the think-aloud after-the-fact while watching the video with the user
      - Allowing them to stray
        
        If you build extra time into your tests, you can allow users to stray a bit as they work
        
        They should stay on task
        
        they might wander down a rabbit hole
        
        This can yield good data, but takes time
        
        Eventually, you may have to interrupt and prompt them to find their way back
        
        If they can’t, help them, and note a major failure
      - Answer questions
        
        Paper system is enough - do not answer any questions
        
        You wouldn’t be there “in real life.”
        
        You want to see if they can figure it out
        
        You want to see how hard it is
        
        You want to see how catastrophic the outcome is if they keep struggling
        
        Answering users’ questions for help ruins your data and contaminates it
      - Do not make value judgments
  - - - Now you can show them how to accomplish the tasks that they had failures on
  - - - Even if they happened for just one user
- - - - most common task satisfaction metric
- - - - Pick something users like
- - - - Learnability
        
        have users never interact with domain before
        
        How easy is it for users to accomplish basic tasks the first time they encounter the design?
      - Efficiency
        
        Once users have learned the design, how quickly can they perform tasks?
      - Memorability
        
        When users return to the design after a period of not using it, how easily can they reestablish proficiency?
      - Errors
        
        How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
        
        prepare some error messages/ paper responses - let them know how to recover from errors
    - - Satisfaction
        
        Determines who uses what
        
        How pleasant is it to use the design?
- - - - Observers can learn a lot from hearing two people talk to each other
    - - Costs more — have to pay 2x
      - No-shows are more problematic
      - Group effects come in — one disruptive user ruins two
- - - - Iterative design and testing might uncover all remaining problems