Dark Side of Empathizing

Can empathizing reduce co-creation in the design process?

Service design projects carry businesses through a problem-solving process rooted in design thinking — a five-stage process comprising discovering the problem space, defining the problem, ideation, prototyping and testing solutions, and finally implementation. This process isn’t run through just once, but repeated multiple times, and as quickly as possible, in order to reach the best possible outcome. But to get through the first stage — to more precisely discover the space in which the problem occurs — the designer must identify the key stakeholders of a problem and be able to describe the problem space from their point of view. To do this, the designer must be skilled at empathizing. This emphasis on empathy is one of the features that sets service design apart from other organizational problem-solving methods. Among designers, there’s a well-known saying that without learning what the stakeholders of a problem are actually experiencing, service design work will never reach its real goal: creating a genuinely functional, novel solution for those stakeholders. At the same time, arriving at this understanding is a winding road, and the designer spends a large share of the service design process practicing this empathy in order to form as accurate a picture as possible of the stakeholders’ world and their needs. But for all the benefits that gaining this understanding and skill in empathizing brings to the designer and to the problem-solving process, it can sometimes itself become a point of harm — both for the designer and for the solution. But how is that possible? In this piece, you’ll see a picture of what this empathizing looks like, as well as an analysis of how its effects can sometimes be negative.

On the food court floor of the mall, the three of us are sitting on one side of a large wooden table. Behind us is a wall, and in front of us we can see part of the space with its restaurants and their customers. The sound of music, kitchen equipment, and customers talking to one another all mix together, but at this hour — late morning, close to noon — this floor isn’t so crowded that the three of us can’t hear each other. Melika and Ehsan have arranged to work together today on a few tasks for a project, and they’ve chosen this place because it’s convenient for both of them to reach. They’re sitting next to each other, and I’m sitting next to Melika. Both of them have their laptops open, and on both screens they’re looking at the same file. The file in question is an online questionnaire under design, meant to be answered by the target audience of a service design project. The day before, they drafted the questions, and today it’s time to rewrite them so they’re understandable to the respondents.

The questionnaire has close to 20 questions, and it’s meant to stay that number. If the questions grow too many, the respondent might lose patience and abandon the survey halfway through. The questions are also meant to gather information about the working circumstances of a number of the mall’s shopkeepers — meaning the content itself isn’t very complex. But rewriting even this many questions for a simple questionnaire is work that started at 10:45 and continues until 12:45, and even then remains unfinished, to be picked up later when Melika has time to make the tone of the questions consistent. Counting the time spent before this session and what will be spent after, a full working day is needed for this task. That’s because two service designers are writing this questionnaire, and at every step, with every sentence and every option they write, they’re thinking about how shopkeepers from this particular trade will experience the questionnaire. They keep pausing and testing their work to check whether respondents will easily understand the intent of each question: “Last time one of the shopkeepers said we don’t have ‘users’!” — whether the questions are close to the shopkeepers’ own vocabulary: “Do they call it a ‘strip’ themselves?” — whether, when answering on their phones, respondents can easily see the question and its options at a glance: “It shows these stacked on top of each other on mobile, isn’t that too much? Does it scroll all the way down?” — whether to avoid adding another question that would make it too long: “We can’t split this into two questions, because they’re hard to reach and we want them to answer this, and we only get one chance to get them to fill it out” — and, in short, whether every single detail that a respondent will only spend five minutes dealing with is in its right place. Partway through designing the questionnaire, the two of them are so meticulous about wording the questions — sometimes falling into long pauses and silences — that it occurs to me to suggest that if they’re still unsure whether a question or its options work, they could resolve that uncertainty by testing the questionnaire on one or two shopkeepers they have an easier rapport with, before distributing it to all the shopkeepers. Melika welcomes the suggestion, and it speeds things up a little.

Once the questionnaire work is done, it’s time to enter the answers from a number of interviews they’ve conducted with some of the shopkeepers. The file changes. Now both of them are looking at the same online spreadsheet file. Melika explains to me how they go about this work: “We put the interview results in a Google Sheet so that, first, we ourselves understand what we’ve entered; second, Mr. Naseri [the client’s contact person and project manager] understands what we’ve written; and third, if someone later wants to do an interview and enter it, they’ll understand how it’s done too.” In other words, now they have to think about the experience of their colleagues who will later see this file. The two of them check whether they’ve chosen suitable headings, and whether each heading conveys what the answers under it actually meant. The columns aren’t titled based on the wording of the questions, but based on categories Melika has drawn out from the answers themselves. Melika explains this logic to Ehsan, and Ehsan asks questions to understand it better — for instance, one column is labeled “Unit Initiatives.”

