Wednesday, February 25, 2009

Jan. 24 HCI - Cognitive Walkthroughs

Cog Walkthrough: Prerequisites
  • Prototype OR detailed Mockup
  • A description o the user
  • A task, and high level task analysis
Cognitive Walkthrough Questions
  1. Will users be trying to produce whatever effect the action has?
  2. Will users see the control (button, menu, switch, etc.) for the action?
  3. Once users find the control, will they recognize that it produces the effect they want
  4. After the action is taken, will users understand the feedback they get, so they can go on to the next action with confidence?
Prioritize Issues
  • Critical (“Show-Stopper”)
    • Major loss of functionality. User cannot continue unless problem is resolved.
  • Moderate
    • Affects one piece of functionality. User can continue with other aspects of task, or work around the issue with some effort.
  • Minor
    • Cosmetic issues, issues that cause only minor slow downs or can be easily worked around.
Cognitive Walkthrough Exercise
  • User (Persona)
  • Task Description
  • Task Steps with Cognitive Walkthrough notes
  • Summarize & Prioritize key problems
Use the Word Document provided in WebCT: Assignments to organize your Cognitive Walkthrough.

Wednesday, February 18, 2009

2.18.09 HCI

Feedback on Scenario assignment:

How to decide on the right level of detail?
  • Could someone who has never seen your system imagine your persona using it?
  • You can assume that you don't need to describe very common knowledge
    • example: what it means to 'click' or 'type' or change text
  • Does your scenario inform your design?
Today's lecture:

Mockups
  • Definitions
    • Pictures of screens as they would appear at various stages of user interaction
    • Very early prototypes made of low-fidelity materials
      • Usually on paper; don't go through and do the programming
    • Prototypes with limited interactions and content
    • Typically Paper (or Cardboard)
      • drawn or created with software tools
        • PPT, Photoshop, Pencil
        • Omnigraffle is popular for MACs
      • Use different pages for new windows
Mockups = Low-Fidelity Prototypes = Paper Prototypes

Example Mockups


PDA travel application
Website design (Not in English …)
Google Reader (Demonstration Prototype)
Mockups
  • Purpose
    • Facilitate design evaluation BEFORE spending lots of time and money on a high-fidelity design
      • Reduces programming time
      • Can save money by identifying changes early
  • Concrete design improves feedback/evaluation
    • Prototyping: Same quality with 40% less code & 45% less effort (Boehm, Gray, Seewaldt, 1984)
  • Use whatever is fast and easy for *you*
    • Hand drawn?
    • PowerPoint?
    • Photoshop?
    • Pencil (add-on to Firefox)
      • Supports rapid paper prototyping for web/software interfaces
https://addons.mozilla.org/en-US/firefox/addon/8487

Check out Omnigraffle.

Local vs. Global Mockups
  • Local
    • Target selected aspects of the system
    • Identify KEY issues. What is most tricky?!
      • What terms to use in menus
      • How to provide feedback, etc.
  • Global
    • Overall interaction with your system
    • More holistic in nature
    • Covers numerous tasks with the same prototype
Vertical vs. Horizontal
  • Vertical <-> Local
    • Implement one section of your system in detail
    • Leave the rest as low-fidelity
  • Horizontal <-> Global
    • Implement all of your system in detail at high levels
    • Make all high-level features interactive
    • Leave in-depth content unspecified
      • E.g., actual description of grants, actual help files
High-fidelity Prototypes
  • Also known as
    • Prototypes
    • Version 0 systems
  • Use after you have clarified your design requirements
  • A working release of your system
  • Developed with same tools as final system
  • May lack some functionality/content
Working with your Mockups
  • Evaluating without users
    • Discuss readings
    • Issues for creating mockups?
    • (Next week: Cognitive Walkthroughs)
Hands-On Work
  • Begin mockups for your system
    • Decide on your design method
      • Our focus is on the quality of your design (not the method you used to mock it up)
    • Target 2+ tasks from your Design Briefs
      • Eventually you want your mockups to cover all tasks
  • Work on Design Briefs
    • Due next week
    • (No reading assignment this week)
Cognitive Walkthrough and Heuristic Evaluation (need to choose which will be used for which).

Should partner up for evaluation purposes on project to use evaluations.

