A few months ago I had the honor to appear on Design Details with hosts Bryn Jackson and Brian Lovin. I was, they said, the first anthropologist and first researcher to be on their podcast. Yay, thank you for the opportunity! But, guys, really, 159 episodes WITHOUT a researcher? Like I said on-air, you think design has a hard time getting a seat at the table, it’s even worse for us researchers. (Love you guys!).

Despite the chip on my shoulder and countless forays into pickling and spam (the meat kind), something resembling a coherent conversation around design and research emerged. Partly, I tried to make the case that every start-up and customer-facing product team needs an anthropologist on board. There are many reasons why, which I’ll unpack below, but if you want to understand your users anthropologists and design researchers from other disciplines can help you do that. Anthropologists study people and how they think, act, feel, and live in the real world. We do this through ethnographic field research, and spend time observing and participating in their worlds. We do not pull people into a lab or rely primarily on surveys and quantitative data. What people say they do can be very different than what they actually do. Data excels at identifying trends, but ethnography is suited to understanding WHY those trends are happening.

Cultural anthropology has a rich history in software and hardware development. Xerox PARC has perhaps mostly famously engaged anthropologists in its work. Yet, especially given current trends toward user-first product development, there is a big and growing need for anthropologists and design researchers. Humans are complicated creatures, and culture and context inform how anybody will relate to a particular design or technology. If you want to build effective products and experiences, connecting with users and working from a place of empathy and concrete insight is crucial. Anthropologists can build that foundation and help your team succeed.

Pied Piper has a Broken Flute

Let’s take everybody’s favorite start-up right now — Pied Piper. [Pied Piper, for those of you who haven’t seen the TV show, is the start-up featured on Silicon Valley, a comedy smartly satirizing tech and start-up life]. For 3 seasons we’ve watched CEO Richard Hendrix and team struggle to build and release their platform featuring their ground-breaking “middle-out compression algorithm”. Its been a tense yet hilarious journey, they always seem just poised for success when there’s a setback. Toward the end of season 3 though, finally, they launch Pied Piper and all seemed successful. As a viewer, I relaxed. Jack Barker was out of the picture. Download rates were massive. And for the first time Gilfoyle and Dinesh were acknowledging their bro’mance. All was well. They made it, I thought.

 

But they didn’t make it. Testifying to the powerful promise of Pied Piper, initial download rates were respectable as a high number of people were drawn to try the platform. But very few ended up consistently using it. Here we were yet again faced with their prospect for failure. Which, hey, I guess that’s okay. Success=Failure right? Not always, failure can be failure. Even Gavin Belson at Hooli had to reckon with that.

Lacking any comprehension of the disparity between download rates and daily average users, they turned to a market research firm for some quick hit insights. Through a handful of superficial focus groups they found there was utter confusion and frustration with the platform. Users couldn’t tell what Pied Piper did, much less use it. The algorithm and architecture might have been great, but the experience was awful, leaving the promise of middle-out compression tech ultimately unfulfilled. In short, Pied Piper didn’t deliver.

Our beloved CEO, peeping from the other side of the lab’s 2-way mirror during the focus groups couldn’t believe it and whined out, defensively, “Clearly, none of these people get it.” I have heard this before and have had to struggle with it in real life. There really is nothing worse than having your basic assumptions and hard work rejected, but the problem here is not with the users. It is with Pied Piper’s development process that led them to build a platform without any real research or user feedback loops. The users were fine, it was the team that didn’t get it.

Reeling from the focus group’s negative reaction in the lab, Richard and Monica continued to hash it out:

Richard: Okay, well, everyone that I showed the beta to loved it.

Monica: Who did you give the beta to? Your friends, engineers?

Richard: Well, yeah, Monica. I wanted to give it to people who would understand what I’m trying to do, so I could get useful feedback.

And with all due respect, I gave it to you, the one person without a computing background, and you said it felt engineered…. Oh, shit.

Monica: Yeah. You’re trying to sell the platform to regular people, but you never actually put it in the hands of regular people.

The mistakes made by the team here are obvious. The Pied Piper team didn’t step out of their echo chamber, and ultimately failed completely to understand the values and expectations of their potential users. They didn’t design with them in mind. Consequently, the team’s enginneer’y values and assumptions, explicit in the platform, were completely irrelevant to everybody else.

This is a fictional anecdote, but it’s not really that far from the (self-inflicted) problems that so many have faced in software development. Like, I imagine, every other researcher out there watching the show , I thought to myself, “man, if they only had a researcher on board this could have all been avoided…”. What if they did have one? What if they had an anthropologist?

