Switch semantic environments to avoid stakeholder meddling
“Creating good user experience is not a design problem. It is a power struggle.” –Alan Cooper
Despite decades of articles, books, and courses on the topic, the most common design process still looks something like this: a stakeholder tells their designer their idea, and the designer redraws it until the stakeholder likes it. Stakeholders — PMs, managers, profit center leaders, domain experts— are the ones making the design decisions. The designer’s role is seen as closing a communication gap between these stakeholders and the development team.
Designers naturally chafe at this state of affairs. But our stakeholders are not singling us out; their entire job exists within a semantic environment of making decisions in meetings. They are accustomed to discussions where the stakeholder is an expert and the other participant is not. When designers are not intentional about how they show up to stakeholder meetings, the stakeholders do their best to play the role they normally do: make the decisions using their own expertise, which often goes counter to the designer’s idea of the right thing to do. And then we get upset; “the stakeholder told me to change my great design.”
Part of any designer’s role is bringing colleagues into design’s semantic environments of user research, critique, and visual documentation of design decisions. But to be truly effective, we must also navigate the semantic environment of our stakeholders to legitimize those decisions. This means learning how to ask the right questions, withhold the wrong ones, and mine for gold.
Design for decoration is a recipe for failure
As a junior designer, I thought my job was to attach mockups to Jira tickets. My stakeholders had gotten used to finding an obvious problem, picking the first solution they could think of, and asking the developers to build it. Design was a concession: in exchange for adding a new step between “we had an idea” and “the developers build it” the requirements would now be clearer because of the accompanying visuals.
Design under these conditions was a time-consuming process. As it turns out, if you don’t know what the problem is, and what solving it looks like, you can’t actually make design decisions — you can only iterate on the drawing and hope that the stakeholder likes it. So stakeholders would tell me “I’ll know it when I see it” and I would iterate through high-fidelity mockups until they “saw it”.
I used to believe, like many designers still believe, that I could gain credit with those stakeholders — and maybe even the coveted “seat at the table” — by giving in to those requirements. If I was being measured on outputs, then I could safely compromise on the parts of the design process that did not fit.
I was wrong.
Giving up responsibility for making design decisions didn’t insulate me from accountability when those decisions turned out to be bad. After all, if the stakeholders had not believed their idea was really good, they would not have asked the developers to build it. The fault had to lie with the mockups, they thought. Or perhaps hiring a designer in the first place was a mistake.
The “I’ll know it when I see it” feedback cycle
It didn’t take me long to realize that I was asking my stakeholders for the wrong inputs. Their opinions on visuals never mattered. What I needed was their framing of the problem, their definition of success, and how they thought their solution would get the company there.
But the semantic environment that business stakeholders normally inhabit wasn’t suitable for what they really wanted; they were asking me for pixel-perfect mockups because that was what fit into Jira. They were trying to develop the visual fidelity of their features before they had the conceptual fidelity to understand what they really wanted.
Instead of taking my stakeholders’ decisions at face value, I started treating them as user research feedback. When the business told me to design a feature, it was articulating a need in its most familiar language (product requirements). By applying research and synthesis methods to my own process, I could prevent my stakeholders from trying to design for me while still satisfying their needs. Rather than elevating my stakeholders to a position of authority over what good design was, I focused on the why behind their opinions.
I realized that the problem wasn’t with my design decisions — it was with the way I was communicating them. Rather than rushing to make the changes I thought they requested, I focused on finding and clarifying areas of ambiguity. The first artifacts I showed my stakeholders needed to reflect just enough of the stakeholder’s vision that they could say “yes, that’s what I want!” and articulate the details within the new shared context I had created.
This context-building work served the same goal as high-fidelity prototype design, but it was much faster and less frustrating for both parties. Instead of letting my stakeholders try and make design decisions, I helped them develop the conceptual fidelity of their ideas to the point that they did not feel the need to do so. Once they saw the most important nuggets of their ideas reflected in my sketches, they trusted me to do a good job beyond that point.
Interrupting the cycle with cognitive estrangement
The key to the context-building conversation is that it takes place outside of the stakeholder’s familiar semantic context — the meeting where they act as a decider. In corporate culture, the main attribute of a decider is decisiveness: they make decisions quickly and confidently. But for a designer interested in understanding divergent interpretations, decisiveness is detrimental; it leads to premature convergence.
To prevent the stakeholder from unconsciously performing the role of a decider, we can change the semantic context. By transposing the conversation into an unfamiliar framework, the pressure to Decide is instantly lifted. This principle — estrangement — is behind the power of a well-run design workshop.
When the conventional rules that govern a meeting no longer apply, a workshop facilitator needs to create new rules — guard rails that prevent the conversation from sliding back into a meeting. Workshop exercises become most effective when they have very specific questions, highly structured ways of answering them, and time set aside for thinking about those answers. Templates or other constraints (such as the space on a sticky note) force participants to break out of their assumptions and deliberate on their answer.
Try to avoid asking ambiguous, open-ended questions outside of workshop contexts. In the standard semantic environment, business stakeholders expect clarity. Avoid creating the expectation that your stakeholder should make a decision; present your design decisions as updates, rather than soliciting design critique.
