Are you expected to demonstrate the “value” of your work?
Do you have to continually justify your existence?
If so, know this is a thorny, multifaceted issue.
First, let’s just face it, it’s usually the designers who are asked to “demonstrate their value,” and it’s often a trap. As Alan Cooper (2018) points out, “What’s the ROI of UX?” is a common but frankly idiotic question. If your higher-ups are asking it, they’re letting you know they already do not value your work, your contribution, your role. They may even be building a case against UX in general; and, as Cooper advises, you might want to look elsewhere for work. Orgs that take design seriously don’t ask questions like that — they lead with design.
If you don’t want to jump ship, however, and would rather take on the challenge, what are some things you can do to thrive in such an environment?
Let’s keep this simple. We’ll stick with three quick points:
Establish Some Ground Rules
When you’re asked to “demonstrate your value,” it’s often in a sort of “Gotcha!” sabotage kind of way. You cannot demonstrate project-specific value after the fact, by pulling some magic ROI stats out of a hat. If this is what you’re being asked to do, it’s an unfair ask.
One trick, also from Alan Cooper, is to ask them to explain how they calculate the ROI of the work for the other roles, so you can apply the same process to your own work. It’s a clever judo move because, of course, they aren’t calculating the ROI of the other work being done, let alone their own!
To demonstrate value, a framework for defining and assessing it must be negotiated and agreed on up front. This means if you’re in a position where you’ll often need to demonstrate your value, you will need some ground rules. The five rules suggested here are from Disabato (2018) and Hall (2013):
Rule №1: This is straight from Disabato (2018). The easiest way to demonstrate value is to only solve expensive problems. Disabato defines an expensive problem as something you can show is costing the business an outsize amount of money, that they will pay a premium to fix. Thinking in terms of cost of delay, while your work on a less expensive problem may still have value, all work dedicated to it will still together be less value-adding.
Rule №2: Insist on requirements, just not as agilists tend to think of them. Real requirements have nothing to do with solutions. They’re not specs. If you need to demonstrate value, focusing on output won’t get you there. Working software isn’t a measure of value. If you’re expected to show value, then you’ll need a negotiated agreement around the value you commit to creating, which includes how that value will be defined. Requirements can be renegotiated as you learn, but they still need to be there. They’re like the boundaries in any healthy relationship — they cordon off the space that allows for freedom of movement, real agility, and discovery. Afterwards anyone can look at them and say, “Here’s the value I wanted you to create, and yes, you created it.” There’s no room left for debate.
Rule №3: Part of the bargain should be that the work you do will actually be implemented. If they want you to do design research but then ignore the learnings as inconvenient, that’s on them, not you. They can’t come back and blame you for not creating value. If design decisions are a fait accompli, then they never really wanted your expertise to begin with. They wanted your imprimatur, but that’s not your role. Don’t fall for this bait-and-switch. It’s an old trick, and it’s not value-adding. (See what I did there?)
Rule №4: As Goldratt (1990) argued, the root causes of most issues are psychological. He described the concept of “minimum viable” more than 20 years before the term caught on: You’re looking for the minimum number of changes to the environment that make it so the problem in question can no longer exist. Well, what were your requirements? What changes did you agree to create? You can’t show improvement without a baseline. What was the situation before your work, and what’s the situation now? Did the target metrics move in the right direction? Or not? This keeps the conversation on goals, measures, and what to try next, which can help with anyone biased against the kind of work you do.
Rule №5: This one’s from Hall (2013). Design is about decision making. Research is about making better evidence-based decisions. If this is what you’re being asked to do, then you need to be able to actually gather the info needed to better inform the decisions on the table. Some people will get in your way. You’ll need tactics to get around them, whether that comes in the form of air cover from the person you’re working for or from identifying the right stakeholders to approach the person in question for you. However it’s handled, there will be “playground bullies,” and they’re usually people that don’t value design research.
Keep Research Front and Center
Agilists often act as though coded product is all that matters. This devalues other work. The fact is, there is only one way create business value, and it’s not to code product — it’s to change someone’s behavior. There are lots of ways to change behavior other than coding something. Remember Goldratt’s point above: You’re trying to learn what minimal changes to the environment will make it so the target problem no longer exists, and the root causes of the issue are almost always psychological.
Goldratt also argued that the people in the context in question will typically have an intuitive sense of what the real issue is. You have to seek them out and help them verbalize it. Sounds a lot like design research, doesn’t it? Such research is key. It is not a “nice-to-have.” As Hall (2013) notes, however, many will want to engage with you on other parts of the work, and the temptation will be for you to just throw in the research that you know needs to happen for free. Doing this would just play into their bias.
What decisions need to be made now? What assumptions are at play? What’s the risk associated with each? What needs to be learned to derisk the path forward? Notice these questions cannot be answered without research. As Disabato puts it, research is prerequisite to being value-based, and yet is the most likely thing to be cut from the budget. You can push back by baking it into your requirements (Rule №2 above).
So don’t treat research as a freebie. It’s work, and like any other value-adding work, needs agreed negotiated requirements that will then be used to assess its value. What’s the goal? What are your research questions? What are you trying to learn? Crispify this before anything else happens. If they’re not interested, go do something else.
If they argue all they need is to ship small coded thingies to test their assumptions, you can take this tip from Kim Goodwin. Ask them to consider how much cheaper it is to rule out half of these small coded thingies with a handful of interviews. If they’re just not interested, move on. Nothing to see here.
Also remember Rule №3: Ensure as a part of the work agreement that decisions will be revisited based on what is learned. This helps you avoid the bait-and-switch mentioned above. Higher-ups sometimes approach research disingenuously. As Hall (2019) notes, when they say they need “research,” they actually mean “marketing research,” which is more about culling quotes and stats to pepper their presentations with. In other words, what’s being “marketed” are the decisions already made. This is a far cry from design research, which is about becoming evidence-based.
I recently experienced this firsthand when an executive, looking at our report out, said he “doesn’t like the tone of the user quotations.” Clearly, he wasn’t interested in design research. What he wanted was an imprimatur, a seal of approval.
Avoid Neediness
As you can probably tell, I think negotiation skills are important for any designer. In fact, one of the most common mistakes designers make may well be acting like they’re in a debate when they’re really in a negotiation. A point commonly made by negotiators is that you need to know your walkaway position, your “Ulysses pact” (Duke, 2018). This is the agreement you have with yourself, your team, your cohort, whatever, about the concrete things that will cause you to walk away from working with someone.
What might your Ulysses pact be? Well, how about, for starters, the ground rules discussed above? If someone can’t agree to your ground rules, maybe you should move on. Now, that does not mean that you walk away from the customer, but rather that you invite them to walk away if you cannot come to agreement. You are not needy. You are just there to see if there is a fit, and it is looking like there isn’t, AND THAT’S FINE.
If you forget this, if you act like you NEED the gig, this will raise customer barriers. Think about job interviews. You interview better when you don’t actually need the job, don’t you? In fact, the entire interaction is probably different. People instinctively react to neediness similar as to being threatened.
I recently heard an executive say, and it is brilliant advice, “Never let on that you might not be fully booked.” If you do, it signals to people that you have no leverage. They’ll be more upfront about their demands and less receptive to your position. They will start asking for you help create a “win-win,” which is a Trojan horse for demanding concessions. As negotiator Allan Tsang puts it, win-win language assumes a finite pie.
It’s zero-sum thinking in sheep’s clothing, and is a trap you should want to avoid.
That’s it for now.
Reference
Cooper, A. (2018). When companies question the value of design: ‘What’s the ROI of UX?’ is the most idiotic question ever asked. User Friendly. Retrieved on October 22, 2019 from: https://medium.com/s/user-friendly/whats-the-roi-of-ux-c47defb033d2.
Disabato, N. (2018). Value-based design. Draft.
Duke, A. (2018). Thinking in bets: Making smarter decisions when you don’t have all the facts. New York: Portfolio.
Goldratt, E. M. (1990). What is this thing called Theory of Constraints and how should it be implemented? Great Barrington, MA: North River Press.
Hall, E. (2019, September 11). Not content with content [Audio podcast]. Retrieved on October 22, 2019 from: https://vod.podbean.com/e/episode-18-kristina-halvorson/.
Hall, E. (2013). Just enough research. New York: A Book Apart.
Charles Lambdin 