Thursday, February 5, 2009

Thursday - Capstone Class

Learner Levels

Level 1 - Student Level

Level 2 - Teacher/ Trainer

Level 3 - No computer, beyond design level (something that can't be controlled, therefore not part of the design; usually a budget issue).

Wednesday, February 4, 2009

Febuary 4th, 2009

Today's topic: Scenarios

Review: Persona Exercise
  • Interviews...
    • Easiest parts?
    • Hardest parts?
  • Driving the persona?
    • Easy? Hard? Enough data?
  • How did you decide who to interview?
  • How did you decide what to ask?
  • What lessons learned for Capstone project?
Interviewing Tips: Finding Users
  • Decide carefully who to interview
    • Develop a profile
      • Who are the general users for your system?
      • What user characteristics are relevant to design & testing?
      • What characteristics should all users have in common?
      • What characteristics will vary? How will you define them?
  • Try to interview between 6 and 10 people
    • Less than 6 make it hard to identify patterns
    • More than 10 often not very useful
  • Having trouble finding people? Ask the first few users to suggest others.
  • Do contextual interviews
    • Go to the users’ relevant environment
      • E.g., office? Home?
Interviewing Tips: What to Ask?
  • Interview as a team (VERY helpful!!)
    • One interviewer, one scribe
  • Explain why you are talking to them & they can end interview at any time (for any reason)
  • Ask open-ended questions that allow elaboration
  • Look for opportunities to probe interesting responses
  • Be specific in getting how people already do tasks
    • Verbal: Tell me about the last time you ….
    • Observational: Walk me through how you’d …You can change/add questions as needed
  • This is the design phase! The point is to gather all relevant data!
  • Ask about contrasts: Best experience? Worst experience? Likes? Dislikes?
  • Last question:
    • “Can I contact you again if I have any more questions?”
    • Needs to be OK to say “no”!
Interviewing Tips: What Not To Do
  • Don’t use “Yes/No” questions
  • Be wary of leading questions
  • Avoid speculative questions
    • “Would you use an electronic calendar?”
    • If you must ask, do so at very end of interview
    • Don’t put too much stake in the answers
  • Avoid specific design questions
    • Look for data to inform your design! Don’t expect your interviewee to be able to solve your design problems.
Analyzing Your Interview Data
  • Flesh out notes from interview IMMEDIATELY
  • In teams, have each member start by analyzing data separately
    • Look for patterns that concern
      • Design priorities
      • Design issues
      • Deal-breakers (a.k.a. show-stoppers-such as registering; people hate to register and that is sometimes a deal breaker for a site)
    • Reconcile key themes identified by each team member
  • Use data to identify priorities
  • Then derive tasks
WHAT IS A SCENARIO?
  • Task + Persona = Scenario
  • Idealized but detailed
  • Describes a specific instance of interaction
  • Tries to balance generality & accuracy
    • Use persona
    • Use common, general tasks
    • Situate use in your design
  • Scenario-Based Development
    • Scenario-Based Evaluation
HOW TO WRITE A SCENARIO
  • Describe the situation of use that people (e.g. your persona) would experience
  • Write it for what your persona would want (or need) to do
    • Several scenarios for common tasks (to account for the most common tasks in your system)
  • Include specific, realistic details from your data collection
    • could use data from interviews to use in the scenario
  • Scenarios tell a short story (need to be able to imagine what's happening)
    • Represent the conditions, situations, and people that you'll be designing for
Scenarios for Design
  • Usually, a collection of scenarios are used
    • Should represent key priorities of your design
  • Scenarios help you perform evaluations without the users
    • Cognitive Walkthroughs
  • Scenarios help justify & communicate decisions
CHECK THE PPT TO REVIEW THE EXAMPLE SCENARIO FOR STUART (slide 18)

Scenario Practice
  • We practiced creating a scenario for Stuart using an educational technology(in groups of 3ish).

HCI Exercise #3: Scenarios
  • Due next week, Feb. 11
  • May work in teams
  • Steps:
    • Use persona you created for HCI Ex #2
    • Develop two common tasks
      • Use an educational technology of your choice
      • If possible, use your Capstone project
    • Write two scenarios of use (one for each task), describing how your persona would engage with the technology to perform the task(s).