We should happily take anyone’s feedback any way they want to give it. After that, it’s our job to continue the conversation and make sure we have the right information, and enough of it, to make a good choice on what to change in our products.
First things first: there is no right way for someone to give feedback. But as a professional designer or developer it can be challenging to receive feedback from people who may not have the context or vocabulary to express it perfectly.
And our definition of perfect will often betray our personal and professional biases. But we should happily take anyone’s feedback any way they want to give it. After that, it’s our job to continue the conversation and make sure we have the right information, and enough of it, to make a good choice on what to change in our products.
Instead of trying to build an elaborate process for synthesizing feedback, we should get a better handle on what we’re trying to accomplish when we ask for feedback. Then practice, practice, practice.
Practice with customers. Practice with colleagues. Significant others. Mirrors. Stuffed animals. Whatever. Just practice.
So what are we trying to accomplish?
We’re trying to separate feedback that’s contextually helpful from the feedback that we can act on in a predictable and reliable way.
There are four types of information that help software designers and developers understand the world around a customer, but don’t help us decide what to build.
When considering whether to build a solution, it can be difficult to understand how it will impact other dimensions of the product. Take this rubberized handle. It might provide a better shaving experience, but it will also increase the cost of the razor. If this increase in cost is greater than the value the rubberized handle brings, you’ve lost the customer.
Until you can confidently understand what value the solution is providing, you can’t compare it to the costs and make an informed choice.
Some customers might tell you they want a wider, lighter, or sharper blade. But before you go off and build a wider blade, understand you may be attempting to solve a problem that can be solved in a better way. For example, a customer might want a wider blade to reduce the number of passes over the skin and prevent irritation. In this scenario, a good solution might not be a wider blade at all. A different cream or lotion might address this more effectively.
Until you can confidently understand the intent behind the specification request, you can’t possibly start to build a good solution.
Customer needs are a notoriously imprecise gauge of what you should be building. One need could actually result in a multitude of different solutions. Let’s say a customer wanted a razor that was more dependable – it could mean lasting longer, resisting bending, withstanding moisture, etc. If your perception of dependability relates to withstanding moisture while your customer’s perception of dependability relates to resisting bending, you are going to head off in the wrong direction.
Until you understand the precise dimensions of your customer’s need, you can’t tell if you’re making meaningful improvements.
Benefits, like needs, are too imprecise to act upon. A benefit can also be delivered with a multitude of different solutions. Does “easy to use” relate to the time it takes to finish shaving, the amount of time it takes to put the razor together, or reducing errors while shaving? What is your perception of the benefit? What is your customer’s perception of the benefit? If they’re not the same, progress will be made along the wrong dimensions.
Until you understand the specific dimensions of the benefit for the customer, you can’t tell if you’re making meaningful improvements.
There are three types of feedback almost instantly valuable to your product. They might take more work to reveal, but it’s worth it in the long run.
A job is what someone is trying to carry out. It sounds easy, but can be surprisingly tricky to properly identify. There is almost always a combination of three jobs when people are using a product:
Which job is really driving behavior?
Think about a father using a traditional razor when his son is learning to shave. There’s a personal and social driver to using a traditional razor that an electric shaver just can’t beat. In this scenario, if the father were asked if he wanted a faster-charging electric shaver (benefit), of course he would say yes. Nobody would turn down a benefit like that. But it wouldn’t help him teach his son how to shave. Only the traditional razor solves that job.
It’s not uncommon for designers to identify a functional job, believe they have the full story, and act on it – only to end up making something that nobody uses. Keep probing, even when the story seems to be complete.
Great products understand how customers measure value for themselves – how they want to get the job done, and what it means to get the job done successfully.
Whatever value is being measured needs to have a direction (e.g. increase, minimize, etc) and a unit of measurement (time, cost, etc). If you can’t find a specific measurement and a way to use it to indicate progress, it should be a signal that you’re talking about a contextual problem, not an actionable problem.
Here are a few examples:
Remember, this isn’t a framework to push people through. Rather it’s a way to probe how someone is measuring their perception of success.
If you look hard enough, there are always constraints preventing people from getting their job done the way they want to. For example, when someone runs out of shaving cream, they can’t use their traditional razor. Making the razor sharper wouldn’t make a difference. Yet when interviewing customers, constraints are rarely mentioned.
A few simple questions can go a long way to uncovering constraints:
Get into the habit of sprinkling these questions into a conversation to probe for constraints. And be prepared to repeatedly slap yourself on the forehead.
If you’re just getting started it’ll be clumsy and awkward. That’s okay. That’s how it is for everyone. If you’re a seasoned veteran it’ll be clumsy and awkward. That’s okay. That’s how it is for everyone.
Just be really clear about what you want to accomplish. Then practice.
Originally published as Product feedback you can act on on Inside Intercom. Intercom commissioned a wonderful illustration by Shawna X for the article. Go check it out!
In short, I’d like to get specific about the fundamental skills involved in product design, a few brief examples of the type of work that can be done for each skill, and how they’re mapped to common product design roles.
There’s such a thing as getting down to the root problem too quickly, particularly when it comes to product design. The value in figuring out the “Why?” behind things isn’t quite as much about the destination as it is about the journey.