• Ehsan: Like, in some of your interviews did you ask what initiatives they’d taken?
• Melika: No. From what they said, I understood that, say, such-and-such unit did this or that to sell better.

After checking the headings — finishing up with a few corrections — it’s time to check the order of the columns, and once that’s done too, they decide to enter one of the 25 interviews that need to be entered together, so that later, when they’re each entering the rest of the interviews on their own, they’ll go about it in a similar way. When they go to enter what was said, the data entry can’t follow the order of the columns; instead, they enter the data based on whatever the interviewee happened to talk about first, since the interview was semi-structured and the respondent was free in how they answered. As they enter the interview information, the two of them consult each other about which column heading a given thing the interviewee said best relates to, and then consult about how to enter the answer in a way that stays faithful to the quote — entering more or less the exact sentence the interviewee said. And once again, the next challenge in entering the data is making sure the sentences are recorded in a way that lets others easily understand what the point actually was, without picking up a different meaning. In a sense, they are organizational translators: people who have understood the language of the trade’s members and are trying to phrase the findings in a way that’s easy for designers who never met the respondents directly to understand, while still conveying the meaning accurately.

The fact that the interviewee raised a different category every few sentences, and the matching column heading had to be found each time, means Melika is constantly moving back and forth between columns. Watching this back-and-forth between so many columns — which by a rough estimate number around 50 — is frustrating even for me as an observer; I don’t know about Melika, but I admire her patience. The interviews, which took an average of 45 minutes each, take roughly the same amount of time again just to get their results entered into the table. Looking at the column headings, I can also make out traces of other stakeholders:

• Challenge with the mall’s management
• Challenge with other tenants
• Most important factor behind lack of business
• Strengths and unique features of the mall
• Competing markets, from the tenant’s point of view
• Successful strategies of the mall
• Unsuccessful strategy of the mall
• Customer personas
• And so on.

In their effort to uncover what goes on in the shopkeepers’ world, the designers have also been thinking about other people who weren’t present during the interview but who played a role in shaping the shopkeeper’s experience: competitors, the mall’s manager, neighboring shopkeepers, the shopkeeper’s own customers, and so on. As a service designer myself, I know that by the time this project is finished, they’ll go on to try to understand the perspectives of these other stakeholders too, because that’s what design is: an effort to understand others’ experience and world, and to meet a need that’s meaningful within that world. Designers do this so much that even outside the project, in every interaction, they find themselves thinking about someone else’s world, someone else’s wants, someone else’s needs. Actually, it’s better to say “others’,” plural — because this consideration of wants and needs isn’t limited to customers alone; it takes in every important stakeholder in a piece of work. This is how noticing others’ needs becomes a habit — and even when working inside the team, the “other” becomes that team member who isn’t present right now but whose experience and world must still be considered, since they’re the one who’ll later be looking at the questionnaire results.

This habit can also be seen in Fahimi, the team lead. Having practiced this empathizing with others more than the rest of the team, a few days earlier, on this same food court floor of the mall, while talking with his team members about the contract with the client, he started by talking about the client’s world and what the client needed from this contract: whether inflating the time estimate would upset the client, or whether increasing the hours of work would be something the client could comfortably accept. Even when team members pointed out that in some months, because of the client’s disorganization in assigning tasks, their own work-life schedules had been thrown into disarray, and that it might be better to set a minimum monthly volume of assigned work as a condition for the client, he explained his view to them this way: “I was like this — that despite the cost we ourselves are bearing, [we do it] to make this onboarding path easy for them, so they can trust us and have no worries at all, and say it’s a hundred percent worth it for me to sign a contract with these guys — so that we sign contracts of this kind, be alongside these guys for the long term, so that this happens.”

