If you’ve ever done the d.School Wallet Project, or any of the other introductory design sprints, you’ll know that the design thinking process starts with Empathy. For this 90-minute project, you develop empathy by interviewing your partner and asking them about the contents of their wallet or purse in order to design a better one for them. Why is empathy important? The d.School Method cards explain:

You want to understand a person’s thoughts, emotions, and motivations, so that you can determine how to innovate for him or her. By understanding the choices that person makes and the behaviors that person engages in, you can identify their needs, and design to meet those needs.

So far, so good. For this wallet project, an interview with the single person you’re prototyping a solution for makes complete sense. However there are a few reasons this approach doesn’t work well for most real-world projects:

1. Most products aren’t for a single person; in fact, design usually requires balancing a complex set of needs, many of which are contradictory.
2. Many users aren’t quite as easy to access as the student sitting next you in class.
3. Interviews are a very narrow way to define empathy, and empathy is a very narrow way to define the benefits of user input.

I’ll explore each of these issues below.

1. Needs are a complex thing to define

In my work, I constantly balance the needs of multiple stakeholders, along with the technical limitations of our software and regulatory limitations of the medical space. Let’s take a seemingly simple project of how to add a button to a website for ordering a prescription DNA test (it wasn’t scoped quite this way in real life, but that’s the gist of it). Let’s examine how a typical design process would go as I identified the needs of one group of users that my product should solve.

First, I would identify some people in my target demographic (including some “extreme users” like people in the Quantified Self movement who track lots of data about their health, or prospective parents who refuse to do genetic testing). After interviewing a handful of users, I would develop a Point of View statement, composed of three parts like this:

• User: A man or woman who is planning to start a family
• Need: wants to find out information about their DNA before having a child
• Insight: and believes requesting a kit online will avoid the hassles of scheduling a visit to their doctor.

Finally, I would work with a diverse team to brainstorm possible interventions before quick prototypes with hand sketches or Balsamiq mocks. I’d take these prototypes back to users, get their feedback, and iterate.

In the context of a classroom or consultancy, where one has the luxury of designing from scratch and doesn’t need to contend with final implementation, this approach makes a lot of sense. However, in-house designers can’t abstract away the complexities of a shipping product.

In actuality, adding this button and the related workflow involved the following stakeholders:

1. Consumers seeking to be tested
2. Doctors and the clinic office managers who sign off on requests
3. The client services team that works with patients
4. The in-house sales team that calls clinics to complete the authorization process
5. The field sales team that supports and services clinics in-person
6. Software developers who build the software to support and scale inquiries
7. Our legal team, who ensures compliance with HIPAA and other regulations

If I were to try and diagram it, the web of stakeholders would look something like this:

Each stakeholder has different concerns and needs to balance. For instance, a software developer may say that something you want is impossible, or say that it is possible but would require tradeoffs you aren’t willing to make. Sales people may want to visit every clinic in-person to ensure a smooth experience, whereas doctors are so busy they don’t have time to do much more than authorize an order. Balancing opposing needs requires patience, and the persistence to keep tweaking the idea until you find a version that satisfies the needs and wants of all stakeholders.

2. You’re not designing for the person sitting next to you

Simple design exercises generally focus on interviewing and designing for someone who’s easy to access (often a fellow student). I wish it were always so easy to talk with a user!

Perhaps my perspective is skewed because I deal with very specific populations (doctors in the reproductive space, women who are trying to conceive, etc.) but it’s not always easy to track down a specific user type, simulate the mindset of an actual patient going through a process that stretches out over weeks or months, or find people willing to share their private health information with a stranger. It’s not just patients who are difficult to access. Doctors may be completely unwilling to engage. They’re busy, and why should they be bothered? What’s in it for them? Sometimes I’ll get lucky and there will be friendly doctors who are willing to share their opinions, but I can’t count on being able to interview a few doctors every time I want to make a change to the website.

Given the limited access to users, and the fact that interviewing can take a lot of time that I just don’t have, I’ve found it’s important to be open-minded and resourceful in understanding the human aspects of the problems you’re solving. Fortunately, having a product gives designers access to a ready pool of options they wouldn’t have when starting a project from scratch.

Here are ways I get product feedback, beyond the usual ethnographic interview approach:

