Developing empathy for stakeholders means looking at the project from their perspective, in order to let go of the defensive and protective feelings that often surround a project. Empathetic designers accept that stakeholder suggestions are based in reality, and are important. When designers have empathy, they not only understand the stakeholder’s perspective, but they’re actually driven to action: they want to make changes to their designs because they feel the stakeholder’s pain as well as the user’s.
That doesn’t mean that a designer should do anything and everything a stakeholder suggests. It simply means that the priority for communicating has shifted from a position of defense to one of solidarity. Stakeholders and designers are on the same team, accomplishing the same goals, and espousing a common vision.
– Tom Greever, Stakeholders are People Too [emphasis mine]
Why does our gut twist a bit when we think of this? We still somehow believe our stakeholders are at best, not in as pure a pursuit of the users’ good as we are, or at worst, are tasteless. I mean, come on, the loyalties are right there on the face of our job titles: Sales Manager, Project Manager, Business Analyst, Solutions Architect, User Researcher, User Experience Designer. You can tell who really cares about the user. We do. High five! Hold still for a second; your cape is crooked.
Once we allow ourselves to believe we’re on the moral high road as UX designers, it creates a problem — when stakeholders suggest a change based on anything other than the user’s immediate need, it feels like a compromise. And when we feel as though we’re compromising we take a defensive posture emotionally, vocally, and physically. I’ve done it. You’ve done it. And before we take our final form, we will all do it a few more times.
But life is complicated, and there are many things at play in the organizations we serve, and far fewer actual villains. We need to tune our empathy antenna for a wider range of signals.
I’m currently reading Tom Greever’s Articulating Design Decisions, and he suggests creating stakeholder stories with the user story boiler plate as a way of seeing stakeholders as, well, humans.
User Story: As a user I want to _____ so I can _____.
User stories, hopefully heavily influenced by research, are buoys that help us keep our bearings as we solve problems. They speak to motivation and goals, and help get us at least somewhat in the user’s shoes. Greever’s idea of writing them for your stakeholders as well was, for me, one of those, “Why didn’t I think of that?!” things. Here are three examples from his book:
As an executive, I want to see what my team is working on so that I can provide a report back to upper management
As a product owner, I want to deliver new and creative ideas so that I can make an impression on the company with my leadership.
As a developer, I want to understand all the requirements up front so that I can plan my work and maximize my time.
PERMISSION TO CAPE: I wasn’t going to say anything about it, but since I just had to type “so that” three times, fie on the torpedoes! If you want to put on your cape and defeat something, allow me to suggest the extraneous “that” in the user story boiler plate. “… so that I can avoid a rage blackout.”
Ideally, your stakeholder stories will be more granular, and there will be a few for any given role you are trying to better understand. After all, people’s needs and goals are multi-dimensional. Getting the details for these will take some strategy because most project briefs don’t include a company’s org chart and the KPIs for every role you’ll encounter over the course of the engagement. You’ll have to ask around. You can casually ask other people in the company about who reports to whom as you walk between meeting rooms, or better still, go to lunch with people and ask something like, “So, I’m always interested to hear about the daily details and nature of other people’s jobs. Would you mind telling me what it’s like in your chair most days?” Use your own words, and actually mean them. The point is, most people like talking about themselves.
Paul Ford has this great piece on being polite in which he shares this nugget:
Here’s a polite person’s trick, one that has never failed me. I will share it with you because I like and respect you, and it is clear to me that you’ll know how to apply it wisely: When you are at a party and are thrust into conversation with someone, see how long you can hold off before talking about what they do for a living. And when that painful lull arrives, be the master of it. I have come to revel in that agonizing first pause, because I know that I can push a conversation through. Just ask the other person what they do, and right after they tell you, say: “Wow. That sounds hard.”
This applies not only to parties, but group lunches in the break room. Remember, you’re on a slow boat, and you’re really just trying to understand the other person as a human being who, despite that little success calendar on their desk, spends as much of the day frightened and in pain as you do. Over the space of a couple of weeks you should be able to write a much more detailed set of Stakeholder Stories than when you began, and hopefully those stories will help you let down your defensiveness, hear past their clumsy expression of an idea, and calmly understand what they really need.