LearnUltimate Guide to User Feedback Part 3: Turning User Feedback into Action

John Turner is CEO and Founder of UsersThink, which provides user feedback on demand for landing pages. He’s passionate about usability, UX, feedback, helping people, dancing, and high fives. Check out his free email course on the 7 biggest landing page conversion killers (and how to fix ’em).

 

This is the third part of a three-part series on user feedback. Be sure to check out Part 1 “Why User Feedback Matters”, and Part 2 “10 Ways to Get User Feedback”, if you haven’t already.

 

In the first and second posts in this series, I covered why getting user feedback was so important for your project and some of the most common ways to collect feedback. In this post, I’ll cover how to take all the feedback you’ve gathered and turn it into actionable change.

For some odd reason, there’s always a fair amount of talk around how to get feedback (like the ideas above), but almost no talk around what to do once you’ve received it.

Chances are, if you’re getting any feedback at all, you’ll receive conflicting responses, contradictory statements, or comments that just feel off to you. But there’s some nuance here, as well as a lot of widespread misconceptions about how to deal with feedback and put it into action.

I wrote a short post on the UsersThink blog around this, which includes the free, one-page guide included with all UsersThink orders, but I’d like to add a few more ideas. Here’s how you start with feedback and turn it into changes for your project:

Gather all feedback into one place

Even if you’re using an approach that doesn’t deliver all feedback at once, you still want to gather all feedback into one place. It will make looking back over old ideas and suggestions much easier, and will help with the next step.

Go over all feedback in one sitting, and review it multiple times

You want to have all of these different ideas hit your brain at once. It’s okay to review a little at a time before all feedback is gathered, but you still want to go through this step. It’s going to be information overload, but doing this also helps remove some of the initial emotional difficulty from this process. Once you get past some of the tough feelings associated with this process, it’ll be easier to put this all into action.

Step away from the feedback (if you can)

Look, no matter how long you’ve done this, no matter how many times you’ve heard this stuff, it’s still hard. It’s always hard to not take this feedback personally. But you need to hear it, and giving yourself a little space from the feedback, after going over it a few times, will help you return with a clear head. Go do other work for a few minutes, take a break, practice cartwheels, really anything, just a short bit of time away will help a ton.

Return to the feedback and make notes of what people did and didn’t like

Separate in your own notes the stuff that people found good (or useful) and bad (or difficult/frustrating). Don’t filter, remove, or rank this stuff yet. Just list it all out. Put all the good in one section or file, and all the bad in another, until you’ve covered all the feedback you’ve received.

The goal is to learn about how people react to your project, not for them to tell you how to fix the problems

This is one of the most common misconceptions about getting feedback: that the users will tell you exactly how to fix the problems with your project. That’s not really what the point is. The point isn’t to release all control and authority over your project or even to have others tell you what to do. The point is to gain outside perspective, and learn what seems to bug folks, and what they like, about your project. Only you can truly know what might eventually work for your project, but that outside perspective will help you realize what the problems worth solving are.

Sometimes someone will have a great idea for a new feature or a change to make, and that’s great, but learning what the real problems are is more important, as once you know which problems exist and are causing the most grief, it’ll make your job of solving them that much easier.

Order all of the “bad” points from most critical to least

There are a lot of detailed methodologies around how to do this, but I think the best approach is the simplest, especially when you’re a small team, or a team of one: order them based on your own opinion and judgement. If you’re on the fence on any of the issues, go ahead and put them aside, to see if they come up later.

“Fix” the problems by making the smallest changes possible

Another big hangup over feedback is finding a few issues, then declaring “the only option is to start from scratch!” Chances are that won’t fix the real problems so much as creating a lot of work that will only result in trading out old problems for new ones. Instead of that, start at the top of your problem list, and do what you think is the least amount of work to fix that problem, and go down the list. This “do less” approach works surprisingly well, and helps you move and improve quickly.

The only time this approach won’t work is when there are more fundamental issues with your project, like you’re offering something that doesn’t help anyone or fix any problem. But at that point it’s less about project feedback and more about pivoting your core idea.

Get new feedback on your new changes (from new people)

Ideally you can make changes quickly to your project, or at least build a mockup of your new fixes fast. Try getting fresh feedback on your new project version. In general, it’s better to get feedback on your new changes from people who haven’t seen the old version or given you feedback already (UsersThink is built around this, so feedback is always from folks who haven’t seen your landing page before). You want feedback on how the new project version works on its own, not how it compares to another version you had before.

You’ll quickly get a sense not only of if things you tried to fix are taken care of, but also if problems you skipped over still exist, or if new issues cropped up. More likely than not, new, smaller issues will emerge, ones that couldn’t be seen before because the larger issues masked them, which is why ongoing feedback is so helpful.

Repeat this cycle as you build

Make sure you’re getting feedback early and often, as already suggested, no matter the feedback collection method you choose. Set it around certain key points in your project building process, at certain milestones, so you’ll save time and effort down the line.

Now go build something awesome!

Armed with this guide on getting and using feedback, you can feel confident that you’ll be able to develop your next project or idea faster and better than ever!

And if you found this helpful, you can find more helpful tips from UsersThink with our free email course: 7 Biggest Landing Page Conversion Killers (and how to fix ’em).

This is the third part of a three part series on user feedback. Check out part 1 and part 2.

Leave a Reply

Learning to code can be fun!

Get started today with a free trial and discover why thousands of students are choosing Treehouse to learn about web development, design, and business.

Learn more