We know it is important to listen to users and get feedback on our product in order to make it better.
But what do we do with the feedback that we get?
For instance, if a user of our app tells us:
”I hate this dropdown, it’s not intuitive. I really wish that it was a slider to select the things I want.”
Or when a reader discusses our book:
“I don’t like this part of the story, it really drags on. I wish there was some sort of fight scene here and that could really make it exciting.”
What do we do?
Do we implement what the customer suggests? Or do we ignore the feedback, and keep building what we originally set out to do?" As Henry Ford says:
“If I had asked people what they wanted, they would have said faster horses.”
Henry Ford
The problem with this quote is that it’s not asking the right questions to the user.
Don’t ask a user what they want (ex. I want a faster horse).
Ask the user what their problems are (ex. I’m not going fast enough).
Learning from doctors
We can learn how to gain valuable feedback from our users by taking a close look at how doctors interact with their patients.
Imagine, a patient with a headache walks into the doctor’s office and asks for help.
Patient: Hi doc, I’m glad to see you. I really haven’t been feeling too good lately and I was wondering if you could help me.
Doctor: Of course! What are your symptoms?
Patient: I’m having a headache with some ringing in my ears, and I’m having some trouble sleeping. I honestly think it might be a tumor, I’ve been watching a lot of tv lately and I’ve been researching a lot on WebMD and I think that might be the issue.
Doctor: How long have you been having the headache for?
Patient: Around one week.
Doctor: And on what part of your head do you feel the headache?
Patient: On the back of my head.
Doctor: Do you drink caffeine?
Patient: I used to quite a bit, but with my anxiety acting up I stopped cold turkey, why do you ask?
Doctor: (jots notes down) I see, I think I might have an idea of the cause for your headache but I will ask a couple more questions just to be sure.
In this example we see two things:
The doctor focuses on the symptoms of the patient.
The doctor keeps asking questions to get more feedback on what the patient is feeling. By doing this, the doctor narrows down what the potential diagnosis could be and increases the chance of diagnosing it properly.
The doctor keeps the patient’s suggestion in the back of their mind, but does not leap to that conclusion.
It is the doctor’s job to diagnose the problem, not the patient. It may very well be a tumor, but that decision comes down to what the symptoms are of the patient and the doctor’s diagnosis.
How does this relate back to our field of choice?
As the creator of a product, it is important to remember that:
The user is almost always RIGHT about their problems with our product.
If the “story drags on” or “I can’t find where the menu is” or “I don’t know what you’re trying to say here”, the user is almost always right.
There is something wrong and it’s important to dive deeper with what the user finds wrong with our product by asking more questions about which parts the user had trouble with.
The user is almost always WRONG about how to solve our product problems.
We constantly need to remind ourselves that as the product owner, we are the problem solvers of our product, not the user.
Like doctors, it is possible that the solution they come up with is correct, but we ultimately need to take a step back and dive deeper into their symptoms in order to come with a solution that will solve the problem with our product.
TL;DR
It is important to listen to feedback from users, but remember to listen to your users as a doctor would a patient - to take their problems (or symptoms) seriously but their solutions (or diagnosis) with caution.
Top comments (0)