Although this “seeing the other” and their needs will raise the quality of interaction with the other, having this habit sometimes brings negative side effects for designers too. One negative side effect is occasionally forgetting the role of the “other” in solving a problem or advancing a project. This can be seen in Melika and Ehsan’s effort to design the clearest possible questionnaire with the respondent’s character in mind, when they forget that although they’re making every effort to create the best experience for the respondent, past a certain point it’s only “designing alongside” the respondent that can produce the best result. This is exactly why testing the questionnaire with a small number of the target group is a standard method for getting the best result out of questionnaire design. I remember a project related to insurance, where I myself was on the team, and we were designing a questionnaire; it took three or four days, with every ounce of care from our own point of view, to arrive at a questionnaire we considered flawless for respondents to answer. And when we reached the stage of testing it with a small group of respondents, we ran into the fact that our respondents over 50 years old, who worked in freelance and labor jobs, didn’t understand the colloquial tone of the questions and needed someone younger to read the questions to them in a formal, written-register tone. Even though, in speech and conversation, this group of respondents talks more colloquially than any other group, reading colloquial text left them confused. If we hadn’t run that test, we would never have realized the change that was needed in the questionnaire, or even in the research method itself, for uncovering the respondent’s world. In other words, some part of the “other’s” world that we’ve tried to understand always remains with the other person alone, and we only manage, stage by stage, to uncover parts of it. This is exactly why the stakeholders themselves need to participate in the problem-solving process.

Another negative side effect is the designer forgetting themselves as a stakeholder in the relationship with the client — as when we’re willing to “bear the cost” so that the client can “have no worries at all.” Whereas the client is in fact an important stakeholder in solving the problem of managing the relationship between designer and client, and half of the initiative for arriving at a genuine solution rests with them, and it’s only in “designing alongside” the client that the outcome becomes favorable both for the client and for the design team. The design team, too, are human beings who have their own needs in order to do their work. It’s true that playing the role of “empathizer” in solving the organization’s problem falls mainly to them, but they themselves also need “empathy” — need to have their own world understood by the client — in order to deliver their best performance.

I witness the peak of this mutual lack of understanding a month after Fahimi’s meeting with his team about how to deal with the client; we’re sitting in the senior manager’s office, and those present are discussing the prioritization of tasks that need solution design. At the meeting the month before with the client, priorities had been set at the senior manager’s own suggestion and, in some cases, insistence. Now, with only a month passed since that meeting, because of changes in the client’s circumstances, not only have those same priorities from the month before been changed again by the client himself, but he doesn’t even remember what priorities had been set for the design team. To my utter disbelief, as Fahimi is going through the Excel file to show the team’s work plan for the past month and the months ahead, I witness this exchange:

• Middle manager, Hooman: When’s task X due?
• Fahimi, pointing to the file, explains: We had it here in October and December so it wouldn’t clash with your work. If the priority needs to change, you can let us know.
• Senior manager, Vala: Did you all arrange these priorities?
• Fahimi: Some of them you specified yourself. Some others, whose work was already done and ideation completed, we moved up.
• Vala: We had a meeting two months ago? Was I there?

Sima, another team member who is the project manager, hearing this exchange, has her eyes go wide, and shoots a surprised look at Fahimi and me, then says in an astonished tone, “It was a month ago!” Fahimi himself is taken aback too, and glances at Sima, who looks surprised, and at me; I murmur to him, “Yeah, I think it was a month ago too,” and then, frowning slightly, he flips through his notebook looking for the meeting date, saying to Vala as he does, “We can check the exact date in the notebook too, but it was a month ago.” Although Vala says, “Let’s take another look at the priorities. Ninety percent it’s probably still the same, but let’s just check” — the priority of at least two of the five ongoing tasks gets thrown off, and even becomes entangled, with both ending up at roughly the same priority level and turning into priority number one. On top of that, one task that had been placed at the top of the priority list, specifically at the senior manager’s insistence, and that the design team had been working on the previous month with everything they had, gets dropped from the priorities entirely, because the client’s view of one of the main tenants on the mall’s food court floor has changed. A similar thing happens again the following month, when one of the tasks the team was working on is dropped by the client because of changes in municipal regulations for malls. In the months after that, similar things happen too — sometimes because a socially sensitive date is approaching, sometimes because someone new has joined or left the organization, and for other reasons as well. Although the client, too, faces a great many changes in this environment, some of which aren’t within his control, what happens to the design team in the midst of all this isn’t even seen by the senior manager or the client’s middle managers, and its effects aren’t acknowledged. The fact that the design team has laid out its work schedule based on these priorities — and that the arrangement of this schedule has even affected this service design team’s other projects for other clients — and that the work is now left half-abandoned, leaving the team with a sense that the past month’s efforts were fruitless, none of this registers with the client, who doesn’t even remember what his own decisions were. This repeated pattern got to the point where even I, who was only observing events, felt the pain the team was feeling, and spoke to the team lead about it, suggesting that perhaps it would be better to set some limit on the client regarding the number or stage of priority changes allowed in the schedule. But the feedback I got was: “It’s natural for their priorities to change, and I understand that too.”

