An Ethnographic Approach to Software

Kelly Moran, @Kel_Moran
Senior Design Researcher, projekt202, https://projekt202.com/

Ethnography claims its roots from the field of anthropology. How can a method used for such a seemingly exotic purpose be useful in the modern world of software design? Revealing and most importantly understanding user needs requires sensitivity, empathy, and a disciplined approach - all of which can be found within ethnography. This paper will outline the basic components of an ethnographic perspective, demonstrate the use of ethnography in user-centered design research, and highlight how the impact of this research ripples through the software development process.

There is a story they used to tell new US Peace Corps volunteers during their initial training. Imagine two tribes living on an island. One tribe wears blue lenses and sees everything in shades of blue. The other tribe wears yellow lenses and sees everything in yellows. The two tribes don't get along very well, since they see things so differently. One day, a member of the blue tribe gets an idea. She decides to put on a pair of yellow sunglasses and observe the yellow tribe to see things the way they do. She returns in a week and her fellow members of the blue lens tribe eagerly inquire what it was like wearing the yellow lenses and seeing things in the way of the yellow lens tribe. The adventurous blue lens member exclaims, "It was so amazing - everything was green!"

This narrative points out a primary principle of ethnography, and that is the acknowledgement that everyone views the world through their own lens. Recognizing this lens, and that it carries with it your own unique internal biases, assumptions, and understanding of the world in general, is a critical part of the ethnographic perspective. There are several critical components to understanding what ethnography is, all of which are important when applying this outlook to software design and development.

What is Ethnography?

This buzzword has made its way from the academic halls of the social sciences, through the varied landscapes of fieldwork, shaken up the world of organizational behavior, and landed firmly in user-centered design research where it is often applied to software. A basic definition of ethnography is a study of people and cultures, but it should be noted that ethnography is both a process and a product. You "do" ethnography to produce "an" ethnography - meaning you use a special set of methods and philosophies to create a written piece of work that describes and interprets a culture or way of life. When "doing" ethnography, the process is not one specific method. Instead it is an approach to conducting research and as such it can utilize a variety of methods. These methods can include participatory observation, contextual inquiry, semi-structured interviewing, and many others. In order to take an ethnographic approach to understanding a group, such as the population that makes up the users of your software, there are three key factors to keep in mind.

Key Factors in Ethnographic Research and Their Application to Software

1. Description

One of the first requirements of an ethnographic approach is to focus on qualitative, or descriptive, data. While quantitative, or numerical, data can provide a good supplement to ethnographic research, the focus here is on description. The prominent anthropologist, Clifford Geertz, has called for ethnographers to aim for what he described as "thick description." Thick description means providing not just the procedural or step-by-step actions being observed, but also the context surrounding those actions. His classic example is the wink. An account of a wink which does not meet the requirement of being thickly descriptive would be something like "the closing and opening of one eye." However, recounting that you saw Participant A close and open one eye while looking at Participant B does nothing to explain what happened. Someone may close and open one eye in order to let someone else in on a joke, or to flirt with that person, or they may just be trying to blink a piece of dust out of their eye. By omitting the thick description surrounding the act of winking - what happened before and after the wink, the recent history of the two actors, the reactions of any other people observing the action - you risk misleading your audience. By saying only, "Clara winked at Robert" you leave interpretation up in the air, with potentially inaccurate results.

The need to provide thick description when studying users of your software is just as important as in any other ethnographic research. If you only report to your team that you saw people use the printer a lot, but you do not provide information on what was happening at the time or what they were doing with the print-outs, it leaves little to work with when creating solutions. When you research your users and how they interact with your software you have a responsibility to provide data good enough to interpret their actions in a meaningful way.

2. Context

Closely related to the need to provide thick description in ethnographic research is the absolute requirement that the research be conducted in context, or in the environment, of the people being studied. This is often referred to as field work. Laboratory experiments, while useful and valid as way to test scientific hypotheses, are not ethnographic. By observing, interacting, and interviewing with a research population in their own environment you both literally and figuratively meet them where they are. They are in a space where they are the experts and you are there to learn from them. This can be a humbling experience, since as the researcher you may initially know very little about how things work in this environment. This is the exact environment though where, in the case of software design and development, you will want your software to function optimally. Allow the research population to help you understand this environment. More on that later.

I want to take a moment to make it clear that the ethnographic requirement of visiting the environment in order to understand your users does not prohibit the use a lab setting to test your software later. It just means that while you are figuring out what to build or how to greatly improve something that is performing poorly, the context of the users is more important than the controlled atmosphere of the testing room.

Application to Software - Context and Description in Action

In a recent project researching how to make professional accounting software more efficient, developers reported that users frequently complained attaching files took too many clicks. This was confusing to the developers, because there were only a few clicks involved in the process. By visiting the accountants, my research team saw that the files they needed to attach were buried in layers and layers of folders, which was a result of the complex organizational work they had to do. Aside from just being complex their work also required a high level of accuracy, since millions of dollars were involved. With complexity and accuracy both at work the users wanted to open and review a file before attaching it, to make sure it was the correct one. This meant that first they would click folder after folder to open and view the file, and then in the software they would drill down that same path to attach the same file. While we could not eliminate the problem of complexity within each accounting department, we could support the need for accuracy and reduce the number of times the accountants needed to drill down through the files by letting them drag and drop instead of browse and select. Only by visiting the users in context and in describing their actions and motivations could we help developers provide a solution to a problem they could not understand from their desks.

