Field research answers the question, “Who are our users and what are they trying to do?”
A field study focuses on the big picture: how people currently solve their problem. With field research, you examine the workflow across multiple channels and observe user behaviours, needs, goals and pain points. Field research is fundamentally outward looking: your aim to find out what’s happening in the real world.
The typical research location is a participant’s home or workplace. You’re looking to discover how people achieve their goals right now, before your system has been built or invented. What problems do users face? What needs do they have? What are their skills and motivations?
Lean Startup researchers characterise this as ‘getting out of the building’ — but getting out of the building isn’t enough. A field visit is much more than a pop-up user interview in a coffee shop. To use the analogy of animal behaviour, an interview is like a visit to the zoo whereas field research is like going on safari. With field research you observe real behaviour: you see what people do, not listen to what they say they do. In short, you go where the action happens.
Without field research, you’re designing in the dark. With field research, it’s like someone has turned on the room lights.
To use the language of Lean Startup, field research helps you validate (or invalidate) the problem hypothesis. Is the problem that you’re trying to solve for users really a problem? Design teams often experience a kind of groupthink where they believe they are solving a real user need — but in fact few users are bothered by the problem. One of my favourite examples is the connected kitchen from Hoover. When I discuss this with people, most people agree that it would be cool to have your washing machine send you a text when it has completed its cycle, but ‘cool’ doesn’t necessarily mean useful.
The Hoover Connected Kitchen project promises to network your kitchen appliances. It's cool but is it solving a user need?
The other issue you’ll uncover with your field visit is how serious a problem this is. Some problems aren’t so serious for people that they are willing to spend time or money solving them. You may have discovered an itch, but a field visit will show you if your customers are happy with their current way of scratching.
Usability testing answers the question, “Can people use the thing we’ve designed to solve their problem?”
A usability test focuses on how people do specific tasks and the problems they experience when using a particular system. Traditionally it takes place in a lab, but in practice it can take place anywhere (including the field). Typical research locations include:
- A participant’s home or workplace.
- Public spaces, like coffee shops and libraries (so called ‘pop-up research’).
- Research studios or labs.
- Meeting rooms
- Your desk (using a laptop or phone for remote research).
Usability testing is fundamentally inward looking: you give your users a prototype and a set of tasks and you see if they can complete those tasks.
The key difference between a usability test and a field visit is that with a usability test you’re evaluating a specific design idea with your users. If a field visit is like turning on the lights, then a usability test is like looking under the microscope. Field visits give you the big picture whereas a usability test lets you evaluate a specific solution.
To use the language of Lean Startup, a usability test helps you validate (or invalidate) the solution hypothesis. Does your proposed solution work?
Should I run a field visit or a usability test?
Field visits and usability tests are complementary research techniques so you need to do both. A field visit tells you if you’re designing the right thing. A usability test tells you if you’ve designed the thing right. For example, your product might perform fine in a usability test but it will fail if people don’t really care about the tasks you’ve asked them to complete.
Your choice of method depends on where you are in your development lifecycle.
If you’re in the discovery phase, you should be carrying out field visits to turn on the lights. This is because you want to answer the question, “Who are our users and what are they trying to do?”
Once you’ve understood the problem, it’s time to get out your microscope and usability test your design solution with users. This is because you want to answer the question, “Can people use the thing we’ve designed to solve their problem?”
In summary, you simply need to ask two questions:
- Is there a user problem to be solved? (If unsure, carry out field research).
- Have we solved it? (If unsure, carry out usability testing).
About the author
Dr. David Travis (@userfocus on Twitter) is a User Experience Strategist. He has worked in the fields of human factors, usability and user experience since 1989 and has published two books on usability. David helps both large firms and start ups connect with their customers and bring business ideas to market. If you like his articles, why not join the thousands of other people taking his free online user experience course?
Love it? Hate it? Join the discussioncomments powered by Disqus
Foundation Certificate in UX
Gain hands-on practice in all the key areas of UX while you prepare for the BCS Foundation Certificate in User Experience. More details
Every month, we share an in-depth article on user experience with over 10,000 newsletter readers. Want in? Sign up now and download a free guide to usability test moderation.
User Experience Articles
Our most recent articles
Our most commented articles
Search for articles by keyword
- 7 articles tagged accessibility
- 4 articles tagged axure
- 5 articles tagged benefits
- 16 articles tagged careers
- 8 articles tagged case study
- 1 article tagged css
- 8 articles tagged discount usability
- 2 articles tagged ecommerce
- 17 articles tagged ethnography
- 14 articles tagged expert review
- 2 articles tagged fitts law
- 4 articles tagged focus groups
- 1 article tagged forms
- 6 articles tagged guidelines
- 11 articles tagged heuristic evaluation
- 7 articles tagged ia
- 14 articles tagged iso 9241
- 11 articles tagged iterative design
- 2 articles tagged legal
- 11 articles tagged metrics
- 3 articles tagged mobile
- 8 articles tagged moderating
- 3 articles tagged morae
- 2 articles tagged navigation
- 9 articles tagged personas
- 15 articles tagged prototyping
- 7 articles tagged questionnaires
- 1 article tagged quotations
- 4 articles tagged roi
- 17 articles tagged selling usability
- 12 articles tagged standards
- 47 articles tagged strategy
- 2 articles tagged style guide
- 4 articles tagged survey design
- 5 articles tagged task scenarios
- 2 articles tagged templates
- 21 articles tagged tools
- 56 articles tagged usability testing
- 3 articles tagged user manual