In both of the cases above, when the mindset of “designing for the other” casts a shadow over the designer’s core mindset of “designing alongside the other,” the influence of the other party in the interaction on solving the problem gets forgotten, and the opportunity to use the “other’s” ideas to solve the problem is lost. Perhaps sharing the team members’ experience of uncertainty in their work and personal lives — caused by the client’s failure to assign work on time — would have given the client a view into the human experience the team members go through in working with his organization. Perhaps raising this human issue wouldn’t have caused distrust at all, but instead would have led, together with the client, to a win-win solution for both sides. But these paths remain hypothetical, at the level of “perhaps,” without our ever knowing what ideas and options might have been available had we walked the path of solving the problem alongside the other stakeholder rather than in his place.

Fahimi is an experienced designer, and this isn’t Melika’s first experience in design either, and both of them, as experienced designers, know very well that a designer’s empathizing with the other, in order to understand their world, isn’t meant for making decisions in their place, but rather to enable creating an easier interaction with the audience in solving their problem. The design’s audience has an active role in arriving at a clear problem definition, in reaching ideas, and in implementing solutions — which is exactly why, in service design specifically, there’s talk of co-creation with stakeholders of the solution, in which the designer facilitates other stakeholders’ participation in reaching a solution — especially when the conditions governing the problem space are such that we’re facing a wicked problem. A wicked problem, in the world of design, is a problem that, because of the presence of different stakeholders with sometimes conflicting interests, cannot easily be solved, and sometimes even its starting point isn’t clear. Such problems have no right or wrong solution, and the only way to move toward solving them and reaching a “possible” solution is through negotiation with the other stakeholders. Richard Buchanan, in his article “Wicked Problems in Design Thinking,” quotes Rittel — who first used this term in the 1970s — describing it as a class of problems related to social systems that are difficult to formulate, where the information is confusing, where there are many stakeholders and decision-makers regarding the solution, sometimes holding conflicting values, and whose branches are scattered confusingly throughout the whole system. He then goes on to say that, under these conditions, design is a systematic approach of logical reasoning and argumentation, guided by designers, aimed at reaching one of the core themes of communication, construction, strategic planning, or systems integration. He holds that argumentation in design thinking moves toward close interaction and mutual connection among objects, things, actions, and thoughts, and that all products of design are an example of this form of argumentation (Buchanan, 1992: 15, 19, 20).

This team’s designers go through this process to solve all of this project’s client’s problems, but in the heavy shadow of the habit of empathizing they’ve developed, they’ve forgotten that the very nature of their own interaction with their client has itself turned into a wicked problem — one that needs resolving through discussion and negotiation with the client. This is a problem shaped by the client’s own high staff turnover; by the dynamism of the project’s working environment itself, which, as a commercial mall, is affected by all kinds of political and social events; by shifts in the mall’s customers’ behavior patterns in response to each of these events; by economic fluctuations that constantly affect interactions with the shopkeepers; by changes in municipal and city regulations, which occur with high frequency in Iran and especially in Tehran; and so on. All these factors cause the priority of tasks, the volume of work, the personnel the design team interacts with within the client’s organization, and other project conditions to constantly change. Although the design team’s presence in this commercial mall is meant to help create new service solutions precisely within such a highly changeable environment — and it’s in the presence of such conditions that the work of “creating a novel solution” takes on a more pronounced meaning — the way the design team goes about solving the problem, the timing of the work, and the team’s degree of success in doing it all require constant interaction with the other stakeholders, and are bound up with their cooperation. In other words, the design team is itself one of the stakeholders in these circumstances. Under such conditions, change in the client’s circumstances is, in the team lead’s words, “natural” — but overlooking the design team as a “stakeholder” in the presence of these complex conditions is not natural at all.

But here, the designer has continued empathizing with the client to such an extent that he has forgotten his own share in participating toward creating the desired solution, and forgotten that he himself is a stakeholder in solving the problem of interaction with the client; and so that the “other” — with whom the designer is in his most empathetic state — doesn’t have to bear the least bit of trouble, he tries to create the best solution for the client, rather than alongside him, and rather than as the result of negotiation with him. This is how the needs of the design team — both the needs related to carrying out the design work and the team members’ need for better interaction and working conditions — have gradually been forgotten to such a degree that the client changes the project’s parameters in almost whatever way he sees fit for himself and his organization, without even being aware of what effect each of these changes will have on the design team and, consequently, on the productivity of his own project.