Why 'being brought in early' isn't always what you want
Building UX influence and effectiveness in low maturity environments
One of the classic complaints of UX Designers, UX Researchers and Service Designers is that they are brought into projects ‘too late’.. e.g. decisions have already been made or everything is already on fire.
This is a complaint born of experience and because it’s exhausting to be an afterthought when decent designers know their craft can and should add value all the way through a project, from its initial inception.
However.
Rather than write another article about how messed up the industry is and how much designers are wronged and disrespected, I’m going to give you a different hot take:
I’d rather not be brought in early.
What madness is this?!
Low UX maturity sets you up to fail
OK. So let’s assume for a moment that you don’t work in a highly UX mature environment. Let’s assume you, like most people, work in an organisation where you spend a fair amount of time on one of the following:
Explaining what UX is
Explaining why talking to users is important
Fighting for research budget
Asking for time to think or iterate
Attempting to slow down the rush-to-solutions
Well done. You’re like most UXers.
Why being on a project from the beginning can backfire
Now imagine you’ve been invited to the party on the first day. You’re so excited. You turn up to the first meeting ready to talk about your process, or even just how you can help connect stakeholders to user needs.
But you don’t get a chance to speak.
Or you mention doing some work to help frame the problem
Or you mention research and get dismissed.
Why aren’t they listening to you?
Because at the beginning of the project there is no risk.
And no risk = no rigour. The amount of time and resource you get to practice your craft depends entirely on stakeholder perceptions of how much risk your work will remove.
No risk = no investment in craft. And not a lot of support for any kind of design process.
You’re here to prove that “we involved UX”
I’ve seen so many designers get frustrated because they didn’t get to contribute to a project as an actual designer. Yes they were brought in at the beginning, but essentially just to sit in meetings as some kind of witness-to-the-madness so that a project manager could tick the politically expedient box of ‘‘involved UX’.
Or maybe they patted you on the head and didn’t stop you running off doing discovery work, but didn’t want to hear the playback where you challenged the entire project’s premise.
You’re basically a passenger on the project. Somewhere down the back of the bus.
Why being brought in half way through can be great
So what’s the alternative to being a passenger?
Well, it’s being brought in as an emergency service when the bus catches fire.
Because when the bus catches fire, they need someone to fix it. Here are some typical mid-way-through UX or Service Design flavoured emergencies:
They realise they’re working on the wrong problem
They forgot to gather requirements or align stakeholders
They discover a competitor has beaten them to it and need to pivot
A senior stakeholder has asked where The UX (or evidence) is
An entire team of business area has not been consulted (e.g. operations) or a massive dependency needs to be investigated
They finally tested something and users rejected it entirely
Something that someone made up cannot be built
They’re missing something important (e.g. Content. Some architecture. A mechanic to make the whole thing make sense to users. Any kind of KPIs. A team to maintain it. Evidence)
All of these indicate that someone now needs to come in with their back of methodological tricks and, as quickly as possible, do a ton of work to fill the gap before anyone notices and without slowing everything down.
By the way this is NOT the time to point out that if they’d invited you in at the beginning this wouldn’t have happened or that in their haste to not have you ‘slow them down’ at the beginning they’ve blown up their own bus.
What this gives you
… is power.
Because now there is risk. And risk = rigour.
It’s true, you’re not going to now be allowed to rewind the whole project and run some glorious UCD project like it’s 2008. Because it’s not. You are going to have to do a load of scrappy fixes in a short amount of time.
However.
You now have their attention. You are standing in the middle of the party (on a bus?) with the fire hose.
Now you get to ask for the minimum time and materials and stakeholder attention and access to users resource you need to do some kind of design process that adds value to the project.
You’re not the passenger and you’re not ignored and you’re making a valued contribution.
Take a bow
The impact you have at this point and your ability to deliver it efficiently, humbly and without rubbing their nose in it with an I-told-you-so (however tempting that might be) is your USP. It’s your case study. It’s the value you bring that might just get you invited to the party next time with a seat at the front of the bus.
And it might just not have to catch fire at all.