1. Support teams! They’re a fabulous resource for knowing all of the different ways your product is broken. Support teams are the eyes and ears of an organization, and more than once I’ve found myself sharing a surprising insight with them, only to have them respond “oh yeah, we hear that all the time.”
2. Fellow employees. During a major site relaunch, I invited coworkers from different parts of the company to give up their Saturday and get a sneak peak of our new features. Fresh eyes always find new bugs or usability issues. Always. As a second endorsement of support teams, I often share new designs with them to critique, since they know all of the ways users get confused, and all of the crazy things they try and do.
3. “Dogfooding” This loosely means using your own product. After a number of people at the company went through screening, we surfaced a number of issues we either hadn’t been aware of, or hadn’t prioritized. For instance, we’d always heard complaints about how hard it was to write on our saliva tubes, but after trying to do it ourselves we realized how critical the issue really was.
4. Google Consumer Surveys. I’d been trained that ethnographic interviews are the gold standard of research, but have found that surveys have their place — I’ve found they’re good for getting a pulse on the mental models of the general population. (I’ll talk more about using Consumer Surveys as a design tool in a future post.)
5. Satisfaction surveys. I know they’re not sexy, but gosh are they useful. If you’re lucky enough to work on a product with existing user, leverage them! If your company doesn’t already do these, try and get them started.
6. Data. You know, like good ole’ Google Analytics and other usage metrics. My company also uses Salesforce, which has more dashboarding options than you can shake a stick at. Depending on how your company stores data, you may want to brush up on your command line skills or else find a friend who’s handy with database queries.
7. Phone calls. While in-situ observations are a rich way to gather data, phone calls can also be useful. For one, they’re easy to to do, simple to record, and fairly cheap to transcribe (I recommend services like Verbal Ink if you’re doing a lot of interviews; in the long run it’s a lot cheaper than wrist problems from too much typing). An added benefit of phone calls is that you can talk with people (in my case doctors and patients) who live all over the country, rather than relying on the ones who happen to be local (or budgeting thousands of dollars and a lot of time for travel).
8. Ride-alongs. This one is particular to companies that have field teams. The company I work at has a national sales team, and I make a point to join the local rep for a day when I travel. I usually spend most of my time during sales calls quietly observing what’s going on, and pick the mind of the rep as we’re driving around town. Like the support team, they can aggregate feedback from dozens or hundreds of users, and flag issues that may warrant more attention.

It’s not that I don’t do ever do ethnographic interviews, but they’re few and far between. When it comes down to it, I would wager that more than 95% of product feedback I gather for my work comes from someone other than the patient. While I do have occasional moments of guilt over not speaking enough with end users, I remember that it’s not about how you develop empathy for the people who use a product, it’s about the mindset of caring and understanding their needs. Interviewing is not the only way to achieve this.

As a final point here, I want to emphasize that it’s important designers aren’t the only people in the product organization to feel responsible for the user experience. I’ve made it a point to work with our field team to get more employees visiting clinics, and looking into ways to make patient stories and issues known throughout the company. I love having a team of engineers who will often jump in and defend our user before I’m even aware of an issue (one developer, in particular, handled a lot of debates against requests for a particular modal, dubbed by him: “the nuclear option.” Knowing he was there to defend the user, I didn’t even need to get involved.)

Designers can be catalysts for understanding the user, but by no means should we be the only ones to feel ownership for how we treat those using the product.

Disclaimer: getting the raw data is easy, synthesizing it is hard. While all parts of the company should feel invested in listening to users, designers and product managers must take responsibility for aggregating observations in order to steer product strategy.

3. User research is about more than needs

As I quoted above, the d.School method explains that empathy accomplishes the following:

By understanding the choices that person makes and the behaviors that person engages in, you can identify their needs, and design to meet those needs.

While empathy is important, it’s not the whole story. I believe empathy is about far more than needs: It’s about developing an understanding of the complex set of interrelated problems a product can solve, and collecting stories as evidence for designs to solve those problems. True user research, done by dedicated professionals can ferret out an extremely nuanced understanding of user behavior, most often the pace of startups doesn’t allow for this level of understanding for every project.

The dirty little secret of design ethnography is this: by collecting stories to support our opinions, we designers can manipulate others to agree with our ideas. Inherent in this is a danger that single anecdotes can have an outsized impact on product direction. It is imperative that we use discretion, and make sure not to filter out feedback not directly supporting our own opinions.

When I was an undergrad, a mentor gave me some good advice. He explained that companies would listen to people like him, because he had a track record. But if I wanted to get anyone to take me seriously, I would need some evidence to back up my opinions. A few days later, I was sitting with a lab-mate in Kendall Square, handing out Starbucks gift cards for anyone who would fill out a survey, looking for data to back up my ideas. This mentor’s advice has borne out over the years. I think we designers need to be honest, and acknowledge that research can be just as much about justifying your design decisions as it is about informing them.

Have you ever been in a situation when you have strong ideas about the right direction for a product, but find yourself going head to head with a colleague who has equally strong opinions about her own idea? This is a prime example of when you look to research data to be a tie-breaker. For instance, your colleague is optimizing around an edge case, like trying to pay an invoice from a mobile device versus a regular web browser. In this situation, Google Analytics can quickly tell you whether it’s okay to reserve certain features as web-only by showing you what percentage of people access a given page on their phone vs. a computer.

Design is admittedly a subjective field, and having anecdotes and stories to point to (as well as hard data when it’s available) can help to get other people on the same page about what to build. In-person interviews are one way to gather these stories and evidence, but it’s far from the only way.

Take-aways

I have plenty of thoughts about empathy, and the expansive way we designers must approach it when working in-house. If I had to boil it down to a few key take-aways, it would be these:

1. Empathy is about defining the problem you’re solving, and prioritizing which solutions to build.
2. It is design’s job to be an advocate for the people who use a product, but it is also their job to make sure all employees understand the stories and issues from these users.
3. Being an in-house designer gives you access to a rich array of options for understanding your users. Be creative, and don’t limit yourself to interviews.