This document discusses user observation research methods. It defines user observation research as observing customers in their real-world contexts to understand their goals, workflows, and how a product could fit into their behaviors. The document recommends observing users directly rather than relying on interviews or focus groups, as behavior is more truthful than self-reported accounts. It provides tips for planning an observation study, including defining goals, recruiting real users, collecting structured or unstructured data, summarizing findings daily, and adjusting the process for agile development cycles.

1. Field Research at the Speed of Business:
What, Why, and Some How
Paul Sherman
February 18, 2015

2. User Research
What
it is
Why
do it
How
to do it (intro)
2

3. User Research
The method goes by many names…
3

4. My Term
I use the term “customer observation” or “user observation” research.
It keeps the focus on two things:
The customer
Observing them in the real world
4

5. Use The Term That Works For Your Organization!
At a former company, we referred to it by two acronyms…
FMO FMH
Any guesses?
5

6. Whatever Works
“Follow Me to the Office”
“Follow Me Home”
Part of the UX practitioner’s job is to align the team and build user-centered
research and design activities into the product development life cycle.
Use words that resonate with your stakeholders.
6
UX

7. Whatever You Call It…
Customer observation is a method of understanding your target users’ goals,
workflows and context.
It reveals how they work (or play), why they do what they do, and how your
solution fits – or might fit - into their current patterns of behavior.
7
UX

8. Why Observe Users In Context?
Because Content Context Is King
8

9. Context Is King
Imagine you’re talking to some target users.
Where will you learn more about how they work?
Here? Or Here?
9

10. Why Observe Users In Context?
Because Behavior Doesn’tLie
10

11. Why Observe Users In Context?
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.
11

12. Why Observe Users In Context?
Bonus…
When you watch people
in context, you can ask
follow-up questions
about things that never
would’ve occurred to you
in a lab or meeting room.
12

13. Current Solution Or New One?
Most observation projects are run either to watch how people use an existing
product or service…
Or to identify how people currently perform an action…and assess whether
there’s an opportunity to provide a new product or service.
13

14. Typical Objections
The project manager:
“It takes too long.”
14
The founder: “We
don’t need to talk to
customers, I know
what they need.”
The marketer: “My
team can run a focus
group.”

15. 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.”
“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?
“We can just run a focus group.”
Observing the target customers in context will reveal rich details about
workflow and motivation that focus groups can’t uncover.
15

16. Want To See An Example?
16
(Video shown to attendees)

17. Here’s Another
17
(Video shown to attendees)

18. What are the chances I
would’ve learned as much if I
just brought those people
into a lab?
18

19. How To Do Customer Observations
Philosophical considerations
Practical considerations
19

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

21. Practical Considerations
Above all…decide what you want to investigate.
It’s OK if you just want to go out and look for problems to solve.
But be explicit that that’s your goal.
21

22. An Example Goal Statement
During discussions with [client], we identified the following goals and constraints for this effort:
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 typical (logical) tablet resolution of 1024x768.
22

23. Make A Project Plan
You won’t regret it if you do. You will regret it if you don’t.
23

24. What Type Of Data Do You Want?
Structured observations
Record behavior with a coding
scheme.
“Participant entered transactions 7
times during her shift. Each took two
minutes.”
24
Unstructured observations
Just watch what’s going on.
Ask follow-up questions in the
moment.
Looser, more conversational.

25. Recruiting Users
Get access to real users, not the users’ bosses.
Seriously. They have to be real target users.
25

26. Starting Your Observations
You’re not going to feel prepared.
That’s OK. Just go with the flow.
26

27. Collecting Your Data
Use a format that works for you!
27

28. Summarize Daily
Daily reports are
your friend.
28

29. Summarize Daily
Daily reports are
your friend.
29

30. Summarize Daily
Daily reports are
your friend.
30

31. Analysis and Reporting
Affinity diagramming
is useful to identify
commonalities and
trends.
31

32. Analysis and Reporting
Reporting is really
up to you. Research
some reports!
32

33. 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 expect to shoehorn it into a single dev sprint.
(Maybe two though!)
33

34. Paul Sherman
paul@shermanux.com
+1.512.917.1942
QUESTIONS AND CONTACT INFO