A friend of my dad once had a long commute to work. It was the better part of an hour’s drive, which I consider a long commute. One day, towards the beginning of his daily travels, an opossum scrambles out onto the highway. Being a good driver he doesn’t swerve, knowing that to swerve could endanger human life. So he did something I’ve done before… kept a straight course and wished the little thing the best of luck.
He then heard that awful “kerchunk” sound of the opossum rolling a natural one in the adventure of life, a life now snuffed out by an impartial rubber tire going 60mph.
He thought that was that, and continued on his drive. But as he went, he heard a steady rhythmic clunking sound. With a bad feeling in his gut he pulls over onto the shoulder, stops, and gets out to look for whats making the sound. To his horror, there, jammed inside his fender was the opossum — dead, of course, and hanging by it’s tail.
Well he couldn’t just keep driving like that so he cautiously used his foot to kind of bump the opossum in hopes he would dislodge it. But try as he might, it didn’t dislodge. It continued to hang in his wheel well, lifeless.
So with grim determination, he wrapped his hands around it’s mangled carcass and gave a hard pull. Little by little, and with much effort, he managed to get it dislodged. He cast it into the roadside bushes and tried to decide how to clean his now dirty hands.
This was a truly uncomfortable experience, but here’s the part that’s important to us: in his mind, he was blaming someone. Who was he blaming?
Nature? Bad luck? The county? The highway department? Himself?
In fact, mentally he was blaming the automaker of his car. He was blaming the engineers who designed a wheel well that had enough gaps in the shielding to snag a opossum tail. All of those bad things he felt while pulling on the lifeless marsupial, he transferred to that automaker.
That brings me to what probably should be a Law of Customer Experience (but isn’t, yet):
A customer will blame the product they are interacting with for any negative experience during that interaction, even if it is not the product’s direct fault.
Now, for a real-world application.
I work on a home search product. You know, a site where home shoppers can look up homes for sale in their area. Myself and others have put years of UX research into this site, as well as understanding home buyers and sellers at an extremely detailed level.
One thing that home search sites do is send you an email when new homes are on the market. One day we had a user who got their daily new listing update, opened the email, and rather than seeing a gorgeous curbside photo of a house like they see every day, they instead saw a close up of a toilet with trash all around it and dark horribleness inside, on a $500,000 house no less.
Understandably, the user didn’t like this — who would? And thankfully they let us know. We make it very clear, all of our listing data comes from Multiple Listing Services (MLS). The United States has over 3,000 MLSs and homes can only be added to these MLSs by licensed agents and brokers, and in compliance with their respective MLS rules.
The vast majority of the time, those layers of checks is enough to ensure a certain level of quality in the photos and data. But clearly, shit happened. From our standpoint we were given the bad photo through an automated process. But the customer didn’t care about that. They saw this terrible photo because our technology passed it along to them. We can’t hide behind thinking “oh well it’s not our data we can’t help it” when it’s us who are forcing the customer to yank on the proverbial opossum.
But let’s be real here: the opossum is an edge case. I mean, when an automaker tests a car, how many rodents, dogs, cats, and marsupials do they run over in track testing? (I’m not in the automotive business but I have an overactive imagination.) The toilet too is definitely an edge case. That kind of thing is very rare.
So what is the appropriate way to approach edge cases?
I’m here to suggest that you already know how, and have all the tools you need to handle them. Why do I think this?
If you’re a qualitative researcher you don’t typically swim in the pond of statistical significance. We interview or run testing videos on 5, 10, 12 people, and from that we usually learn plenty. How? Because we use them as a voice.
I believe qualitative research is vital, but we can’t ever pretend it has statistical significance. In my daily practice I avoid serializing qualitative research into numbers because it can present a false impression of statistical significance. So we don’t say, “7 out of 10 users think X”, because a product owner will naturally think we’re representing 70% of all their users. We’re not.
So we fuzzy it up a bit, saying things like one, some, most, or all. It’s not perfect, but it helps. I will often go more vague and say “we’ve heard that…” and state the insight. Often I will be asked “how many”, and I will say how many, but add a reminder that it’s not statistically representative of the whole of their users.
The important thing about qualitative research isn’t how many people said a thing, it’s that someone said a thing. It’s all about the voice. Let me say that again: It’s all about the voice.
So lets go back to our edge-cases. The opossum. The toilet. How do they matter to a business and to a product? Statistically, they do not have any value. Probably the worst thing the automaker could do is make a team of expensive engineers spend a week designing a opossum tail blocking shield, making a prototype, testing it somehow, and then probably engaging a third party to manufacture them, then adding a step in assembly to install them. That’s ridiculous. The other option is to ignore it.
But, qualitatively, the edge cases are a voice and as a voice, they matter. So how would you approach the opossum problem, or the toilet problem, as if it came up in qualitative research? Because really, that’s what this is.
So I hope right now you’re picking up on your own answers, but let’s stay here for a minute. For the opossum, you could use it as a signal that maybe the wheel well design needs a review overall. Maybe if a opossum gets stuck, other things get stuck. Now we can scope our next line of inquiry from unlucky marsupials, to literally anything that gets stuck in there. Maybe those findings lead us to systemic issues that add up and, when redesigned, solve the opossum issue and two dozen related issues.
For the toilet photo, all I can say is we’re working on it. The right kind of conversations are being had, not simply around how to block future poo photos, but how to detect and respond to potentially objective photos at scale and in a compliant manner. Weirdly it’s harder to not display a picture.
The two takeaways I want to hammer home are again: 1, The user will blame the product they are using for all negative experiences while using it. And 2, Treat edge cases as you would treat user voice. Use it to open broader lines of inquiry rather than patchwork fixing the specific issue, and try to solve the root of the issue if you find that there is one.