Let's talk about feedback!

I’ve come to realize that my work has greatly benefited from constructive feedback over the years and that teamwork is undoubtedly the backbone of any successful product.

Every stakeholder has an important part to play. Their insights are valuable because they give us a broader perspective of the user experience and needs. That’s why good feedback pushes the team to think outside the box and come up with better solutions.

But what exactly is good feedback? And what kind of feedback can have the opposite effect?

In my experience as a UX Writer, I think there are 5 common mistakes that should be avoided when giving your team feedback. So, let’s dive right in.

1 - "I don’t like it!"

They may not be very common these days, but personal opinions that offer no suggestions as a way forward can still pop up now and again.

Now, that doesn’t mean that they should be dismissed. However, the problem arises when this subjectivity constrains us, instead of opening up a multitude of possibilities.

That’s why, the most useful feedback is that which, from a personal point of view, makes clear: 1) the benefits of a “new approach” for the product and 2) the objective guidelines to keep in mind when reworking the proposal itself.

By always trying to go one step further using well-reasoned arguments we can become more agile.

For example, if you don’t think onboarding messages are hitting the mark, explain why and point out that it is a good opportunity to activate the brand’s personality and boost user engagement.

Likewise, if you think an error message is unclear, you should highlight whether or not the copy lacks clarity in terms of what happened, the issue, and most importantly, the solution.

2 - "They do it like this, so why don't we?"

In our day-to-day work, competitive analysis and inspiration go hand in hand. We often realize that it’s not necessary to invest time and resources in creating something that already works.

We should take inspiration from brands and products that are already performing well, but we must also recognize that each brand is unique and that every experience has its particularities.

For example, when we talk about patterns of interaction, it’s always best to focus on those which are already familiar to our users.

However, the fact remains that, depending on the context, certain formulas may not work, and responses may differ based on product limitations, company objectives or even the cultural background of the user group.

On a verbal level, for example, using a more direct tone to convey information may work in certain markets, but may be interpreted as offensive in others. Similarly, using a more humorous tone might seem like a good idea, but may not be in keeping with our brand personality.

To avoid providing feedback without this cross-sectional perspective, it’s worth asking ourselves questions like:

• Who are we, who are they?
• Could we do something similar?
• Does it make sense for us to do something similar?
• Do we have the tools and resources (human, time, financial, etc.) to do something similar?
• Does it fulfill our needs?
• Is it in keeping with what we want to communicate as a brand?

This exercise should also be done by those who receive the feedback. It’s interesting to try to figure out if what the majority of companies are doing is the way to go or if taking an alternative direction is worth the risk.

3 - "I didn't mention this before, but..."

The timing of feedback is also key for the team to get the most out of it.

That said, feedback can and should be considered even after a feature goes live. This ongoing review and quality control forms an essential part of the product lifecycle and is the main focus of the QA team.

But some feedback should be mentioned at specific points in the workflow. Therefore, it’s important to set a clear deadline for this on the project timeline.

For example, if we know that feedback can affect an A/B test, then make sure it’s delivered at the earliest possible date. By doing so, we won’t compromise the result, minimizing errors, efforts and frustrations for the team.

4 - Reply to all

The channels we use to communicate feedback are as important as its content. Using the right ones ensures that only the people involved will be able to access it, on time, and without causing unnecessary fuss.

We should also consider whether the feedback should be made public or kept private, sent to all project stakeholders or sent to one person in particular.

If your feedback is related to a possible bug following the release of a new feature, for example, why not send it to the QA team? They will know better than anyone how to categorize it and will forward it to the relevant department.

It can also be interesting to ask yourself the question, “Should I post this feedback here?” to minimize endless threads and protect the stakeholders involved.

Other questions we should ask ourselves before providing feedback include:

• Can I still provide feedback via this channel?
• Is it really necessary for all these stakeholders to be made aware of this feedback?
• Should I communicate this feedback on an individual basis?

5 - "I would do it like this!"

And last but not least, the “I would do it like this” type of feedback. The problem here centers around showing how you would do something without explaining why. This leaves no room for others to learn from your fresh insights.

When you rehash the work of others, without giving them tools and instructions to make improvements, then no learning takes place, which is essential for both individual and team growth. Therefore, it’s always more beneficial to discuss the proposal, even if it takes longer.

For example, if you think the message could be better organized into title, subtitle and disclaimer, rate each section and distribute them according to their degree of relevance on the screen. This is a visual and logical way of explaining an information hierarchy scheme.

However, this type of feedback doesn’t take into account the fact that, if you’ve written or designed something in a certain way, there’s probably some sort of rationale behind it. You may have considered certain elements that perhaps the other person has neglected. For this reason, it’s important to thoroughly support a proposal with arguments before presenting it.

In short, receiving feedback means we make fewer mistakes because we are more aware of the needs of every part of our complex system. This means we can anticipate potential issues, learn, and grow as a team.

This is precisely why it’s so important to establish good feedback practices. Only in this way can we become stronger and more agile. This may not directly impact business metrics, but it certainly has the potential to improve the way your team works.

…

This post was written with the help of Cabify’s Content team. <3