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?
- 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?
- 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”!
- 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.
- 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
- 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
- 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
- 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
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).
No comments:
Post a Comment