If you are a User Experience (UX) consultant, or a client who often outsources to UX consultancies, then this post is for you. It’s about UX skirmishes. In case you don’t know, a skirmish is a military tactic where the attackers move in swiftly, do as much damage as they can before the enemy has a chance to respond, and then leave.
Delacroix (1863) Arabs Skirmishing in the Mountains.
So what’s the link to user experience? Well, lets compare this to a typical UX research project:
- The client contacts the UX consultancy with a product that’s almost ready for launch.
- The UX consultants barely have a chance to meet the design team before the research starts, learning little about the processes, politics and business objectives that made the product what it is.
- A few days later, the research sessions have been completed. Blink and you’d have missed them.
- The UX consultants retreat to their lair where they prepare a flashy presentation.
- On the day of the big presentation the client is bewildered but impressed. Lots of pain points have been uncovered. Things are more screwed up than they’d hoped, but they are thankful to have done the research.
- Right at the end, they have a paltry 30 minute Q&A where the client desperately tries to clarify their understanding of things.
- Before the dust has a chance to settle, the project is over. Someone is assigned a list of actions to “fix” the problems, but no budget is set aside for further research to check whether the actions actually solve the problems they are meant to.
- Months later, the UX consultant looks at the outcome. “Oh dear,”they think to themselves, “the client botched a few things up. Why didn’t they listen to my recommendations?”
So, do you notice the similarity here? Like it or not, a typical UX research project can be very skirmish-like. I’m not saying it’s malpractice – far from it. A skirmish delivers good value for money compared to no skirmish at all, and the evidence is in the fact that the clients keep coming back for more. Skirmishes uncover a lot of problems that the clients simply would not otherwise be aware of.
But here’s the clincher: problem identification is just the beginning of a long and tiring journey. And just at the moment the going gets tough, the UX consultant packs up and goes home.
The problems they uncover need to be properly understood and prioritised according to alignment with business objectives; appropriate solutions need to be designed and costed; new technologies may need to be considered; prototypes need to be built and then tested to ensure that the target problems have indeed been solved. This process is enough to sap the will to live out of the most well meaning team, so on top of everything else, they also need help to maintain passion and a unified vision of success.
With this in mind, it’s no wonder that successful UX research projects don’t always lead to successful products.
So what should consultants be doing?
- Periodically check in with the client once the redesign process is under way. Your findings need husbandry.
- Consider offering discounts for longer projects. You’ll not only help your clients more, but you’ll increase your billing efficiency by having fewer gaps between projects.
- Educate your clients that the “bolt on at the end” or “one big user study” mentality is a fallacy.
- Push back on your clients when necessary. If they want to blow their budget on a massive eye-tracking extravaganza when two or three smaller iterative studies would be more effective, it’s your job to talk them out of it.
- Make sure that not only does the client attend the research sessions, but that they also actively engage with the findings. Ban laptops and phones. Give them note-taking responsibilities. Have mini-workshops between sessions.
- After the testing, engage them in the analysis process rather than disappearing off to your lair to craft a shiny presentation.
Back when I worked at Flow Interactive, Phil Barrett told me that their goal was to educate their clients to such an extent that ultimately, they’d stop needing to use Flow at all. Conventional thinking would suggest that this would kill the golden goose and you should always try to keep your magic recipe secret. In reality, the only thing that happens is that your clients start to love you, and those who do reach independence become vocal advocates of your services.
When a client asks you to do a poorly planned research project, it’s easy to roll over and sell them exactly what they are asking for. It takes courage to disagree with them when they’re wrong.
Great post Harry, I really identify with the skirmishes you refer to.
Love this blog
Excellent post. I couldn’t have put this any better myself.
It’s actually quite hard to persuade people out of the extravaganza. eyetracking or otherwise.
The tendering process is also a big hindrance to providing good guidance.
Pingback: February UX Roundup | UX Booth
Interesting point, but I think the real root of the problem was addressed in your first point:
Effective UX requires a holistic approach that starts on day one, not on the tail end of a project. Can we blame UX consultants that get called on day 364?
You’re absolutely right. Still, we’re kind of complicit in the whole thing if we let it keep happening over, and over, and over again.
Everything about the majority of clients production cycle is so badly broken that all most of us can do is help address mInor issues.
Most projects I’ve consulted on have uncovered fundamental problems with the proposition. To address these issues they need to restructure their product offering. At the user testing stage nobody wants to hear the truth do these issues are ‘parked’.
In our role as practitioners we witness how the structural failure of organisations negitively affect end users. The user interface is the visible manifestation of the organisation. Only by changing how that company thinks and acts will we enact significant positive change. For most of us we are far too far down the food chain to influence change.
You can’t win them all!
Pingback: Our Bookmarks: Dec 7 - Dec 13, 2009