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 first part of a three-part series on user feedback.
Feedback: The best way to improve a project once you know how to build it
Treehouse does an awesome job of teaching you the skills you need to build websites and apps, and there’s no question that the ability to bring your ideas to life is a big deal. So now all you have to do, once you have those skills, is code a bunch and you’ll end up with a perfect project (with a perfect name), right? Well, it’s not that simple.
Being able to turn your new idea into reality isn’t the only thing you’ll need to do. You’ll also need to master the art and skill of learning, via feedback, what works and doesn’t work for your project. While I built my startup, UsersThink, to make it easier for makers, builders, hackers, and students to get feedback early and often on what they’re building, it’s certainly not the only way to get feedback.
I’ve seen plenty of posts advocate for “get feedback and then improve,” but I’ve seen few that go over the various approaches to getting high-quality feedback, or how to take that feedback and turn it into positive changes for your project.
So that’s what I aim to do in this post! But first…
Why get feedback?
Here are some common reasons why feedback can help you.
It’ll help you regain perspective on your project
When you first start working on a cool new project or idea, you’ll start off having a pretty objective view of the problem you’re solving. But that objectivity is quickly lost, sometimes shockingly fast. Worse yet, it’s easy to think you’re maintaining that objectivity when you aren’t.
Getting feedback from outside individuals will help you regain that lost perspective, and it’s a big reason why having feedback at multiple stages of a project helps so much. Having objectivity on demand, in the form of feedback, will help you build a better project faster.
You can’t know everything, even when you know more about your project than anyone else
When you really start digging into something new that you’re building, you’re probably mapping out, or at least thinking about a million little issues, details, and ways your project can be changed. When you’re that involved, you probably know more about it than anyone else.
But it’s impossible to know everything. There are going to be things you’ll miss or didn’t anticipate, or things you assume work, that don’t. That’s okay and part of the process, but you want to fill in those gaps as quickly as possible. Getting feedback will help you fill in those gaps of knowledge.
I can’t tell you how many times I was working on something (including UsersThink), thought I had everything perfect, got feedback, and then realized “wait, that’s what they think that is for?” or “wait, that’s what they think that does?” Once I had the feedback, it’s wasn’t hard to find problems and fix them, but it wasn’t something I could have discovered otherwise.
It helps prevent small problems from growing into big problems
I’ve seen a few folks who get feedback very late in the process of building their project, discover real and pressing problems, but because it’s so late in the process, they throw up their hands, proclaim “it’s too late!”, and decide to do nothing about the issues they just discovered.
While it’s never too late to fix something, it’s often easier to fix things earlier rather than later. Problems that might be small and easy to fix early on can grow in size as you work on your project, just by virtue of your project growing.
Worse yet, because you’ve sunk so much time into what you later discover to be an issue, it can be hard to change from a psychological position, as there’s often a certain level of “I can’t change that, I’ve spent so much time/effort/energy/resources on it already, so it must be good!”
Getting feedback at every stage of a project can help you prevent small issues from becoming big.
It helps increase your awareness of possible issues (even if you don’t make changes right away)
At the end of the day it’s your project and you’re the one who will ultimately decide what stays and what will be changed. But it’s always better to be aware of things that might cause problems, even if you decide to not make any changes right away.
If you’re getting ongoing feedback, and you discover a potential issue, but you don’t want to fix it quite yet, you’ll have multiple chances to learn more about it and make alterations. When this happens, just make a note of the issue, put it aside, and make the other changes to your project. On a follow-up round of feedback, if it comes up again, you’ll have a clearer head about it, and be able to tackle it more easily.
It’s always much, much better to be aware of those issues than to discover them later on.
You’ll learn about problems you had no idea existed
There’s always a certain level of shock when you get that first round of feedback on a project. Even when you’ve been through the process before. But it’s especially tough if it’s your first time. And yet, this is probably the best part about getting feedback, despite the shock: learning about an issue you had no idea existed.
In most cases, once you learn about these hidden problems, it’s often not hard to fix, but it’s impossible to fix if you don’t know they existed.
There’s a wonderful testimonial for UsersThink that really drives home this point:
Ran another round of website testing with @usersthinkapp. Really good, actionable feedback. Feels like we’ve been flying blind without it.
— Adam Steinberg (@adams472) February 12, 2015
While it’s written specifically about UsersThink, I think it’s part of a broader truth: without feedback, you’re flying blind.
But you don’t have to get feedback if you don’t want to (as long as you know the downsides)
If I haven’t made it clear already, I’m very much in favor of getting feedback. But there are cases when you don’t need to get feedback. Here are the two main circumstances:
Your focus is more on learning about how to build, not on what is built
This fits into the context of learning with a site like Treehouse, where you’re following along with an example project, or just trying to replicate an example given in a step-by-step lesson. It’s not really about whatever site, app or functionality you’re building in the moment, so much as it’s about learning why certain actions produce certain results. You’re more focused on the mechanics and skills to build a project, and less on how to improve a project.
You’re just building for yourself, and just for the fun of it
Sometimes it’s just fun to prototype a new idea, make a quick tool for your own use, or automate a small part of your day. These types of small, personal projects can turn into something much bigger (think Apple and Facebook), but if you’re not worried about building for others, it can be perfectly fine to not solicit feedback.
The key is to know when you’re building for yourself and when you’re building for others
When you’re building for yourself, there’s still no question that you could learn from feedback, but that doesn’t have to be a part of the process. Since learning skills and building for your own enjoyment are reward enough, you don’t have to go beyond that under those two circumstances above if you don’t want to. It’s totally cool to say “yeah, don’t care what anyone else thinks”.
But that stance is a problem when you expand beyond an audience of just you. At that point, it becomes a good idea to follow the steps and approaches I’m going to outline below. This can be a transition that happens naturally, totally unplanned.
That is what happened with me when I originally built UsersThink. It was originally built as a tool for my own use in website consulting, as a way to more effectively get user feedback on demand for landing pages and websites. Even though I was improving the product as I went, it only had a user base of one (me).
But as I made progress, it dawned on me that this tool could be really helpful for others. That’s when I started getting feedback on the tool itself, as well as the process I was using for it, early landing pages to promote it, and pretty much everything related to it.
When it was just for me that stuff didn’t really matter, but once it went beyond me, that’s when the feedback mattered.
When to get feedback
Here’s one of the most common (and unfortunate) ways most people go about getting feedback:
“Okay, the project is complete! I guess we should get some feedback now.”
Then they get feedback, learn that there are a few things that are problematic or could use some improvements, but they feel it’s too late to fix anything, so nothing gets changed. Not the best way to do it.
If you want to make sure your project improves quickly, and the end result is the best it can be, build feedback into each step of building your project, even if you’re getting feedback in small amounts.
You’re looking not only to get into the habit of getting feedback (to preempt the “it’s too late!” feeling), but also getting used to receiving feedback, because the “it’s too late!” feeling is often triggered by how overwhelming that late feedback can seem. You basically want to handle feedback in the opposite way of this Onion article (warning: some swearing).
Building a cycle of “work on your project, get feedback, alter your project based on what you’ve learned, and repeat” will help you hedge against all the things that can get in the way of making what you’re working on awesome.
In the next post, I’ll talk about the different ways to get feedback, before covering how to turn that feedback into action in the third post.