Joe Natoli has spent over 30 years working in UX.
Over the decades, he has helped over 280,000 UXers through his courses and mentorship.
There are 48 countries with a lower population than that.
We talked to Joe about confusing UX terminology, the struggle of UXers to get a “seat at the table”, and the differences between practical and professional UX work.
This article summarizes what we learned from him on:
As a practice grows and matures, its practitioners develop a lingo they use to talk to each other.
Joe sees this as a good thing — a sign of a developed industry.
But UX is a developing industry.
Folks going to business school are taught nothing about design & research.
Businesses are run, therefore, by people who don’t truly understand design or research.
Talking in UX terms therefore leads to two problems:
In Joe’s experience, organizations come around to hiring UXers AFTER having suffered dire consequences.
The process looks like this:
Business gets kicked in the teeth → hires UXers
A company he worked with (an enterprise behemoth worth somewhere around $ 2.4B) had customers clamoring for a self-service solution. But the company was ignoring those cries.
“The company dragged their heels, because they could; they were the market leader, the only game in town. Customers had nowhere else to go. That changed when two competitors entered the market offering a better service at 25% of their fees! The company lost hundreds of millions of dollars within six months… and quickly came to the conclusion that maaaaybe it should invest in that UX stuff they’d been hearing so much about.”
Even at this stage, the function of UXers isn’t clear — most organizations hiring this way do it because they know they need to respond to those tiresome teeth kicks.
The result? UXers end up in organizations that need them, but don’t really know why..
As previously established, most folks running the organization don’t really understand product or UX.
No wonder UX terms are just strange noises for them.
It is funny to imagine the PM hearing “womp womp womp” as you explain contextual inquiry or information architecture or the double diamond process. However, this is not good for the UX industry overall. The PM must understand what you’re talking about. They must understand why any of that matters to them and their project goals.
There are a ton of organizations with a few UXers and no idea what they’ve been hired for.
This is the result of these organizations being confused by UX terminology.
Before you can have any impact on the organization, it would help if anyone outside the UX community understood you.
We discussed these problems with Joe. Here are some words of advice about each!
All too often, we hear UXers complain (rightfully) about organizations giving them barely any autonomy at all. Why hire someone if you don’t want to hear them out?
Is it ridiculous that UX people have to fight for a seat at the table?
Absolutely*
*However, as Joe says, “you can deal with what is, or you can waste a lot of time wishing it was some other way.”
Joe suggests a pragmatic approach to UX in such situations.
You could be overly dogmatic about the process and be confrontational towards executives who just don’t get it. That would be akin to banging your head against a wall and serve only as comedic relief.
Here are some ways to show the value of UX to everyone else.
Each organization is unique. They carry with them a unique set of UX problems.
Joe does not have a single, set way of approaching all his clients; instead, he adapts the processes and methods he uses to suit the project. Each situation, each client, each product, and each user or customer base brings a unique context with it. That leaves no space for dogmatic process. He believes that being too rigid about what counts as “good” UX can stop UXers from doing what’s important.
Joe suggests that all UXers focus on what the organization cares about.
What are they trying to achieve? How do they currently work? What bottom-line business and financial realities are driving both of those things?
“We're leading with things that we care about, but we're not leading with things that all those people we're trying to convince care about. You can talk best practice all day long, but they don't get it. You're talking in a foreign language to someone who doesn't speak it.”
Improving your organization’s current workflow will always be better than implementing a brand new workflow because it’s a “best practice” you read about online or in a book or a course.
The UX world is hounded with dogma. UXers often tend to love the process more than the outcome! Theoretically sound process, however, is often impractical.
On our call, Joe told us of a team that had one whole workday for user research. Eight hours.
The intel was to be presented to the board of advisors and missing the deadline would kill all hopes of receiving funding.
Joe’s advice to the team? “I told them to split up that 8 hours into 15-minute chunks and conduct as many user interviews as they could. Transcribe these interviews and go through all of them together, as a group, to find common patterns — things users had trouble with, or complained about, or wished was different.”
This was not an ideal research approach by any means, but it was good enough.
Getting caught up trying to do things ideally was impossible for the team. They simply did not have 4 weeks and infinite resources to get to the answer. They had 8 hours, so they did what they could and what they had to in order to get user input.
If you somehow end up on a research team with endless autonomy, time, and resources, you can pursue that ideal, perfect-world research.
That, however, is rare.
In the corporate world, teams are struggling for a seat at the table.
Under such circumstances, doing whatever it takes to reach the desired outcomes should be your goal.
Joe loves and recommends Erika Hall’s book, “Just Enough Research”.
It is a guide to practical research that will help you sidestep the dogmatic mentality of doing things perfectly.
Design and research programs will make you adept at reading through a problem statement and coming up with a step by step design or research process. Joe understands the importance of this skillset, but encourages UXers - again - to be practical. In addition to those common best practices, it is helpful to build the skills to convince stakeholders and get over roadblocks.
As a UXer, you will be working with business stakeholders who are real, emotional human beings. No matter who you report to, they will have some personal stake in the results you produce.
Joe’s advice is to start by uncovering and discussing the fears they have. Without going into specific deliverables or even the desired business outcomes, what is it that they personally want out of your work? What are they on the hook for achieving? What does their next promotion hinge on? What can get them fired?
Once you identify stakeholders’ personal fears, Joe says, the next step is to work on alleviating them.
If left unchecked, those fears can interfere with your work as stakeholders push irrational deadlines and expectations on to you.
“When someone gives you an irrational demand of some sort, that irrationality is coming from fear. They're afraid of something, and you have to figure out what it is — because you can probably address it in a better way. Instead of doing whatever they say they want by next Friday, you can solve that issue in a way that actually makes them happier and more relaxed.
If you have a product manager asking you to create 10 new features by Friday, or run 3 new studies this week, you can argue about timelines and deliverables all you want.
That would lead you exactly nowhere.
It's the wrong question.
It's the wrong argument.
To break through this irrational roadblock, Joe suggests, take a time out and find the fears the PM wants to alleviate.
“Tell me what the situation is: what is that deliverable supposed to prove? Or show? Or communicate? What does this person need to see or know or be able to do with what you give them? That's the right question. And then you create a deliverable, whatever it is, based on the answer to those questions. There's no such thing as the ‘right’ deliverable; there's context. What are we trying to accomplish here? How is this artifact going to answer that need? I don't think we're taught to do that — and we should be.”
What do they need to know?
What metrics do they need but don’t understand?
Why do they want it by Friday?
Take their fear into account. That would help you approach your work as a problem solver first and a UXer second. That would help you look at the bigger picture.
Once you consider:
you will have the ability to look beyond the project’s deliverables and take the bigger picture into account.
As a UXer, you will often be provided with project requirements to be fulfilled — number of screens to be designed, number of usability tests to be conducted, etc. But that isn’t enough information!
Get more clarification on the outcomes the organization needs. You don’t want to find yourself with all the desired deliverables and yet none of the desired outcomes.
What questions does the organization need answered?
What is your work supposed to prove?
Approach deliverables in a top-down manner. Understand the desired outcome and then plan the deliverables that will lead to it.
The alternative is to go through the motions and just finish all the work assigned to you by your employer. This approach leaves the organization unsatisfied and the UXer impactless.
Now that you are geared up to demonstrate your value, you must talk in a way everyone understands.
Here are some ways to show the value of UX to everyone else.
TLDR: Cut the bullshit.
But of course, we love bullshit when it comes from us.
At the start of his career, Joe constantly felt like no one was hearing what he had to say.
After facing multiple run-ins with the same issue, he had an epiphany.
“I was banging my head into walls all the time: why is this not working? And finally, it hit me. I finally got it through my thick head: wait a minute — they don't UNDERSTAND any of this! They say they do, but they don't.”
No one else in the organization understood a word of what he was saying.
Everyone heard what he was saying, but it never made sense to them.
They nodded and they smiled, but nothing ever moved the needle.
“I went back to something that my father has always preached, which is clarity, simplicity. Dispense with everything that you feel like you need to say in order to exude professionalism or formality or whatever — and make sure that you're communicating. When you write things, write them with the assumption that no one has any idea what the hell you're talking about. When you present things, present them as if no one has any idea what you're talking about. That forces you to keep it simple and clear.”
Leave the buzzwords to the McKinsey people. When the rest of the organization understands you, you’d have at least the option of rallying them behind your work. Winning buy-in is the only way a UXer can create an impact on the organization.
When in Rome, mention your impact on the bottomline.
UX folks don’t speak business. Business folks don’t speak UX.
As a result, UXers end up overruled and frustrated.
Joe acts as a bridge between two segments who are speaking different languages to enable them to understand each other and work together effectively.
He recommends that we all follow suit — talk to businesspeople in terms of outcomes!
“In order to convince business people — who have zero context in terms of the work that we do — you have to talk to them in THEIR terms, not yours. You have to talk to them using words that they understand.
I'm a big fan of saying that UX folks need to understand Business 101. You need to understand how market share works. You need to understand what's on that profit and loss sheet every year. You need to understand what their quarterly financials look like.
You have to understand these things in order to make a good case and say ‘this is worth doing,’ because otherwise you're only addressing a fraction of a fraction of something that’s as huge as an entire universe.”
Understand what the organization’s quarterly projections look like.
Understand what their books look like.
Understand where the money is coming from.
Armed with this knowledge, UXers can make a legitimately strong case for why their work would improve the outcomes of the organization. If the business people don’t understand how UX is contributing to their outcomes (we’re talking $$$), the UX org will be ineffective at best, and short-lived at worst.
No one would care about, say, best practices or democratization, UNTIL they see it as a means to improved outcomes.
So one last lesson from Joe—take business 101!
You can read more of Joe’s thoughts and access his courses on https://givegoodux.com/
Looppanel automatically records your calls, transcribes them, and centralizes all your research data in one place
