Criticism should come with claims

When developing products I receive a lot of feedback. It’s a good thing but the form of the feedback is often lacking. Then you have to sort of divine the actual meaning behind it.

It’s not a big deal when this comes from users. It’s unfair to expect users of your application to give extremely clear, insightful criticism. Feedback from users is more about knowing there’s a problem and ideally where it is. Anything beyond that is a bonus.

Don’t give descriptions.

People who work on products for a living struggle to give clear feedback just like users. At the worst end you’ll get vague descriptions and feelings that are barely even developed.

“Hey, this page looks a little weird.”

A little more useful, sometimes you’ll get specific problem statements that are still too vague to be actionable.

“We aren’t getting clicks on this page.”

“These buttons on the home page look off.”

The problem here is that this leaves the person receiving the criticism to identify the root cause and what the shape of a solution should look like. Maybe that’s their job but quite often I’ve seen low quality criticism come from the core stakeholders and decision-makers. Then you end up playing an expensive game of product Pictionary where the guesser knows the answer and won’t tell you. So you keep redrawing until they are satisfied and say, “yes that.”

Make claims.

When delivering criticism internally, it should come with a claim. You need to state a problem and give a reason for that problem. Even if it’s only a hypothesis.

“People aren’t clicking anything on this page because the copy is unclear and the button blends in.”

That is testable and actionable. The claim may end up being wrong after testing but at least we’re now on a path to resolving it.

Forcing the “because” to be a part of the criticism is an easy heuristic for improving the quality of that criticism. Other improvements could be setting expectations and giving context. These are things I often need to fish for after hearing vague descriptive commentary related to a problem.

“We expected people to see this and sign up. Research suggests 5-10% of users should take action here but only 1% are. I think it’s because the copy is unclear and the button blends in. But maybe we’re driving the wrong people to the site or this isn’t compelling enough.”

Now this can become a product discussion with many actionable outcomes.