The feedback cycle — Gathering actionable insight and defending your design decisions

At certain points in the product development process, it is important to receive feedback to validate your build, to know if you’re aligning with business and user needs. This is so as to push a viable, delightful and scalable product into the market.

That being said, we do not always get the feedback that we need to properly get to the next phase, this could be as a result of improper dissemination, poor understanding or both.

How do you “feedback” the right way?

The best kind- actionable feedback

Giving and receiving good feedback is a skill that can be learned. While looking at any deliverable that requires feedback, it’s important to ask yourself these questions.

What “exactly” is wrong? - the tricky three

It’s easy to say “I don’t like how this looks” and expect to be understood, but thats not the case. Why exactly don’t you like it ?

Try this trick, draw out 3 specific issues, if you don’t have up to that its fine, but you find you’ve given feedback that can be directly acted upon, this also leaves room for discourse, where the person can defend their decisions leading to your understanding and even better solutions.

What could be better?

You don’t dislike the result, but you feel it would be better, it’s important to follow the rules of 3 here again.

Bring out 3 resources to show what you mean. Having a visual often fast tracks the process and leads to quicker deliverables.

How do i say it the right way?

The general idea is that everyone working on a project wants it to be a success, it is important to give your feedback with kindness, keeping in mind that the person is putting in their best work.

Before i give any feedback, I always start with “well done”, that’s because delivering said task itself was no easy feat.

Its not always a bed of roses

Be sure you put your feet in the right place, then stand firm.

— Abraham Lincoln

Sometimes, all i get is “I don’t like this” even when I try to draw out the specific problem. In situations like this, I let the stakeholder know plainly that the feedback is not actionable, and may extend the timeline if I come back with deliverables that don’t align. I try to open discourse by asking how they would go about solving the problem, so that i can extract some sort of data into the kind of deliverable they would like.

However, there are times where your decisions were the best bet, and if objectively this is true, then you stick by it and defend your decisions, as its for the prosperity of the product.

Having issues giving or receiving feedback? Try this and let me know how it goes. Cheers