A few years back, I read a book (whose title I can’t recall) that delivered this absolutely GOLD nugget of wisdom regarding the struggle to get stakeholder buy-in for UX and Design:
Most people in management or executive positions can’t truly see what’s broken, because they’re usually only looking at the side that’s working.
Truer words were never spoken. I wrote that in my sketchbook on the spot and have never forgotten it.
The thing is, that’s really not their fault. It’s actually a product of the role they play in product development — and their position in that chain.
Their view of things is born from precise requirements and specs, detailed meeting notes and perfect Microsoft Project schedules that deliver a crisp, ordered view of the road forward.
And in many cases, they don’t experience any of those details firsthand. Instead, all of that is reported to them by their next-in-command, who’s afraid to show or say anything that suggests even the slightest problem (side note: when in doubt, remember that job security is a powerful, powerful motivator).
So what they are not seeing, what they are rarely exposed to, is the messy reality of how their products actually get designed, built and used.
Now, before we go any further, I want you to think for a minute about why they seem so resistant to doing UX work of any kind.
Ask yourself why they seem to become personally offended at the very mention of user research or information architecture of wireframe prototyping, in a way that seems appropriate only if you were suggesting a diabolical plot to overthrow the government.
From “We don’t have time for that,” to “We know what our customers want,” to “Just make the UI better looking,” the wall of rejection is usually thrown up fast and furious.
So what happens? You get stuck in an endless cycle of revising your work: showing it to the stakeholders, them rejecting and changing everything, you revising, them rejecting, on and on until you run out of time and something must be launched.
To put it another way: you roll the rock up the hill and they roll it back down. And that’s immensely frustrating, right?
Here’s the thing: there’s a reason that happens. And it has nothing to do with you.
It also has nothing to do with whether or not they buy this “UX stuff.” And once you hear the reason why, it’s going to change the way you work from this point on — for the better.
Recognize that their reality is the cause.
The resistance you see from these folks has everything to do with the way they themselves create things — meaning any and every kind of work output.
Whether the thing being created was a proposal, a sales contract or a Power Point presentation, the process probably went something like this:
- Have a meeting to talk about and capture what’s required.
- Create a first draft.
- Share it with the powers that be for review.
- Receive comments (which are really demands).
- Modify the creation to incorporate all demands.
- Repeat steps 3, 4 and 5 until it (a) gets approved or (b) the deadline is imminent and we have no choice but to stop changing the f**king thing.
Now — with this evidence fresh in your mind — is it really any wonder you are constantly fighting scope creep created by stakeholder feedback?
I’ve just given you the process they follow every day of every week of every year, for approximately 80% of the work they are responsible for.
This is the daily reality they live in.
This is second nature, a product of years of accumulated habit and reflex.
This is accepted business practice. In nearly every industry.
Which means it’s not changing anytime soon.
So until YOU modify the way YOU work with these folks, you’ll be pushing that rock up the hill until the stars burn out.
I don’t want you to do that.
I’ve been there and done that, and I still have the scars to prove it.
So I want to show you another way — a better way. I want to show you how to put a stop to this once and for all.
Yes, I know that sounds impossible to you right now, but I assure you it’s not. The fact that I have a career spanning almost three decades — where I am sought after and well paid for my time — is living proof.
Begin at the beginning.
The change I’m talking about begins at the beginning of the project.
If you remember, step one in the typical process I described above was “Have a meeting to talk about and capture what’s required.”
If you do something differently at that moment, if you conduct that meeting in a different way than it normally goes, you’re instantly in position to “sell” the value of UX. You’ll have changed stakeholders’ perspectives without hardly trying.
I detail this at great length in my UX Requirements Made Simple course — part of my UX 365 Academy — but I want to give you a freebie here to prove my point. I want to tell you a little about how this works so you can see the value for yourself.
Tell me if this sounds familiar to you:
- Requirements are “gathered” by a Product Owner and/or other management stakeholders and handed to the development team as written law.
- If you ask how they got those requirements, you’ll likely hear some variation of “We gathered them from the existing system, what customers said they wanted, and meetings with our Marketing, Executive and IT teams.”
In this scenario, you’re in trouble already — because those “requirements” are based on 4 false clues:
- The personal opinions of those doing the “gathering.”
- The technology preferences of the IT department.
- What customers have said they want.
- What everyone is assuming customers want.
When these are the sources for features and functionality, I will guarantee you that there isn’t a single requirement on the list that truly addresses the root cause of whatever issue led to the project’s existence.
There’s nothing here that truly answers the problem that’s motivating the redesign or the new feature set.
This also often means that the problem itself isn’t really the right problem to solve in the first place. No one really knows the reason we’re doing all this, and they’re unwilling to speak up and say so — because they’re afraid to look dumb or uninformed.
So requirements — requested features and functions — are usually little more than opinions and guesses. Both of which are often born from fear.
The problem with “requirements”
Most requirements state features.
Features are solutions.
Which means we have a list of solutions well before we’ve done any work to figure out what the problem is in the first place.
Does this make any sense to you?
Of course not. But that’s exactly why you experience various degrees of endless debate, argument and political compromise throughout the design and development cycle.
At best, this means everything takes a lot longer than it should.
At worst, it means the product fails and causes great pain to every person involved in the project. Mainly to the people who designed it or built it.
I promise you this, friends: you will be held responsible for every decision you didn’t make, and that will suck. Greatly.
One word changes this scenario dramatically.
That’s right, one word.
The word, in the form of a question, is WHY?
When you use that word — and ask it at least three times — you will find yourself having a very different conversation with the folks in the room. Here’s an example.
Stakeholder:
“We have to port all desktop data views to responsive format.”
(Note: this is a solution, not a need)
You:
“Why?”
Stakeholder:
“So people can work on their smartphones.”
You:
“Why would they want to do that?”
Stakeholder:
“So they can get work done when away from their desks.”
You:
“Why would they want to look at these massive data tables on a three- or five-inch screen, when they won’t be able to view all columns and rows at once? That would make it impossible to compare data points.”
Stakeholder:
[ blank stare, because nobody knows if, how or why someone would want to access a data-heavy enterprise reporting system on a tiny screen ]
Everyone in the room now realizes that the need is grossly undefined. And as such, it has no business being a requirement.
A simple exchange like that is all it takes to make people receptive to the idea that there’s a whole lot we don’t know and didn’t think about here.
That’s your opening to suggest the UX and user research work that helps figure it out, that helps generate meaningful requirements that deliver value — both to users and back top the business.
This “WHY” method works better than any other way I have tried — over the last three decades — to get stakeholders to budge from their position that UX work is unnecessary or a nice-to-have.
It works all the time, every time.
And that’s just the tip of the iceberg, so to speak. In the full UX Requirements Made Simple course, I show you step-by-step exactly where to go from there, now that you’ve won the first, most important battle.
It’s part of my NEW online school, the UX 365 Academy.
Check out UX 365 and UX Requirements Made Simple!
I show you exactly how to march forward to victory, in a way where everybody wins.
Sound simple? That’s because it is.
Look, “experts” on my side of the fence love to make this stuff sound complicated. It’s my opinion that they do so simply to protect their livelihoods. They operate out of the fear that if everyone knew that a lot of this was focused common sense, they’d be out of a job.
I’ve never thought that way, and I never will.
Competing for a slice of the pie never made any sense to me; collaborating and teaching so that we can all work together to grow the pie makes a lot more sense.
In my UX Requirements Made Simple course, I’m going to show you things that will leave you astonished as to why no one works this way. I’ll show you how small adjustments to the things you’re already doing can make a radical difference in the way you’re perceived by management, stakeholders and your fellow team members.
You’ll also see how easy it is to get everyone on the same page, sharing the same goals, without a fight. I’ll show you the methods I’ve used for nearly three decades with Fortune 100, 500 and Government organizations, like how to:
- Get a seat at the Executive table during requirements generation, instead of getting them handed to you like written law.
- Reframe user stories and requirements to convince resistant managers and stakeholders of the validity of a UX-focused approach.
- Minimize Requirements and Scope changes during the course of the project.
- Resolve problems of trust, internal conflicts of interest and information inefficiencies.
- Learn methods for quick, qualitative user research that won’t impact budget or project plans.
- Integrate UX validation into an existing requirements process — without disrupting the status quo.
All in the time it takes to watch a movie on Netflix.
These lessons come from experience, and if I’m honest, from a fair amount of hard knocks. Like anything, the most valuable things I’ve learned were born from tough situations where solutions seemed impossible. So I’m not pushing anything here I don’t use myself. And I’ve helped organizations from Fortune 100 companies to Government agencies to startups implement these same solutions.
If you’re tired of banging your head against the wall fighting for UX efforts to be included in your projects, take 5 minutes to check out the course at the UX 365 Academy. See what students have to say about it.
I think you’ll find it to be a valuable addition to your UX arsenal.
And more importantly, I think you’ll see that it carves a path forward to less battles, fewer headaches and a LOT less stress.
