Como você abordaria uma situação em que o feedback do usuário contradiz a direção inicial do projeto?

Contradictory feedback are very common in scenarios where the chain of user is not aligned or well informed about the project objectives. In such scenarios you as a Solution architect should always bring the project's sponsor in the center. Project sponsor will decide that whether the feedback is worth considering as a design change or should be consider as a part of new future project

We need to listen and understand, not reply the user opinions. The feedback is an essential part of the design iteration, and we need it to evolve to a better product. More important than not consider an opinion or feedback, is evaluate to not consider everything, everytime. Doing this, you aren't able to define and grow your design.

When user feedback contradicts the project's initial design direction, start by evaluating the relevance and impact of the feedback. Prioritize changes that align with key user needs and project goals. Use prototyping and testing to iterate the design, ensuring the changes enhance the overall experience. Communicate transparently with stakeholders, setting clear expectations. After implementing changes, validate them through thorough testing and gather ongoing feedback. Reflect on the process to learn and improve future projects, ensuring a balanced approach that respects both user input and the original vision.

I observed this scenario in most of greenfield implementation where there is no reference of system but the requirements are outlined in a document. The initial design always contradict if the interpretation between the stakeholders are different. Product SME present his interpretation from product functionality perspective. Business user interprets it from day to day usage perspective. Hence a workshope to bridge the interpretation would help to understand and provide initial design and get alignment of Business in initial sprints itself to avoid conflicts at later stage. Also ensure the alignment is on mail so that you can always fall back onto the mail during the conflict resolution phase.

Every project has different perspectives, the way you want it to be, the way it is, the way users perceive it and the way they want it to be. If there is a divergence between the users and the vision for the project, try to determine why, is this because the users really like it and are full of ideas, or because you haven't found the ideal user community? Are you trying to build a community or find one that is out there, these will require different approaches to the evolution of the project. I believe you should have a vision that guides you but even the vision must be tested. Maybe it is just not the right time and the vision might just need to adapt as well.

The feedback should be looked in the context of project objective without any bias. Even if the feedback calls massive efforts to get implemented but has an alignment with project objective ( i.e non-inclusion of the said functionality in project will cause massive dent on projects objectives) must be considered. Even if it calls delay in project rollouts, confession in front of project sponsors. Its always wise to address the feedback rather than addressing it as a 'Ticket' post rollout.

Usually when situations like that occurs during a project development, it means you need to listen, study and understand more your client, its market sometimes and even the place where the client is getting ‘inspirations’ for this hard feedback (believe on me, there is a comparison over what you’re delivering with some other solution). These simple steps can make you and your development team, at the first moment, closest to the client mind in terms of project expectation, bringing more suitable solutions, increasing your team delivery performance and my favorite one: shining eyes by client satisfaction.

Every solution architect encounters situations where initial designs has flows and with subsequent feedback the project design was improved. I look at it as a missed opportunity as the people who are providing you feedback were very well there in system when you were designing the solution. We often miss such inclusiveness in our team. As per my experience bigger challenges are coming when we miss design aspects related to functional domain. We need to make sure that we have heard all of them well who knows the business. Usually design defects in technological stack can easily be avoided by following some set of rules and know how's. You must have future transformation plan of your tech stack as the usage scale cross some landmark.