You launched early and your users' feedback is all useless or wrong. How to get useful feedback?
18 comments
So you just create a contact form and expect feedback to come in without any effort?
Buy lunch for 5 local users and brainstorm. Get your friends to try the app, have a dinner party and brainstorm. Go to survey monkey and add a short survey to your app.
You need to seek out feedback from a broad spectrum of your users and ask specific questions (hopefully based on the voluntary feedback that you've received to date).
Buy lunch for 5 local users and brainstorm. Get your friends to try the app, have a dinner party and brainstorm. Go to survey monkey and add a short survey to your app.
You need to seek out feedback from a broad spectrum of your users and ask specific questions (hopefully based on the voluntary feedback that you've received to date).
Here's how I try to think of it. There are going to be some features that you realize are crucial to add. They'll be so obvious you won't even need to write them down. The point of getting user feedback is not to get requests for random little things, but rather to find out how they are using the site, and discover with them those crucial features that are obviously needed.
It's very possible you're missing the point, unless the users are spamming you guys, which, in that case, would be your fault for not wisely selecting a private beta.
What do you mean by bad feedback? In most cases, "bad feedback" occurs when startups disagree with their users. "You'll see," they say. Well, you know how that story ends.
What do you mean by bad feedback? In most cases, "bad feedback" occurs when startups disagree with their users. "You'll see," they say. Well, you know how that story ends.
Evaluate what you yourself define as useless and useful feedback.
I define useless feedback as people telling me that they want some obscure feature which I then implement and then, predictably, no one, not even the requester ever uses at all.
I think the problem there is that you aren't understanding what they're asking for. I'm sure they are being perfectly clear in telling you what they want but something weird happens when users describe features and wish lists. They often don't know what they want. Finding that out is YOUR job.
IMHO, what you need to do is ask them what would make it better and then dig in to find out what they really mean. Why do they need that feature? There's no script or formula to do this, but that's one question I've found to be useful.
For example, User A says: put a link on my profile, which when clicked shows my age, sex and location.
You should ask, "why do you need that?"
The User will often respond in some way which will give you a clue as to what they're really looking for.
So, the response to that question might be, "oh, well, people always email me to ask me what my a/s/l is and I'm tired of telling them."
So, using this (very lame!) example, they're not looking for a link - they're looking for a way to show their a/s/l on their profile. You can give them what they really want, not what they're asking for.
I hope this makes sense.
IMHO, what you need to do is ask them what would make it better and then dig in to find out what they really mean. Why do they need that feature? There's no script or formula to do this, but that's one question I've found to be useful.
For example, User A says: put a link on my profile, which when clicked shows my age, sex and location.
You should ask, "why do you need that?"
The User will often respond in some way which will give you a clue as to what they're really looking for.
So, the response to that question might be, "oh, well, people always email me to ask me what my a/s/l is and I'm tired of telling them."
So, using this (very lame!) example, they're not looking for a link - they're looking for a way to show their a/s/l on their profile. You can give them what they really want, not what they're asking for.
I hope this makes sense.
You shouldn't blindly implement features just because your users are telling you to do so. While it is important to listen and react to your user's concerns, it's also your responsibility to maintain the integrity/consistency of the application. Also, if you don't believe that the feature you're building is going to have any effect, then it's already heading towards failure because you're not going to be committed to its success.
I agree with jkush -- if you don't agree with the user, you should engage the user and see if you can get the feature to a common ground that you can agree with.
Also, if your feedback loop is just an email, maybe you should add a forum to make the loop more interactive.
I agree with jkush -- if you don't agree with the user, you should engage the user and see if you can get the feature to a common ground that you can agree with.
Also, if your feedback loop is just an email, maybe you should add a forum to make the loop more interactive.
"engage the user and see if you can get the feature to a common ground"
Yes, this is what I'm asking. In direct marketing for example, there are ways that success can be scientifically measured. I am wondering if any of you have used more methodical approaches to improving applications -- or if it's just guess and find out if it worked 2 months from now.
The reason for this is that I just don't always trust users to think deeply enough of the problem for them to know what they want.
Yes, this is what I'm asking. In direct marketing for example, there are ways that success can be scientifically measured. I am wondering if any of you have used more methodical approaches to improving applications -- or if it's just guess and find out if it worked 2 months from now.
The reason for this is that I just don't always trust users to think deeply enough of the problem for them to know what they want.
A great thing to do is invite your target users to try the app/service in your presence.
But don't lead them or demo anything; just watch how they start, and what they react to/don't understand.
We had a similar experience recently -- http://blog.seeksift.com/2007/03/02/an-epiphany/ -- and it did wonders for our usability.
But don't lead them or demo anything; just watch how they start, and what they react to/don't understand.
We had a similar experience recently -- http://blog.seeksift.com/2007/03/02/an-epiphany/ -- and it did wonders for our usability.
Seeksift looks cool. I was a little frusterated though when I clicked on the blog and then couldn't find a way to click back to seeksift easily.
Thanks; let me know if you use it and what you think: good, bad, or ugly (actually, especially if it's either of the latter two categories, because that's how we improve).
Thanks, too, for bringing up the point about the blog; there are probably ways of customizing the header to point to SeekSift.com but I got a little frustrated with Wordpress after I found out you can't change their favicon.
Thanks, too, for bringing up the point about the blog; there are probably ways of customizing the header to point to SeekSift.com but I got a little frustrated with Wordpress after I found out you can't change their favicon.
Scrap the idea. If they can't relate to it who will?
No. I didn't say that they don't like it and there have been no noticeable bugs.
It was very well received by all of those who I heard from. The problem is that the whole "release as early as possible and get user feedback quickly" strategy has not been effective for me at all. My question is how I can get better feedback from users, not how I can suck less.
It was very well received by all of those who I heard from. The problem is that the whole "release as early as possible and get user feedback quickly" strategy has not been effective for me at all. My question is how I can get better feedback from users, not how I can suck less.
Post your Beta to Ycombinator news.
No shortage of strong opinions here.
I'm sure there'd be some really good responses, but most of us are probably about as far from average internet users as it gets. It really depends on what the product is though.
fix your bugs and apologize to your users.