I was recently reminded that even great UX has an implacable foe that it cannot accommodate: the obdurate user.
For me there are three essential elements of an obdurate user:
- They recognise that there is a problem.
- They want the problem solved.
- They refuse to change their behaviour one iota to accommodate the solution.
Almost all users will approach any new product with a degree of bias from similar products or tangential products they’ve previously used. A backup administrator who has previously worked with vendor X will approach a vendor Y product with biases on how the product should work, but this of course doesn’t mean they’re obdurate! Even if someone hasn’t used a backup product before, if they’ve used any other enterprise product, they’re probably going to approach an enterprise backup product with some initial biases. Again, that doesn’t imply obduracy.
The aim of great UX is to mitigate biases by reducing learning curves. (Note: not all learning curves can be eliminated.) Great UX starts by accepting that users may approach a product with a number of pre-existing biases and solves this by applying the three C’s: Coherence, Clarity and Calm:
- Coherence: Except in the rarest of circumstances, no product is a single screen. When a user moves from pages P to Q to R to S to T within the product, design elements and workflows should remain consistent, allowing the user to develop muscle memory in how they review and interact.
- Clarity: Everything in the product should be expressed with maximum understandability. Double-negatives are a great example of reducing clarity, but it goes beyond this – long-winded sentences, spelling mistakes, poor grammar, lack of informational prompts at all, etc., all contribute to reducing user clarity. (And of course, the workflows themselves must have clarity as a whole.)
- Calm: This is the one that’s easiest to miss. The product designers and engineers will instinctively have the best idea of what they can and can’t do within a product. The average user takes time to build up this knowledge. So essentially this is about eliminating or at least wherever possible substantially reducing the fear of surprise, making the product less stressful – even when it’s a brand-new knowledge domain.
Regular users will latch onto those three C’s and adopt a product, even if it works differently to what they’d expect or prefer – even if they don’t particularly like the product. Obdurate users won’t even give it a chance. In essence, the obdurate user doesn’t want a solution based in reality, but some magical solution. The net effect is that if you try to design your product to solve for the obdurate user, you’re wasting your time.
In essence, the obdurate user wants a completely different problem solved.
I was reminded of the obdurate user problem recently when my mother came to visit. Bless her, but when it comes to her iPhone, she exemplifies the obdurate user problem. Let me explain.
Like many people of her generation, she has one volume for her phone: maximum. When you live in essentially a quiet house, having a device that randomly chimes “CHOO” like a steam train engine at seemingly 150dB without any warning (messages) can be a bit of a shock.
Maximum volume works for her because she doesn’t necessarily have her phone with her at all times; it might be in her purse in her bedroom and she wants to still hear it from the living room. But where maximum volume doesn’t work for her is when she’s in bed trying to sleep. I’ll run you through a conversation I’ve had … a few times.
Mum: “I was just drifting off to sleep last night and <random sister> texted me, which of course woke me up and it took me an hour to get back to sleep.”
Me: “You know you can put your phone on silent before bed, right?”
Mum: “But then if someone needs to contact me in an emergency I wouldn’t hear it.”
Me: “OK, so iPhones have this thing called Focus mode. We could set up Sleep Focus for you so that it automatically silences alerts for anyone except people you want to be able to get through in an emergency.”
Mum: “But what if it’s someone who I didn’t add to the list?”
Me: “They’ve thought of that! We can set it up so that if anyone tries to contact you repeatedly it’ll let them through and you’ll hear it.”
Mum: “But what if it’s a serious thing and they can’t try to contact me repeatedly?”
Me: “That’s a pretty small risk though. Now, here’s the good thing. If you turn on a focus mode everyone else who has an iPhone will see you have focus turned on if they try to text you. So they’ll know not to contact unless it’s an emergency.”
Mum: “But what if they’re just being polite and they really do have an emergency but don’t message me?”
Check-mate, Apple. The obdurate user wins. The problem being solved is “how to get an uninterrupted sleep”, whereas the problem the user wants solved is, “how to ensure I only get woken up for an emergency that exactly fits my definition of ’emergency’?”; there’s an overlap, but you’re either looking at a magical solution or a solution directly out of science fiction (e.g., the eButler/u-Shadow concept in the Commonwealth Universe by Peter F. Hamilton – effectively a semi-sentient program that can operate for you to filter data and let you know what gets through the filters).
Here’s the thing: you can’t solve for the obdurate user. Instead, you need to solve for identifying the obdurate user so you can move on from unrealistic expectations. If you don’t make that identification, you’re going to churn through resources without ever actually getting an outcome. To do that, we go back to the start; first, you need to build a comprehensive UX that tackles the three C’s (Consistency, Clarity, Calm), and then once you’ve established that, the obdurate users will effectively self-identify through the problem-exploration phase.