Appealing for deep understanding and context, an anthropologist could have explored not just the problems users struggle with in connecting their devices and content but their hopes and wants in that pursuit as well. What do people want to share? Why? With who? How? What are their points of reference now for doing that? Ultimately, you’re asking about people, communication, and relationships. Answering these questions and generating empathy and emotional connections just isn’t possible in a lab, through a survey, or a few market research focus groups. You need a researcher that can connect with people, spend time with them in their context, understand what’s meaningful, and then work with the team to build empathy, implement research insights, and create sustainable feedback loops. Otherwise, there’s a real danger that the sexy promise of your middle-out compression algorithm will fall flat. If your flute is broken, you’ll end up with no followers.

This leads us to a point that cannot be stressed often enough — technology is cultural and all software is baked with certain values and premises. The question becomes then: do you want to build software that reflects the worldview of your startup or team and aligns with their expectations (especially if your team lacks diversity)? Sometimes, rarely, that answer might be yes. Or, would you rather build software and products rooted in the values of your end-user(s)?

Build software and products rooted in the values and expectations of your end-users and not your own.

So now, as I personally wait with bated breath for Season 4, the team is having to deal with a very expensive and difficult problem. If only they had invested in an anthropologist. It is always so much easier and cheaper to build the right product with rich user knowledge and feedback than to release a dud and iterate from there. If you even get that chance at a re-design, there might not be any resources or life left.

Mixing Lean and Design-thinking

Pied Piper is great fictional fun, but what about in real life? As part of my current work with InVision I spend a great deal of time with design and product teams. I’ve noticed that quite a few are struggling with Lean methods. Lean favors nimble experimentation and iteration, favoring releasing the software early and iterating with feedback. Releasing early and often, the process entails crafting a hypothesis, testing, learning, and iterating. Speed is key, occasional failure is expected, and openness to new directions and pivots is fundamental.

Lean, in the form of agile and scrum-focused processes, is the dominant form of software development. There are a few key problems teams are struggling with, however. One, there is no substantial focus on discovery and learning prior to engineering (see Mike Davidson’s recent piece on Learnings). Many are beginning to feel that they need more space upfront to define problems and experiment with potential solutions before moving into engineering. Two, there is a desire to ground product development, especially the discovery and definition work, in the user, in people. This entails a different form of research.

In theory, user feedback is central to Lean methodologies. Driving iteration, concepts are supposed to be tested and validated (or invalidated). Yet, first of all, in practice — perhaps given the emphasis on speed, iteration, and release — user feedback often seems to take a backseat. How many start-ups do you know that hire a researcher on day 1? Day 300? How many designers out there feel they get adequate time to do their own research? Rather, with everyone running full speed on a “let’s ship!” hamster wheel, it seems like feedback is often relegated to gauging user reactions at release. So, too often it’s build/ release/ gauge reaction/ repeat and rinse. This can be a dangerous way to design and build software, as Pied Piper learned.

Secondly, and importantly, there is a fundamental difference between the UX research that accompanies Lean models and the kind of user-centered approach that many are either undertaking or craving. Research is not the starting point in Lean, and does not generate a deep, contextual understanding of the problem space and the people involved you’re trying to address. The user, in short, is not the point of departure. Context and empathy do not ground projects and drive product development — leaving an opening, or void, for teams like Pied Piper to build products steeped in their own values and assumptions.

Consequently, I’m noticing teams hungry for user-centered discovery and development merging Lean with design thinking methods (from companies like Optimizely to IBM to InVision where we are spending time and energy building discovery-focused processes). Design thinking is often described as a “human-centered approach” to solving problems and creating new ideas. Elevating research and design, it privileges deep understanding, context, and empathy with the problem and those involved. Conceptually, everything flows from and is grounded with the user. It is a user-first approach, rather than feature-first.

This is undoubtedly fueled in part by more and more companies competing on the basis of customer experience, as a recent Gartner survey stated. Many feel user-centric approaches will enable them “to substantiate everything with the user voice, 100% of the time, to build the right thing”, as one design manager at an iconic tech startup told me. Signaling the discomfort many have with Lean, it appears that many lack confidence in their processes to build the right thing and produce desired outcomes.

Yet, its important to note that teams are not entirely moving away from Lean but mixing in user-centered approaches to create discovery and delivery stages of product development (see for example Double Diamond design models and Marty Cagan’s Dual-Track Scrum). This shift however, deeply affects research roles and expectations. Validation research continues to have an important role, but there is an emerging need for researchers skilled at grappling with the nuance of people and problem spaces. Focusing more on discovery research, on building connections to users, and on generating deep questions and knowledge, teams need those fluent in designing and conducting human-centered research. Anthropologists with their toolbox of cultural theory and ethnographic methods are uniquely suited to this task. Here is why.

