Wednesday, April 22, 2009

Final Reports & Presentation

You’ve Done Design Briefs
  • Team Members
  • Statement of Problem/Challenge
  • Activities to Date
  • Summary of User Interviews & Participant Profiles
  • Design Priorities and Issues
  • Quick Review of Related Products/Systems
  • Persona(s)
  • Task Statements
  • Evaluation Plan
  • Exposures
  • Schedule of Design & Evaluation Activities

Final Reports: Goals
  • Present a problem/challenge
  • Show how you used HCI methods to arrive at a solution
    • Discuss design alternatives
    • Motivate design decisions
  • Choices were not arbitrary
  • Choices move design closer to “optimal”

Final Report: Required Sections: Part 1
  • Team Members*
  • Statement of Problem/Challenge*
  • Review of Related Products/Systems*
  • Summary of Interviews and Participant Profiles*
  • Key Design Issues and Priorities*
  • Personas* (may be primary and secondary)
  • Task Statements* (OK if revised)

*Included in Design Brief. Revise as necessary for Final Report

Final Report Required Sections: Part 2
  • Selection Among Design Alternatives
    • Mockups (What were the key findings for each method? How did the findings change your design? Screen shots are helpful, if available)
    • Cognitive Walkthrough
    • Heuristic Analysis
  • User Testing
    • Design for User Testing (What was the design you used for user testing?)
    • Experimental Protocol (What was the procedure you used during testing? Includes instructions, practice tasks, etc.)
    • Tasks (What tasks did participants complete?)
    • Participants (Summarize the general characteristics of participants)
    • Summary of Results/Overview of Findings (summarize the results from user testing. Give examples of comments, and provide screen shots of problematic elements...making a table is helpful or making list of actual aspects of the system and then what were the problems that were found).
***Screenshots in Apple are Apple, shift & #4

Final Report Required Sections: Part 3
  • Recommendations/Revisions from User Testing
    • High Priority (Explain who your prioritization of design issues and the design changes you made as a result)
    • Moderate Priority
  • •Final Design (What was your final design? How does it resolve issues identified during user testing. How does your design meet the needs of your users? Finally, how well does the final design resolve the challenge/problem you identified at the beginning of the report).
  • •Future Issues
Final Report Questions
  • Does your report clearly show the evolution of your design from beginning to end?
  • Do you show how HCI methods informed your initial design and subsequent changes? (Show what was learned in class and how it helped you arrive at your design)
  • Have you made it clear how your user testing informed your final design?
  • Is it clear how your final design will meet your users’ needs and resolve the challenge/problem you identified?
***Final Report can be submitted by May 6th at 5:00pm on WebCT by either PDF or Word***



Presentations
  • 20 minutes per project
    • We have 9 projects total
    • Teams: Each person should present a portion of your project
  • 15-17 minutes for presentation
  • 3-5 minutes for answering questions
    • Audience members: Be active & ask questions!
Presentation Goals
  • Communicate the problem/challenge you were trying to solve
    • Convince your audience that it’s important!
  • User Needs
    • What were the user needs that you identified?
    • What was the initial design?
  • HCI Methods ->Final Design
    • How did HCI methods inform decision decisions?
    • What were the major design changes and why did you make them (e.g., what HCI results convinced you?) (user testing or earlier analysis)
    • How well does your final design meet users’ needs?
Presentation Questions
(can you answer yes at the end)
  • Did you clearly state the problem/challenge and its importance?
  • Is it clear what your users’ needs are?
  • Did you clearly connect the outcomes of HCI methods (e.g., Cognitive Walkthrough, Heuristic Analysis) to major design changes/decisions?
  • Did you make a case for your final design meeting users’ needs?

Wednesday, April 1, 2009

Parts of a Test Protocol

-Welcome
-Explain rights as a participant
-Study is completely voluntary
-You may stop at any time, or opt out of any task, for any reason.
-Instructions (general)
-Invitation for Questions
-Think Aloud Practice...Perform practice
-Task 1 instructions...Perform task
-Task 2 instructions...perform task
-When done, debrief and thank participant
-Give them an overview of the goals of the study
-Ask if they have any questions
-Invite them to contact you if they have questions in the future
-(Often, ask if they would like to participate in future studies)

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).

Wednesday, January 28, 2009

Personas

Articles read for today:

"Child-Personas: Fact or Fiction?" by Alissa N. Antle and
"Personas: From Theory to Practices" by Chang, Lim, & Stolterman

The Origin of Personas