3. Shared Perspective

The final key factor in using an ethnographic approach is incorporating both the participant and the researcher perspective. In anthropology the participant perspective is called the emic perspective, and it involves understanding how the group being studied sees, feels, and experiences their world. Remember the blue lenses and the yellow lenses? The blue lens wearer got close to understanding what it was like to be a yellow lens wearer, but could have learned more with interaction and interviewing added into her observations. This would have helped her understand goals and motivations - both important pieces of the emic perspective. Once these are uncovered the viewpoints of the participants are then blended in with the insights and interpretations of the researcher. This outside viewpoint is referred to as the etic (instead of emic) perspective, and in software design and development it provides the balance that is needed to make a project successful from a strategic business vantage point.

This need for shared perspective means that good ethnography is both participatory and inclusive. In software design research, including user types of various roles, as well as subject matter experts (either inside or outside the software company) and internal stakeholders is the recommended way to ensure that all perspectives are considered. Listening to the users does not just mean giving them what they ask for, it means making the effort to understand their wants and needs and finding ways to meet those wants and needs in appropriate ways.

Application to Software - Blending Shared Perspectives

By automating the process of submitting legal documents to the court house, a software development company was able to eliminate the time lawyers had previously spent physically delivering those documents in person. The software company was sure they were providing a high value product by giving time back to lawyers. Some lawyers and their support staff however were disappointed with new system. They said it wasn't really faster. When the software company decided to send a research team to observe and interview lawyers, they were admitting that they lacked the perspective to understand the problem. My research team discovered that lawyers and their support staff were annoyed that by using the electronic submission process, they no longer knew which court staff person was reviewing their documents or why certain documents took longer to reach the judge. From the user's perspective, the process was unfriendly, unclear, and unhelpful in the case of submission errors. In fact, when errors occurred it could now take days to correct them - much more time then it took to physically deliver and correct errors at the courthouse. The research team helped the software company blend the user viewpoint with their own business perspective and we created a status tracking system that let users see when the court opened the submitted files, which court staff member was reviewing them, and when they reached the judge. The group is currently working on making error messaging clearer and more helpful.

A more entertaining example of including the participant perspective while blending in your own expert insights comes from the animated sitcom, The Simpsons. In one episode, Homer, the patriarch of the family, is granted the opportunity to design a new car. He works for weeks with the engineers, and they are told by their boss to listen to everything he says. The resulting car is a malformed disaster and the car company suffers financial ruin. The engineers' mistake was not in listening to the user, it was in not listening enough and then applying their own expertise. For instance, Homer put a glass bubble in the back of the vehicle for his kids, which made the car ugly - not to mention unusable for anyone with small children which require close monitoring. Homer put the bubble on the back so he wouldn't hear the kids arguing. A better, and safer, solution might have been an in-car entertainment system or some other creative way to keep the kids out of trouble.

Review

The three key factors of qualitative description, environmental context, and shared perspective are closely interrelated. They all require paying close attention to your users and being willing to put yourself into the position of listening, instead of telling them how they're doing it wrong. Additionally, in order to achieve any of these requirements you must first have the desire to understand the users of your software. It can seem challenging to get started. I will leave you with a few tips for getting started.

1. Ask for help. Let your users know you want to learn from them. They will be more welcoming if you approach them this way then if they think you are there to correct their behavior.
2. Use an emergent research plan. A plan that can change and develop over the course of the project is an acceptable and common part of ethnography. Go out and start learning. Adjust as needed.
3. Set aside your current assumptions. Whatever you think is happening out in the world with your software, clear that out of your head and start looking at everything like it's unknown territory. This is the surest way to generate new insights.
4. Listen actively. Take note of their ideas, and ask them "What problem does this solve?" Their idea may be silly, but it came from a place of frustration, and that was the best solution they could come up with. They aren't software experts, so they did they best they could.
5. Give something back. Your users (research participants) are giving you something, so be sure to return the favor. Honor the idea or reciprocity.

References

Geertz, Clifford. The Interpretation of Cultures: Selected Essays. Basic Books, Inc. (1973) 470pp.

Hoey, Brian A. "A Simple Introduction to the Practice of Ethnography and Guide to Ethnographic Fieldnotes" Marshall University Digital Scholar. (2014): 1-10.
Available at: http://works.bepress.com/brian_hoey/12

Salvador, Tony; Genevieve Bell; and Ken Anderson. "Design Ethnography," Design Management Journal. (1999) (pp. 35-41). p.37

---

Related software design articles

The Psychology of UX

The Psychology of UX - Part 2

Experiential Learning: What Does it Have to Do with Agile?

---

Click here to view the complete list of archived articles

This article was originally published in the Fall 2015 issue of Methods & Tools