1. Problems are people problems. Cultural anthropologists excel at connecting with people and unpacking the intimate, complex frameworks of our lives. These skills can be (and have been) readily applied to understanding problem spaces, to deciphering what users value, and divining whether potential solutions might resonate.
2. Cultural anthropologists invented and pioneered ethnographic, field research methods. Conducting research where people live, work, eat, and breathe produces invaluable insight that lab-focused work cannot. Supporting a process of discovery, anthropologists in the field can learn much about people, context, and make connections that they themselves do not know or fully understand.
3. The concrete, detailed knowledge of actual people that anthropologists produce is much more valuable than personas. Personas are vague, abstract, and as John Maeda argued in a soon-to-be-released interview with InVision, they are a disservice that creates a distance between teams and users. Personas (like “Tom Soccer Dad”) are works of fiction loaded with imaginative (probably stereotypical) assumptions. Only through entering the worlds of soccer dads can you really understand what makes them tick.
4. Ethnographic methods are flexible and can utilize any given mixture of qualitative and quantitative methods, depending on the problem at hand. Ethnography, while grounded in fieldwork, is never rigid in its approach. Rather, it should always be informed by the unique perspectives, experiences, and skills, of everybody involved. And I mean everybody — researchers and participants. A good ethnography is inherently collaborative. It is a creative undertaking, drawing on the resources, skills, and personalities involved to create something unique. You are always building research (and ultimately solutions) tailored to the problem at hand.
5. Anthropologists have a long-standing commitment to developing and working through empathy, a key tenet of user-first approaches. Emotional, empathetic connections to users are fundamental to building experiences that resonate and matter and anthropologist are expert at this.
6. Cultural anthropologists are trained to focus on difference, rather than universals or generalizations. That is, value lies in understanding what is unique, special, and relevant about a community or group of people. What does Facebook mean to white, middle-class American grandmothers? What does it mean to their grandkids? What does it mean to 14 year olds in Belarus? They will have entirely different ideas about the value and experience of the platform. Understanding the unique qualities of users is incredibly valuable for product teams.
7. Anthropologists are trained to set aside assumptions and pre-conceived notions about a research topic and view a given issue with an outsider’s eye so to speak. In other words, we are skilled at de-centering our thinking to explore the phenomena at hand from the user point of view as much as possible. This way of perceiving and thinking about the world can help any team challenge its assumptions and understandings.
8. We offer not just observation, but interpretation. Anthropologists possess a cache of case studies and cultural theory that help produce key insights. Our conceptual training and toolkit can also broaden and deepen the questions, approaches, and ideas surrounding the problem at hand.
9. With a research practice steeped in ethnography, flexibility, empathy, and difference, anthropologists are suited to working with the intuitive, emotional approaches of many designers. This, in my opinion, is key. I have seen too many user experience researchers struggle to rigidly assert “their science” in diametrical opposition to fluid, intuitive design processes.
10. Anthropologists have long worked to give voice and representation to their ethnographic subjects. Such skills are central to representing users to the team, and ultimately elevating the importance and influence of users in product development.

 

Conclusion

Too often decisions are made in software development before problems are properly understood. Too often, as teams fail to engage users product work is guess work. There is a growing anxiety around some of the shortcomings of Lean, but there is also anxiety in moving toward discovery-led processes. Some fear that a focus on discovery will slow the team down. Some see it as a waste of resources through spending too much time and energy on prototyping solutions — throw away code?! Some see research as academic, obtuse, and rigid — a threat to flexible, fast-moving product development.

User-first or customer-driven models though, can not only generate successful experiences and products, but just as efficiently. Committing to a strong research foundation is key. The right kind of research and researcher can help build a process that is not only effective but also iterative and rapid. As I’ve argued here and in other posts, research can and should achieve a few things. Deep knowledge of a problem space is fundamental, and will help establish the empathy and guiding principles needed to ground design and user experience. Of equal importance, ethnography can establish connections to users and fuel rich, iterative feedback loops.

There is no reason to think the process will slow down. In fact, if a team is willing to engage the right researchers and make users meaningful partners in product development, they can make decisions more quickly, with more confidence, and move forward faster without having to go back and rethink key assumptions. No wonder then, that Phil Gilbert, general manager of design for IBM, recently stated that: “The design researcher has been the most disruptive of the design disciplines we’ve brought in — and by far the most transformative.” Indeed. Hug an anthropologist today!

[Note: I have argued that cultural anthropologists are uniquely suited to meeting the needs of the trend toward user-first product development. It is a bit polemical (and perhaps self-serving), but I wanted to use cultural anthropology to tease out what I think are key criteria for a user-first research. There are a number of other disciplines prominent in design research. For example, human-computer interaction, sociology, and Stanford D-school programs embrace key anthropological tenets like ethnography and empathy and are central to contemporary design research. And by no means is qualitative research the only component of a user-first research project. A well-rounded design research program should involve qualitative and quantitative researchers working together to understand any particular problem or phenomena from different angles.]