I was in a meeting once where there was a religious argument between groups of developers, database folks, product owners and executive managers.
The topic: why a certain report screen was taking so long to load.
(1/12)
It was a report clients were asking for; they log in, enter their credentials, enter a date range, set some filters — and then the system would literally take up to three full minutes to fully load the report.
You literally got a blank screen for several minutes.
(2/12)
The database folks are barking: "our infrastructure prevents us from doing this any other way, dev needs to do things differently." #Developers fire back: "it's a needlessly complex data structure." #UX folks are angry with both groups: "we TOLD you this would happen."
(3/12)
Things are getting heated.
I usually let people get their stuff out on the table before I speak. If I pipe up before everyone's had their moment to defend themselves, nobody listens. So I wait to interject, interrupt and calmly redirect the conversation.
(4/12)
There was a young developer who hadn't said anything for the past hour...and before I could open my mouth during a lull in the argument, she beat me to it.
First, she raises her hand — and they totally ignore her.
(5/12)
After 15 seconds, she's not having it — she stands up and walks to the center of the room. She waits for everyone to shut up, puts her hand down, looks around and drops a BOMB:
"How do we know anybody wants all this stuff in the first place?"
Silence. Jaws open.
(6/12)
Uhhhhhhhhh..oh. Uh. Oh.
See, nobody thought to ask that question.
They were all too busy defending their positions, mired in their egos and their own "right way" of doing their job, to take a step back and THINK.
(7/12)
Fast forward: the team digs into that question for a couple of days and actually starts talking to customers — and in doing so, they learn that all customers really want wanted were three or four summary data groups.
(8/12)
They ALSO learned that anyone who actually *needed* the full report didn't even want to see it onscreen — they wanted a PDF file that they could download and print out.
Entirely different process; a LOT less load on the system.
(9/12)
Put together a document behind the scenes, email a link to folks who need it. Instead of making them wait three minutes for a whole lotta stuff they don't really want to see in this format anyway.
Good UX means asking hard questions.
Which often takes courage.
(10/12)
Like the courage of the young lady in my story here.
Here's the lesson:
Despite what you may think, no one in that room is smarter than you are.
(11/12)
Their experience or position doesn't remove the blind spots we all have. You're there to help them recognize and recover from those moments; they are there to do the same for you.
But none of that happens unless you find the courage to open your mouth.
(12/12)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
A significantly large number of companies and organizations share three specific traits when it comes to #UX improvement and #ProductDesign in general:
1 - They don’t really know what their users or customers actually want.
(1/13)
2 - They’re under the mistaken assumption that surveys or their NPS scores tell them what the value of their product/service is to those users.
3 - They’re not willing to allow you to talk to those users to find out what they actually need or hope to accomplish.
(2/13)
I get enough emails and DMs every day to tell me that this is reality for most of you. And the question folks ask me is always the same:
What the hell do I DO?
My answer tends to ruffle some feathers, but here it is.
Them: "We never have enough time to do proper user interviews."
Me: "How much time do you have?"
Them: "a week."
Me: "Let me tell you a story..."
And the story, #UX and #design friends, goes like this:
(1/11)
I was consulting with an organization, whose team needed to do some research; interviews specifically. They said "well, we have 24 hours based on our schedule…but we have to get to this other work to make deadline and right now it's all hands on deck."
(2/11)
So the team can't spare the manpower or the people and there were lots of reasons why that date couldn't move. In the end, we got eight hours.
Eight hours to talk to users and get some sense of what's going on here.
I will be 54 this year. I have helped product design and development teams and individuals in startups, mid sized orgs and global Fortune 100 orgs in 23 U.S. states and six countries in almost every industry you can think of for thirty (30) years.
(1/11)
And across that span and across all those companies and industries, I have seen the same patterns and the same situations over and over and over again when it comes to the power, autonomy and authority far too many people assume #UX and #UI Designers have.
(2/11)
The common thread over every experience across that time is that the majority of organizations still operate in command-and-control fashion when it comes to Design + UX.
The marginalization, devaluing + disempowering of UX and Design folks isn’t a bug, it’s a feature.
Ever wonder why executives and bosses are often so resistant to doing #UX work?
Why they seem to become personally offended at the very mention of user research or #IA or prototyping, in a way as if you were suggesting a diabolical plot to overthrow the government?
(1/9)
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 thrown up fast and furious.
Where does this come from, and more importantly, how do you deal with it?
(2/9)
Let’s start here: 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.
To me, EVERY meeting is a working meeting. So the very first time I speak to a room of stakeholders during a consulting gig, I am absolutely not doing the dog-and-pony show of presenting with slides.
(1/12)
I am here to do one thing and one thing only: make an IMPACT.
Leave a firm, lasting impression that they will not ever meet another consultant cares as much about helping them succeed as I do.
Which means I’m here to talk about *them.*
(2/12)
What they need. What they’re struggling with. What they think is wrong and what needs to be made right.
This also means that even if I don't have the gig yet, instead of sitting politely + taking turns, we’re going to dive in together + interact. Trade ideas.
#UX and #design friends, we need to talk about estimating. I'd like to share some advice that's come up 3 times this week, in hopes it's useful. And it's echoed, by the way, in the BUSINESS OF UX course @EliNatoli and I are teaching at my UX 365 Academy (link at the end).
(1/12)
Avoiding wars with clients is a matter of how you structure your engagements, along with how you spell out what you're doing in your proposals/contracts. That starts with estimating.
The biggest 2 rules I follow are these:
(2/12)
1. I do not EVER estimate a project in full from start-to-finish.
2. Once we're past initial Discovery (see below), I estimate in small chunks, e.g. "here's what will take us to the next iteration/review."