No amount of research will make stakeholders as confident as following all of their biases.
Sell stakeholders on the idea of *doing research* in the first place, or they will demand impossible bulletproof evidence for anything that doesn't align with their existing assumptions.
In one article, @jmspool discusses how you must always ask executives for what they expect to happen *before* user testing. Otherwise they will pretend like they knew the outcome ahead of time, and it will not sway their thinking.
This is an analogous concept.
If you produce results without creating the expectation that the stakeholder's assumptions may have been wrong, they will find a way to reconcile the results with their existing mental model. Often that just means being dismissed: "you asked the wrong people/questions".
As @MrAlanCooper says - user experience is a power struggle. In low-maturity product orgs, stakeholders gather political power through being Experts who are Always Right. Realigning attitudes away from assumptions is a political game, not a delivery one.
These orgs create a vicious cycle between assumption-driven design and brittle development. The cost of being wrong is massive (politically and financially). Rather than reducing the cost of being wrong, stakeholders find it safer to obfuscate how "right" is determined.
Introducing the idea of experimentation - controlled, rapid failing - is anathema to this environment. So you have to sell the whole thing at once: small, quick, cheap tests aimed at learning rather than "winning". The only real failure is if we didn't learn anything new.
This is very scary because it requires stakeholders to commit to a real "definition of good" that's not just "the team delivered the requirements." They have to get buy-in for goals and hypotheses (you might recognize these as OKRs) and that takes work!
But more importantly, they give up control. They are no longer the Knower and Decider (instead, research determines the way forward). They no longer set the team's outputs (the team determines their own experiments). But they are still on the hook for results.
This is what you're struggling against: convincing stakeholders to relinquish absolute power. If they do not, then regardless of the title on your business cards you are stuck as a feature designer or usability tester, not a UX designer or user researcher.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Even the best designer won't be able to make an impact if the brief is "we want to do the same thing as always, but get better results."
Getting a sense of the org's appetite for change should be the first thing you do, before even starting a project or a new job.
Unless you are coming in at the CDO level, you will never be able to transform the entire org. So scope your opportunity space. Who is the most senior leader willing to try something new? How much do they want to risk? Understand (or negotiate for) this up-front.
A lot of companies expect so-called individual contributors (hah!) to fit into an existing slot on the assembly line. But teams that won't give you the opportunity to shape how you work with your colleagues aren't teams, just workgroups.
I often see rookie researchers ask questions of the wrong type of participant. Calibrate your expectations:
-A domain expert can tell you about prevailing theories
-A stakeholder might be able to articulate a hypothesis
-A user can only comment on their own experience
If you ask a user "do people do X?" you're expecting them to make massive assumptions based on nothing but their own experience. You shouldn't even ask them to extrapolate their own behavior. This kind of data is only reliable in aggregate.
Domain experts may have already done the work to collect and synthesize data, or know of existing research by someone else. A regular user will not, and should not be expected to. Don't ask them to speak on behalf of anyone but themselves.
I have no respect for process without valuable outcome.
When gatekeepers ask for some information because that's what the book says, but can't explain its purpose, they are wasting both my time and theirs.
"Transparency" is not an outcome, unless that transparency enables a decision. What is the decision? Has reporting this information ever resulted in an action item other than "fix the format of the information"?
If not - go away.
Unfortunately, process gatekeepers tend to thrive in orgs without a product-focused culture.
It's MUCH easier to check if feature delivery work "fits the process" than to measure impact on customer or business outcomes. And you won't run afoul of managers pushing pet features.
The fundamental roles of a leader boil down to:
- Decide
- Commit
Product teams trying to "be realistic" can compromise on a lot when dealing with stakeholders across their org, but without these you don't actually have a path forward.
Decide: given currently available information, this is the best course of action that will get us to the shared objective
Commit: stick to the decision until new information is available
Someone who is incapable of providing these is not a stakeholder, but an obstacle.
Deciding & committing usually go hand-in-hand. A stakeholder who *seems* decisive might be making the decisions without incorporating all available information into their mental model, and will change their mind with every new piece of evidence or influencer's opinion.
Designers think they can win credit from "the business" by compromising on good process. But this is a mistake:
- stakeholder suggests "just do X"
- designer caves and does X
- the outcome is bad
- stakeholder thinks "that designer is bad" or worse - "design is a waste of time"
Business stakeholders don't know how to do design! If you don't lead, they will try their best, but their best won't be as good as yours.
Yes, leading exposes you to risk & is far more work than going with the flow. But the results are worth it.
Of course, there are designers who don't know how to lead, and get into arguments about "good taste" or whatever. This still doesn't work, and also poisons the stakeholder's perception of design as a whole.
Beware any part of a system (role, process, or feature) whose purpose is largely to solve problems that it causes itself.
90% of what a project manager does is interact with other project managers to align projections with deadlines created by project managers. The solution here is less project management, but if you ask them, we need more.
Every credit bureau offers a protection service, where they'll tell you if the data they gathered on your without your consent was stolen. To do this, they need more of your data. The solution is to gather less data, but it you ask them, they need more.