Fear & Loathing of User Research
Why do we hesitate to conduct user research in software-based projects?
So many software producing companies have an inbred fear of talking to their users and customers. Where does this fear come from? Quick answer is that it’s all about hurting people’s feelings.
Typically, almost everyone in the team will be sentimentally attached to the product we work on sooner or later. We put the effort, the hours, our hopes and our beliefs behind our precious software baby. We commit our intellect and energy hoping that everything will work out just fine upon release.
Spoiler alert: It almost never works out as well as we hope. Also, hope is not a strategy!
Transparency hurts
Well conducted user research is always very revealing. User research results shed light over what’s really going on with a product, good or bad, because it involves the end users. Those for whom we build stuff in the first place. Usability fails get uncovered, opportunities get identified and the usefulness of the product is measured.
User research is revealing because it places data and evidence on the table. Opinions are vanquished instantly in front of solid quantitative (numbers and stats) and qualitative results (observations and insights).
Normally, such facts would be the perfect way to make informed decisions for subsequent iteration with minimal risk. However, the sad truth is that evidence and data makes people, that previously made “bets” based on speculation, suddenly look silly in front of bosses, clients and colleagues. People not used to this way of working feel nervous and defensive. This is normal. This behavior is expected because “failure” is hard for everyone.
For so many of us (in the beginning at least), the discovery of flaws in our products and thinking hurts big time. As a result, in most cases, change never really happens. User feedback is unfortunately discarded and used in future product decision-making process. We are not used to receiving feedback for our beautiful baby. Let’s admit it.
That uneasiness against feedback, is translated as fear. Now, we all know down which path fear leads to… (famous Jedi Master quote removed)
Designers fear to discover that the UI we have been creating is unusable. Developers fear to be told to put more work on a feature we already spent ages working on. Project Managers fear it’s gonna take a long time to conduct user research and any discovered product changes will add to our already delayed release. Product Owners fear to go against our boss’s pet ideas and the directives they have received from them, or simply to admit we were dead wrong. C-level execs fear we might be told our baby is awfully ugly.
“Fear is the mind-killer. Fear is the little-death that brings total obliteration”
— Frank Herbert, Dune
Hopefully, all of the above don’t happen simultaneously. Hopefully that is… But hope is not a strategy, we established that already.
Perhaps we all fear to face the truth basically. It’s just human nature: Fear of pain or fear of losing. Losing face, status quo or integrity.
Reckoning is nigh
So everyone in the team chooses to use the ancient ostrich technique and bury their head in the ground (alas exposing other parts of their anatomy). Hide from the truth and avoid testing with users. Therefore, live with the problem and keep back any kind of software release till the big-bang! Avoid pain and wait for the moment of ultimate glory!
Not staring at homeless people, doesn’t make poverty go away. Avoiding to face the problem, only delays and feeds up it’s harmful impact.
“Numbing the pain for a while will make it worse when you finally feel it”
— J.K. Rowling, Harry Potter and the Goblet of Fire
At some point, the team finds out anyway that the product sucks disproportionately. Product gets Big-Bang-released and then the market decides! User feedback is not nearly as expected (or hoped). Not only the interface is not usable, but the product itself has no apparent utility for the users. Thus, making the release not useful software overall.
The true outcome turns up in the worst possible moment by the most harsh judge: the final users. Not just a controlled sample used for research, but all of them. Then it definitely hurts and everyone experiences true pain.
Next thing, everyone realises that they should have measured the levels-of-suckiness sooner. Right after, the blame goes from/to every direction, till projects or companies shut down.
User research is not about discovering who inside the team is to blame for the mishaps of the product. User research is about learning. Not about learning who was wrong, in order to convict them Judge-Dredd-style, but about learning what was not so great, in order to correct it now. What was not enough, in order to adjust. What changed, in order to adapt. It’s all about improvement, knowledge and avoiding failure.
Repent or die trying
You might be thinking that it’s already too late for your project. You’ve been developing for so long that there is no point in spending time at this point to conduct user research. You can always let it backfire after release. Or you can ask yourself a simple question about your product: Is your software useful for your users? Useful, means that it has both great usability and significant utility for them.
If the answer is a hard “YES”, then thank you for sharing the evidence and KPIs that support this statement with your fellow team members. That’s transparency right there.
If the answer is something around the “NO”-ish area, then wouldn’t you prefer to know “where it hurts the most?” and “how much?”, in order to make improvements as soon as possible? Is it better to know now or later?
Would you like to learn more before or after release? Would you rather expose your few bad software issues in front of the entire universe or just to a handful of users?
“Good products are uncommon. Great products are rare. Perfect products exist only in fairytales!”
- Anonymous UX poet
Most products have significant issues. Many products are unusable. An astonishing amount of products totally suck!
Accept the fact that it is normal that your software has flaws and try to discover and improve them. Don’t leave user research and testing for the last possible moment and lie to yourself that you can’t do it, because you can.
If you are interested to know more about user research and how to do it rapidly and iteratively, have a look at this case study (this one is from the life insurance domain)
If you want some advice contact us at hi@zanshinlabs.io to help you apply this approach to your specific product needs.
