Focus Groups to Study Work Practice

Usability Interface
Focus Groups to Study Work Practice

by Meghan R. Ede
HCI Solaris Software, Sun Microsystems, Inc.
Reprinted from Usability Interface, Vol 5, No. 2, October 1998

Focus groups are a good, fast way to learn about the work that occurs "between" or "around" the tools we build. They can provide insights about work that spans hours, days, or even longer periods, and reveal interactions between people, tools and processes. Focus groups are a good complement to other usability methods because they provide information that would be very difficult or more costly to study directly.

My definition of focus groups is very broad. I consider focus groups to occur whenever a group of people are invited to participate in a moderated discussion on a specific topic. I usually use focus groups very early in the design, to better understand potential users of a product or service. This differentiates usability focus groups from marketing focus groups, which often seek to learn reactions to a finished product. Focus groups differ from usability studies in that the participants are not asked to use a product. They differ from participatory design sessions because the participants are not asked to contribute or comment on design ideas. In a focus group, all I want participants to do is talk.

I usually start a focus group by asking people to tell me about their day. I encourage the other members of the group to record the speaker's activities on note cards so that I can concentrate on asking good questions. Everyone is encouraged to speak. Then I help the group sort and discuss the note cards. My methods for sorting the cards vary depending upon the main goal of each study.

I once ran a series of several focus groups with System Administrators. When I first asked them what they did, they said things like: install, upgrade, oversee, and troubleshoot XX Operating System. Their work sounded very technical, as if they spent most of the day in front of a computer.

When I next asked them to tell me about their last full day at work, starting with whether they had a cup of coffee in the morning, their answers were very different. They all launched into stories about how they couldn't drink coffee because they would be accosted on the way to the coffee machine with requests for help. Most of them carried notebooks to record end-user problems. They talked about telling users over and over again how to do the same simple tasks, like change passwords or screen backgrounds. They talked about training courses and surfing the web, being paged at home, and reading technical books in bed. They read incessantly, news groups, bulletin boards, whatever they could find, in the hope of finding answers to problems not yet encountered.

When we had the note cards sorted and discussed, the System Administration job was revealed as a job dealing largely with people, education, research and somewhat with supporting a computing environment. Almost a completely opposite picture from what they first told me.

I could never have learned this in a usability study (which asks if a specific tool does its job well) or in a survey (few System Administrators realize how much time is "lost" to answering unofficial questions). A customer visit would have taken days or weeks, not hours, and wouldn't have covered such a broad range of companies and positions.

Note: This article is also available on Jakob Nielsen’s web site: http://www.useit.com/papers/meghan_focusgroup.html