Upload
deirdre-costello
View
280
Download
1
Embed Size (px)
Citation preview
Kate Lawrence, Vice President of User Research Deirdre Costello, Sr. UX Researcher Melissa Pike, Director of Technical Product Management, Medical Market September 18, 2014
See to Believe: Capturing Insights Using Contextual Inquiry
Agenda
1. EBSCO’s User Research Team 2. The Contextual Inquiry method 3. Our Medical CI Findings 4. TranslaRng Findings into Product
Data Analysis
Select the appropriate method, conduct our own research. Typically qualita8ve.
What ques8ons have been asked previously? What do those studies show? What does a comprehensive literature search reveal?
SecondaryResearch
PrimaryResearch
Review usage data and metrics. Quan8ta8ve methods.
Social Media Mining
Prototype Reviews
Focus Groups
Participatory Design
Metrics Analysis
Eye Tracking
Heuristic Evaluation
Video Diary Studies
Energy economics
A/B Testing
Secondary Research
Literature Reviews
Contextual Inquiry
Usability testing
Competitive Testing
Cognitive Walkthroughs
Amazon Mechanical Turk
Surveys
Card Sorting
Tree Navigation
Usertesting.com
CI is ethnographic; it is the research method that gets us closest to the user.
Real user, live workflow Users in simulated workflow
Data metrics, surveys Secondary research/ anecdotes
Contextual Inquiry
+ + + + -‐ -‐ -‐ -‐
Observing users in real context, including the structure of their work pracRce
ParCcipant-‐driven sessions
Understanding how social context influences the experience.
Focus on what users do, not what they say they would do.
A structured interview
StaRsRcally significant sample size
Time efficient
Easy recruiRng
What CI Is What CI is not
Contextual Inquiry
h\p://physiciandispensingsoluRons.com
Renewgroup.com
TheformaRonscompany.com
User Sessions
Debriefing
Stakeholder Review & PresenCng Findings
Affinity Mapping
Planning: The Team
• Secure iniCal support for the research • Team = UX & researchers + select others (ideal team size: 6-‐7 members)
• Time is a requirement – CI team members are expected to ac8vely parRcipate.
Planning: Prepping
• Resist the urge to write interview quesRons/a tesRng script – instead, idenCfy a list of themes and topics you want to cover.
• Create (lean) personas* to help with recruiRng.
• Train team on the CI process: provide readings, YouTube videos.
* A good lean persona resource – Jason Crane hGp://snapperwolf.com/2012/03/03/how-‐to-‐create-‐a-‐lean-‐persona.html
Planning: Recrui8ng
• Recruit a small sample based on skill sets/persona breakdowns and prepare yourself for the inevitable quesRon.
• Recruit through people you know – you need to find talkaRve, thoughhul parRcipants who respond to emails.
• Recruit iteraCvely – determine which personas are the most influenRal as you go
• Provide a good incenCve to guarantee Rme and a\enRon ($25+ per hour, Amazon gik cards if cash is hard).
“How do you know
that your sample is
representative?”
Planning: Scheduling
• Schedule parRcipants for a 1 to 2-‐hour block – maximum of 1 parRcipant per day. Build in Rme for travel, parking, food, brief discussion akerwards.
• Meet in an environment where the parRcipants do what you want to talk about. Students? Library, meeRng space, common room. Physicians? Hospital, office, etc.
Planning: Session Logis8cs
• Ask parRcipants to bring any devices they use regularly for the tasks that are the subject of the study. Ex: Students – what do you use for conducting research? Please plan to bring those devices with you to our session.
• Make sure there’s wifi. • Bring a notebook, several pens, your cell phone and your phone charger.
• Download a recording app, then make sure there’s room on your phone to store recordings.
• Start with a single request: “Can you show me the last search you did for x?” • Follow the parRcipant’s lead, but make notes about things you want to circle back and probe on. • Another key quesRon: “How did you learn about that?” • Do occasional Rme checks and note those in the margins
ConducRng the CI Sessions
Debriefing: How It Works
• Researchers walk through the enCre session, note by note
• Team asks specific quesRons, requests details and clarificaRon; discussion ensues.
• Note-‐taker captures what team indicates is relevant; team helps to formulate the “wall-‐worthy” note – Rp: focus on intent
Affinity Mapping: How It Works
• CreaRng affiniRes to organize/categorize the data from debriefs
• Print out every note • Decide on an iniCal set of themes (these will
evolve) • Have the team put all the sRcky notes on the
wall grouped by theme, then organize the notes into smaller, more specific groups and hierarchies
• Invite stakeholders and others outside the immediate team to socialize your findings
*Based on a 6 Sigma pracRce: h\p://www.discover6sigma.org/post/2009/02/affinity-‐diagram/
Visioning: What It Is
• Moving from data collecRon/ organizaRon to acConable ideas; opportunity for others to experience user pain points.
• Let a\endees “walk the walls” of the affinity hierarchies with post-‐it notes – instrucRon: “Write down your ideas for easing the pain points.”
• SoluRon ideas become workflow diagrams that represent ideal user scenarios.
Product Management: Melissa Pike
Rolling up your findings Agreeing on the problems you need to solve with sponsors DocumenRng your product themes and features PrioriCzing your themes and features with sponsors
TransiRoning from visioning to themes
Search Access
Content Mobile
Product Awareness Interoperability
Theme A Theme B
Theme C Theme D
Theme E Theme F
DocumenCng features and use cases CollaboraCng with your architects and technical leads Sharing the CI findings and session arRfacts Socializing features to other product stakeholders Synergizing across other product owners
Alignment: Ini8a8ves, Features
Image By People_icon.svg: User:LiWarn Symbol_support_vote.svg: User:Zscout370 Deriva8ve work: Drilnoth (talk) SVG version: Lukeas (People_icon.svg Symbol_support_vote.svg) [Public domain], via Wikimedia Commons
Roadmap Product Owner from Group 1
Roadmap Product Owner from Group 5
Roadmap Product Owner from Group 2
Roadmap Product Owner from Group 3
Roadmap Product Owner from Group 4
Theme A Theme B Theme C Theme D Theme F Theme G
Share the wealth of knowledge from CI, get buy-‐in, idenRfy co-‐ownership
Avoid living in your own product or market vacuum!
Feature Board Theme A Theme B Theme C Theme D Theme E Theme F
Feature A1
Feature B1
Feature C1
Feature D1
Feature E1 Feature F1
Feature A2
Feature C2
Feature D2 Feature F2
Feature A3
Feature B2
Feature D3 Feature F3
Feature A4
Feature B3
Feature D4
Feature E2
Feature A5
Feature B4
Feature C3
Feature E3
Feature A6
Feature A1
Feature D5
Feature E4 Feature F4
Decreasing Priority
Version 1 “Must Have” Feature Boundary
Blanks mean no feature for this theme has this level of priority
Visualiza8on courtesy of David Brickner, EBSCO Informa8on Services
Theme A Theme B Theme C Theme D Theme E Theme F
Feature A1
Feature B1
Feature C1
Feature D1
Feature E1 Feature F1
Feature A2
Feature C2
Feature D2 Feature F2
Feature A3
Feature B2
Feature D3 Feature F3
Feature A4
Feature B3
Feature D4
Feature E2
Feature A5
Feature B4
Feature C3
Feature E3
Feature A6
Feature A1
Feature D5
Feature E4 Feature F4
Decreasing Priority
Version 1 “Must Have” Feature Boundary
Example, these Pink Rckets are in Requirements
Feature Board
Visualiza8on courtesy of David Brickner, EBSCO Informa8on Services
Theme A Theme B Theme C Theme D Theme E Theme F
Theme A Theme B Theme C Theme D Theme E Theme F
Feature A1
Feature B1
Feature C1
Feature D1
Feature E1 Feature F1
Feature A2
Feature C2
Feature D2 Feature F2
Feature A3
Feature B2
Feature D3 Feature F3
Feature A4
Feature B3
Feature D4
Feature E2
Feature A5
Feature B4
Feature C3
Feature E3
Feature A6
Feature A1
Feature D5
Feature E4 Feature F4
Decreasing Priority
Version 1 “Must Have” Feature Boundary
Ticket color is updated to indicate status on the “In Progress” board
Feature Board
Visualiza8on courtesy of David Brickner, EBSCO Informa8on Services
Theme A Theme B Theme C Theme D Theme E Theme F
Theme A Theme B Theme C Theme D Theme E Theme F
Feature A1
Feature B1
Feature C1
Feature D1
Feature E1 Feature F1
Feature A2
Feature C2
Feature D2 Feature F2
Feature A3
Feature B2
Feature D3 Feature F3
Feature A4
Feature B3
Feature D4
Feature E2
Feature A5
Feature B4
Feature C3
Feature E3
Feature A6
Feature A1
Feature D5
Feature E4 Feature F4
Decreasing Priority
Version 1 “Must Have” Feature Boundary
MulRple state changes due to good progress from the teams
Feature Board Theme A Theme B Theme C Theme D Theme E Theme F
SomeRmes a great product can be defined by what it doesn’t have, versus having too much We are starRng simple, and layering in only the components that we saw user’s use or express a desire for
DeconstrucRng product, enabling usability
The image part with relationship ID rId3 was not found in the file.
Simplifying the Bull: How Picasso Helps to Teach Apple’s Style Inside Apple’s Internal Training Program By BRIAN X. CHENAUG. 10, 2014
"Osmar Schindler David und Goliath". Licensed under Public domain via Wikimedia Commons -‐ hGp://commons.wikimedia.org/wiki/File:Osmar_Schindler_David_und_Goliath.jpg#mediaviewer/File:Osmar_Schindler_David_und_Goliath.jpg
The image part with relationship ID rId3 was not found in the file.
Know your opponent, Make a Plan
CI findings arm you with knowledge Acknowledge your current weaknesses Learn from mistakes IdenCfy opportuniRes Inform your plan Align your team Focus on winning