Alan Cooper "The Inmates are Running the Asylum"
  • Personal Goal: "Develop a precise description of our user and what he wishes to accomplish"
  • User is a resource, but won't know solutions!
  • 'Make up pretend users and design for them"
  • Failure = design for broad, abstract groups
  • Success = design for a single (archetype) user
Personas: Definition
  • Description of a specific, fictitious person
    • Written in the form of a narrative
    • Represents gathered info about a group of users with common characteristics (single users too quirky!)
      • Usually given both a name and a face
      • May contain personal information
        • Family members, friends, occupations, possessions
        • Makes the persona more 'real'
      • Focuses on the goals, needs, and frustration of the persona when using the product being designed
  • 3 to 7 personas usually created for a project
    • Some advocate using one primary persona
Personas: Key Considerations
  • "Pretend" but not "made up"
    • Based on data with users
      • interviews
        • Ideally completed face to face
      • Observations
        • try to do this in the environment where program will be used
        • ask for comments from users - "What frustrated you?"
  • Presented as a story about a believable person
    • Project team should refer to the persona by name
      • Stop talking about abstract 'users'!
  • Focused on enabling effective design decisions
    • Should explicitly define the needs, goals, and frustrations of the persona
      • Designers should be able to infer what features are needed and how they should be designed
Example:

James is 52 years old and works as a mechanic with an organization offering road service to customers when their car breaks down. He has worked in the job for the past 12 years and knows it well. Many of the younger mechanics ask James for advice when they meet up in the depot as he always knows the answer to tricky mechanical problems. James likes sharing his knowledge with the younger guys, as it makes him feel a valued part of the team. James works rolling day and night shifts and spends his shifts attending breakdowns and lockouts (when customers lock their keys in the car). About 20% of the jobs he attends are complex and he occasionally needs to refer to his standard issue manuals. James tries to avoid using the manuals in front of customers as he thinks it gives the impression he doesn’t know what he’s doing.

James has seen many changes over the years with the company and has tried his best to move with the times. James has been told that his van will soon be equipped with a new computer system that will allow him to access job information and records, in addition to browsing the company’s website. He wonders if he will be able to find out what’s going on in the company more easily, especially as customers’ seem to know more about the latest company news than he does when he turns up at a job. This can be embarrassing and has been a source of frustration for James throughout his time with the company. James wonders if he will be able to cope with the new computer system. He doesn’t mind asking his grandchildren for help when he wants to send an email to his brother overseas, but asking the guys at work for help is another story.

What are personas good for?
  • Assisting communication
    • Easier to talk about 'James' and his needs
    • User is too abstract -> doesn't drive decisions
  • Informs design decisions
    • What does james need to do with the new system?
    • How do you meet James' goals?
    • How do you resolve James' frustrations?
If goals nor frustration is resolved, James will be angry and resentful and productivity will decrease.
  • Supports design evaluation
    • Where will you trip up James?
    • Will he know what to do? How to interact with the system?
    • Will he even use the system?
Personas: Drawbacks?
  • Bad personas won't help you and can be misleading
  • Some consider them too 'artsy' (developers tend to fight against it)
  • User interviews can be costly
    • Recruiting users
    • Conducting interviews
    • Transcribing protocols
    • Time to analyze data, extract themes
    • Some estimates: $47,000 for commercial apps
Creating Personas
  • Interview potential users. Take good notes
  • Identify key observations ("factoids")
    • 10-12 per interviewee is typical
  • Sort individuals into groups based on observations
    • Expert vs novice users
    • motivational vs apathetic
    • like technology vs. uncomfortable with it
  • Cluster key observations from multiple interviewees
    • Look for patterns/themes
      • what are their common needs
      • do they have common lifestyle
      • given the use of my system, key themes should relate to what the use of my system is
        • (if visual learners doesn't apply to your system, that shouldn't be a commonality)
    • Typically, 3-4 characteristics from each person are relevant to the group
Interview Data
  • Look for common goals
  • Look for common frustrations
  • Look for common perspectives, approaches
    • Technophile vs. Technophobe?
Observational Data
  • How do users interact with existing technology?
  • Do they take shortcuts?
  • Frustrations? How quickly do they opt-out?
  • Do they know how they use things? (people think they know and they really don't)
HCI Exercise #2 - Personas
  • Due next week (Feb. 4)
  • May work in teams
  • May use Capstone project as application
    • this is encouraged if it can work
Steps for Assignment/Exercise:
  • Identify application/website
  • Create & conduct 2+ interviews
  • Analyze interviews
  • Create persona