How to respond to feedback we disagree with?

You are a designer of interfaces, applications, user experiences. In your work, you dedicate many hours to analyzing, gathering information, designing solutions, and checking them. Whether you’re creating a new product, improvement, or a small feature, you usually have to take into account the feedback of others.

Typically, feedback comes from stakeholders—individuals not actively involved in conceptual design. They may lack the full context of design decisions, and they don’t necessarily need it. The key to preparing feedback materials is providing necessary information that helps stakeholders identify the strengths and weaknesses of the proposed solution.

The article focuses on dealing with feedback that you disagree with. However, it’s worth mentioning situations where feedback may contain an alternative proposal that you haven’t previously considered but has the potential to be the final implemented solution.

What to do in such a situation? Take a moment to consider the proposal. Analyze all consequences, check for any gaps. If the proposal turns out to be better than the one suggested, you have a ready solution for implementation.

In any other situation where you disagree with feedback, it is crucial to define why you disagree and how to respond.

Why might we disagree with feedback?

The proposal has been rejected before.

During project implementation, you iterate on your ideas. Often, you reject something during the conceptual and requirements gathering stage. Stakeholders, unaware of this, may suggest a solution that was previously rejected.

The proposal is more expensive.

Stakeholders may propose a solution rejected by you due to costs and implementation difficulty. They may lack knowledge that you have supplemented with the IT department. You know that the cost of the proposal is disproportionate to its quality and the problems it aims to solve.

The proposal ignores patterns.

Stakeholders focused on their business and product may propose a solution that ignores patterns, potentially making it difficult for users to use basic functions. Implementing such a proposal increases maintenance and communication costs, introducing unnecessary discussions about something that was previously agreed upon.

The proposal requires introducing exceptions.

Sometimes stakeholders’ proposals require introducing special exceptions in the system, complicating logic and increasing maintenance costs. Such a proposal may be costly not only in terms of implementation but also due to later changes that may require introducing additional exceptions.

How to respond to feedback with which you disagree?

At Bethink, we started noticing that these situations often occur and require proper handling. We observed the feedback process and responses, noting what worked well and what didn’t bring the desired results.

Based on these observations, we created a repeatable pattern for responding to feedback with which we disagree. We focused on identifying which pieces of information are essential in such responses and then arranged them in the right order. This way, by following the pattern, we ensure that none of the crucial information is omitted, and the sequence makes the message complete and logical.

Remember this pattern every time you respond to feedback you disagree with, whether in meetings or comments.

Build a shared understanding of the problem.

Make sure stakeholders have the full context. If their proposal stems from a lack of available information, your task is to provide it. Decision-making and proposing solutions on both sides must be based on the same context and knowledge sources.

Show the consequences of the proposal.

Point out other areas affected by the solution (both yours and the alternative) and how it may impact other parts of the system. Don’t forget about cause-and-effect relationships between elements affected by the proposal—what affects what and how. You can use a real example to illustrate inconsistencies in the alternative solution. Act on the principle of contrast—if your proposal does something better, state what and why.

Explain where the costs come from.

Apply this principle if the alternative proposal is more expensive than the one you’re suggesting. Stakeholders may not know all technological limitations, and they don’t have to. Just indicate areas that will require more work and explain why. Highlight implementation and ongoing maintenance costs. Subsequent iterations may be costly if the implemented logic exception requires introducing another exception. Try to describe this in simple language. Don’t use this argument without supporting facts. Remember that you can use this principle to emphasize the low cost of your proposal.

Reiterate the benefits of your proposal.

If stakeholders’ alternative proposal introduces negative consequences, emphasize why your proposal doesn’t. If your proposal introduces other, more acceptable and manageable consequences, remind them. Draw stakeholders’ attention to the fact that your concept doesn’t introduce exceptions; it only extends existing conditions, making them more universal.

Preparing proposals for feedback is time-consuming and requires attention to detail. Stakeholders may have different perspectives, experiences, and opinions, so they may propose alternative solutions.

I hope you now know how to respond to feedback you disagree with. Use the above pattern to make the feedback process smoother and more effective!

Good luck!