You are in San Francisco on a business trip. You are standing in a train station, and you thought you left yourself plenty of time to get to an important meeting, since you’ve never used the BART train before. However, you had trouble finding the station and you have just a few minutes before the train arrives. You jog up to the kiosk and start jamming your credit card into the machine in the hopes it will work like the one at home, but it beeps at you. “Please make a selection first” the screen to the left suddenly flashes, and shows a long list of possible tickets and cards to purchase, and you have no idea what any of them mean. Buckle up, it’s going to be a long ride.
If someone buys a ticket for the train at a terminal in the train station, it makes sense to study the design of the system in an actual train station, with a user who needs a ticket. The environmental factors (a line of annoyed people behind you, people rushing behind you to catch trains, low lighting, and the stress of being late) will affect the design in ways that cannot be replicated in a design studio.
People have remarkably terrible memories. They often don’t remember exactly what they did and certainly not in the detail of what you would need to understand a complex system. Unlike watching someone perform a task in usability lab, you watch them where the task actually occurs in the way it occurs, missed trains and all. As an observer, you get a sense of the entire workflow of a task—from locating the ticket dispenser, to attempting to cram a crumpled dollar bill into a machine, to finding the correct platform.
Conducting a field study involves watching someone do something in the environment they would normally do it. Field studies are best done at the beginning of a project where the team is looking for direction. They may be trying to figure out why users seem to be getting stuck (why are so many ticket-holders missing trains?) and are looking for ways to improve or redesign a project, or they may be looking to discover completely new opportunities. Watching someone through the entire workflow can uncover gaps in the system, misunderstandings, and creative user workarounds that the team would not have dreamed of from the comfort of their office.
The point of field study is to challenge assumptions and ensure what you are building will be adopted by users and help them achieve their goals. And yet, people in an organization often feel that field study isn’t necessary, is a waste of time, or is too expensive. These are some of the common pushbacks:
“We’re disrupting an industry/creating a new one, there is nothing to go see.”
Highly unlikely. There is probably some analog in place now; how do people accomplish their goal now? And if it really is that earth shatteringly new, use a prototype to elicit feedback; users may build their own analogies to things they already do, which will help the design team figure out a system that makes sense.
“I know what people do. I used to do it when I started the company 20 years ago!”
While it can be tempting to assume all users behave and think like we do, especially if we are users of the product, not everyone has the same experiences, technical expertise or goals that we do. This is especially true if the company has been around a long time; new (re:younger) users will likely have a completely different background and context that they bring to the table.
“We know what they do because they tell us in the support tickets.”
Support is often a great way to get insight into the issues users are having with a product. The support team can tell you what issues are arising with customers and to some extent how frequent they arise. The team may jump in with a fix—but the fix may be wrong, because people generally aren’t good at explaining what led to a problem and how that problem relates to their goals. The support tickets tell you who to talk to. Next step: ask to visit them.
“Why not use the research we already have from marketing?”
Marketers and business analysts tend to be focused only on the person making purchasing decisions, not the actual users. Even when the purchaser and user is one and the same, buyers do not equal users—they may purchase your widget, but if they aren’t a happy user, that does not bode well for the company’s future.
“That’s too expensive/time consuming.”
Do you want to find out that users actually don’t act quite how you anticipated when in their own environment? Last minute, pre-launch redesigns are not uncommon; companies put their products into the hands of real people in the real world only as a final check. That’s not the best time to discover that they didn’t take into account the fact that people don’t normally check the train platform number until after they buy a ticket, so putting that information before the turnstiles causes a lot of missed trains.
Field studies mitigate risk; they build confidence that your assumptions (aka, educated guesses) are accurate in the real world of a user.
For thorough information on conducting site visits and task and workflow analysis, checkout User and Task Analysis for Interface Design, by JoAnn Hackos and Janice Redish.