UXINDIA17 - User Research at the Speed of Business: A Field Research Primer & Toolkit

User Research at the Speed of Business: A Field Research Primer & Toolkit

Transcript

2. Field Research at the Speed of Business: What, Why and (a bit of) How Paul Sherman, PhD Kent State University
3. Me Trained as an aviation human factors researcher. Built small and large UX teams. Teach for Kent State’s UX Master’s program. Provide user experience research and design consulting. Husband & dad. 2
4. 3 I’m Also A Pixar Plot Device
5. What We’re Covering What it is Why do it How to do it (just a bit) 4
6. What’s not here How to build a UX research team. Deep details on analysis and communicating findings. More on those topics The UX Kit www.shermanux.com The UX Unicorn Is Dead: Soft Skills Beat Coding Skills bit.ly/ux_unicorn 5
7. What is field research? 6
8. The method goes by many names… 7
9. I like “customer observation” or “user observation” research. They keep the focus on two things: The person In the real world 8
10. Use The Term That Works For Your Organization At a former company, we referred to it by two acronyms… FMO FMH 9
11. “Follow Me to the Office” “Follow Me Home” A big part of your job is to: Align the team. Embed user-centered research and design activities into processes. Use words that resonate with your stakeholders! 10 UX
12. Whatever You Call It… It helps you understand users’ goals, workflows and context. 11 It reveals how they work or play. What they do and why. How your solution fits – or might fit – into their current behavior.
13. Why conduct field research? 12
14. Because context is king. 13
15. Imagine you’re talking to some users. Where will you learn more about how they work? Here? 14
16. Imagine you’re talking to some users. Where will you learn more about how they work? Here? Or here? 15
17. Because behavior doesn’t lie. 16
18. People (usually) don’t mean to lie. But people are bad at recounting the details of things they are expert at and do every day. 17
19. Bonus! When you observe people in context… You can ask follow-up questions about things that never would’ve occurred to you in a lab or meeting room. 18
20. Almost all observation projects are run for one of two reasons... 19
21. Evaluative Watch how people use an existing product or service, and find ways to improve it. 20
22. Generative Identify how people currently perform an action… and see if there’s an opportunity to provide a new product or service. 21
23. Let’s watch some field research! 22
24. Context: The product team and I are observing workers at animal shelters and rescues. 23
25. Learning In Context & In Real Time 24 (Video shown to attendees)
26. What are the chances I would’ve learned as much if I just brought those people into a lab? 25
27. How to do field research (just an introduction) 26
28. Warning: you will encounter resistance. 27
29. Typical Objections The project manager: “It takes too long.” 28 The founder: “We don’t need to talk to customers! I know what they need!” The marketer: “My team can run a focus group. And a survey!”
30. Countering Typical Objections “It takes too long” Quality user research can be done in as little as two or three calendar weeks. Think of it as “sprint zero.” 29
31. Countering Typical Objections “I know what customers need” There are other users besides you. Do you really want to build a product without ensuring that you’re meeting your target users’ needs? 30
32. Countering Typical Objections “We can just run a focus group or survey” Observing the people in context reveals details about workflow and motivation that focus groups and surveys can’t uncover. 31
33. How To Do Customer Observations Philosophical considerations 32 Practical considerations
34. Philosophical Considerations Open your mind Own your ignorance Ask open-ended questions Ask questions because you want to know the answer. Not because you want to show how much you know. 33
35. Practical Considerations Above all… decide what you want to investigate. It’s OK if you want to explore and look for problems to solve. But be explicit that this is your goal. 34
36. An Example Goals Statement During discussions with [client], we identified the following goals and constraints: Goals • Study and document current users’ workflows, and establish where [product] impedes workflow efficiency. • Uncover users’ wants and needs for increased workflow efficiency and data presentation. • Redesign [product]’s existing workflows where necessary, as well as design new workflows and features to better meet user needs and counter competitive threats. 35
37. Goals Statement With Constraints During discussions with [client], we identified the following goals and constraints: Goals • Study and document current users’ workflows, and establish where [product] impedes workflow efficiency. • Uncover users’ wants and needs for increased workflow efficiency and data presentation. • Redesign [product]’s existing workflows where necessary, as well as design new workflows and features to better meet user needs and counter competitive threats. Constraints • Do not “disconnect” from the installed base. The redesigned workflow, views, and normalized terminology must not put any training burden on the current user base or cause more than mild and transient disruption to current customers’ efficiency levels. • Wherever possible, preserve the existing shortcuts and accelerators. Some users of [product] use the application often, and have developed ingrained habits of use for certain common workflows. The redesigned application will to the greatest extent possible preserve the users’ means of interaction and workflow habits. • The application UI will be browser-based, OS-independent, and usable on a tablet form factor. The application will be entirely browser-based. It should be designed to work on the latest versions of the top 4 common browsers (IE, Chrome, Firefox, Safari). In addition, it should be usable at a tablet resolution of 1024x768 logical pixels. 36
38. Make A Project Plan You won’t regret it if you do. You will regret it if you don’t. 37
39. What Type Of Data Do You Want? Structured observations Record behavior using a coding scheme. “Participant entered transactions 7 times during her shift. Each took two minutes.” “Coded as workflow inefficiency.” 38
40. What Type Of Data Do You Want? Unstructured observations Just watch what’s going on. Ask follow-up questions in the moment. Looser, more conversational. You can code your observations later. 39
41. Recruiting Users Get access to real users, not the users’ bosses or internal SME’s. Seriously. They have to be real users. 40
42. Starting Your Observations You’re not going to feel prepared! That’s OK. Just go with the flow. 41
43. Collecting Your Data Use a format that works for you! 42
44. Summarize Daily Daily reports are your friend. And your team’s friend. 43
46. Resources For You Project planner - bit.ly/uxprojecttemplate 45
47. Resources For You Daily session recap template - bit.ly/uxdailyrecap 46
48. Analyzing Your Data Analysis: Break down into component pieces. Synthesis: Find patterns by looking across the pieces. 47 Affinity diagramming is a useful way to identify commonalities and trends.
49. Reporting Your Findings Reporting is really up to you. Research some reports! But be warned… people won’t read a giant report. 48 My big fat report that no one read…
50. Alternatives To A Big Fat Report 49 Stakeholder analysis session Gather the stakeholders. Present raw findings. Draw conclusions as a group. Pros Cons Stakeholders get involved! They may have valuable insights! Stakeholders get too involved. They may have HIPPO insights.
51. Alternatives To A Big Fat Report 50 “Interior decoration” Pros Cons Synthesize the data. Find suitable wall space. Get it up on the walls! It gets your insights out into the world. It generates interest in user research. It’s sometimes hard to convey detail.
52. Up On The Wall 51 https://userresearch.blog.gov.uk/2015/01/21/user-research-for-government-services-8-strategies-that-worked-for-us/
53. Agile Caveats Adjust for agile: user research is often “sprint zero” work. But it can also occur mid-cycle. You can do it quickly, but don’t always expect to shoehorn field research into a single dev sprint. 52
54. What About Remote Research? It’s better than no research! Drawbacks: It presents logistical challenges. You can’t see and touch the participant’s environment. 53
55. Resources For You Remote research tool comparison template - bit.ly/remoteresearchtool 54
56. Questions (and hopefully answers) 55
57. This presentation: bit.ly/field_research_sherman_uxindia17 56
58. Paul Sherman psherma4@kent.edu paul@shermanux.com @pjsherman Thank You!