How do you handle competing UX feedback?

In managing competing UX feedback, another critical dimension to consider is the type of feedback, whether it's qualitative or quantitative. Qualitative feedback, often narrative & descriptive, provides nuanced insights into user behaviors, feelings, motivations, & experiences. This type of feedback is instrumental in empathizing with users & understanding the 'why' behind their interactions. On the other hand, quantitative feedback revolves around numerical data & statistical analysis, providing an objective measure of user behavior, performance, & preferences. It offers an empirical foundation to gauge the effectiveness of your design & pinpoint areas requiring improvement. Balancing both types allows for a comprehensive understanding.

For me, the biggest process change which I had incorporated in my work is to document everything. Once the process > steps > complete journey of user design has been documented then the chances of getting a completely off response are very limited. Since all the different stages, the core stake holders were involved and communicated about the process > response and there is a good amount of documentation for any design solution. In spite of that, if we get then better to validate what had been delivered to the goal and to the user's feedback. Once we know that the design had been delivered as per the goal > earlier user studies outcome then the chances of limiting the finding is to understand where users felt the pain point.

It’s always a good practice to base design decisions on solid user research and data. Whenever possible, use quantitative and qualitative data to back up your design choices. This can be in the form of usability testing, user surveys, analytics, etc. Data-driven insights carry more weight and can help resolve conflicts. Also Data-Driven A/B Testing is a great way to validate your design If you encounter fundamental disagreements, consider running A/B tests to evaluate different design variations objectively. Let data determine which version performs better. Overall, when design decisions are based on data from rigorous research then you have a good rationale to handle competing UX feedback.

It's always good to know your audience intimately through years of working with them and understanding how they interact with your product on a daily basis. Some audiences/users are willing to learn a new way of interacting with software, some are not. There could be excellent ideas coming from everyone involved around innovative UI, but it needs to be intuitive for the specific users of your application and not cause them to take more time each day to learn and use the application.

Mes suggestions s'inspirent du Design Thiking. Voici comment je fais : → Observez → Réfléchissez → Créez des solutions → Testez et itérez Soyez curieux, allez voir ailleurs !

As the owner of a feature or product receiving UX feedback from any source, your first job is to try to understand what that user was really trying to say and then distil a depersonalised User Story from that. Ultimately, you must then decide whether the feedback is worth acting upon. You may then find that the feedback was not conflicting after all. If it still is, then decide action based on which of the User Stories adds more value/impact to your product. For example, a player comes into your game and leaves feedback: "Bonus levels frustrate me and should be removed from the game." With further investigation of the cause, you may find that they were actually saying: "As a player, I want more reactive controls on bonus levels".

As the customer feedbacks are critical for the business and for the organization, however, it's always necessary to evaluate it with a pinch of salt as not all the feedback are easy to incorporate, few design decision had been taken with a detailed study, understanding of user needs, business objectives, and goal, etc. Now with all that, as it's just customer feedback, the organization shouldn't do it without giving the right amount of consideration to the process being followed to arrive at the solution first. Evaluate, study, try, test, and then implement. do an A/B test, and derived solutions data. We should always check that in the process of satisfying one customer, we don't end up losing another set of customers.

Any feedback that's *volunteered* by your existing users is likely to be unstructured, and broad. It's vital to complement these sources of organic and vague feedback — CS tickets, social media, complaints — with deliberate user research sessions, scheduled to run against designs in flux, to deliver specific and structured feedback.

As a UX researcher or designer, we naturally want to collect all the feedback we can get - because that might make the product better! But, in reality, a team or a PM can only process and act on so much information. We need to remember to stay in scope while deciding which feedback to pass on, to make sure we deliver quality insights.

One thing that I have found useful when evaluating feedback is documentation. It is easy to get lost in qualitative narratives or miss design iterations without clear documentation. A simple way to document feedback is with an affinity diagram. By documenting the feedback and grouping it into themes or groups, UX designers are better able to evaluate feedback because of the increase in perspective, clarity, and organization.

Seeking feedback requires vulnerability, but it's vital to keep it aligned with design goals. In my experience, out-of-scope feedback can be also be valuable for future iterations through negotiation so you should always prioritize feedback to enhance your current design effectively. This way, you maintain trust with your users while you solve for the current problem.

As a successful team, one solution that I had opted for my work is to keep a 10% buffer in a release to try out feedbacks that we had received from customers / internal teams, etc. Now in this 10% buffer story, we can evaluate or plan to do a quick test of a new feature and identify if it requires an A/B test or just a quick change in the mock-ups or it's a code change. produce a report as a part of the release summary that what had we gain with this change. did the performance of the functionality had improved? Can a user get things he wanted with minimum clicks? There are many times, a focused team misses out on finding a better solution than customer feedback provides. so always beneficial to try out before major commit.

It's always advisable to have a backlog of stories for user/customer/stakeholder feedback with the appropriate titles. Once we have that ready then try out the details whether it requires a test or non-related feedback. Better to document each step and run it within the team meeting or stand-ups. The team should be aware of what kind of feedback we are getting for the work done. and also kind of fact-check whether something is really working or needs a change. Such a backlog dashboard can help in giving the true picture of the product. and the product owner can keep maintaining or tracking that. the timeline that I had defined for my team is 3 releases. any feedback we et should be addressed in less than 3 releases.

It's critical not to get suck in analysis paralysis. Contradicting feedback will always exist, and as a PM or UX designer it's your role to act on it fast: either analyse it further to clarify the insight or dismiss it, if you have the justification to do so.

It can be very hard to contradict feedback from per example a senior designer or PM, but it’s our role as UX Designers to advocate for the insights based on the actual users. It’s very effective to quote users or retell user testing stories as a way to put power behind your insights. That, and reminding the team that they are not their target audience, will help you get your point across.

Storytelling is always the best way to communicate about a problem and get it adopted. Telling user stories is always the best way to remain empathetic, to take a step back from our analyses, to reconsider the subject in a more global perspective, to gain perspective. User stories, with context obviously, remain the best way to align teams with user needs, and to put into perspective our hesitations which would justify an investigation (quali or a/b test for example).

Competing UX feedback is managed via (wait for it) research. Properly designed research can be used to determine and confirm what's best for an initiative, as well as helping to manage the politics and biases that can impact any given project (or individuals).

Whether dealing with conflicting feedback from play testers, peers, managers, or even directly from a community that uses your product, the most helpful process that you can practise in your day-to-day work is this: 1: Try to ensure you understand the real problems. 2: Anonymize the feedback. Remove any and all personal bias that could creep in. 3: Try to solve the issue, not the feedback. It is easy to fall into the trap of doing the minimum amount of work to put a halt to noise or conflict, but you won't be solving the problem by doing so. 4: Build bridges, not walls. Put the facts on the table and find the middle ground that resolves the problem(s) without just picking a side.

As a UX designer, it is more likely than not that you will have competing user feedback. When this comes up in my work, I strive to look for overarching patterns or common themes. One useful technique I have found for evaluating different feedback is to add all comments to something like a FigJam or Miro board. From there you can organise different comments into buckets and give each bucket a label. You can organise by topics such as "accessibility" or feedback types such as "Likes", "Concerns", "Questions" or "Confusion". Once you've organised your feedback, it's helpful to invite different stakeholders to review and vote on the buckets using an impact/effort matrix to help gain alignment and develop a clear focus as a team.

Sometimes, you may receive feedback from different sources that are not related to the aspect of your designs that you need feedback on. ?? In such cases, it's essential to prioritize feedback based on urgency. This can be done in collaboration with the product manager, engineers, and fellow designers. ?? Although it's essential to capture and take note of all feedback, it's best to focus on feedback that requires immediate attention instead of getting bogged down by less urgent feedback. ??

If a product is big enough and there are many users, it's advisable to have an internal engine to check all the feedback and address those. communicate with the right team along with the release summary. At times, it helps to gain customer trust when they know that the feedback they had given had been taken seriously by the company and had been addressing. Such confident customer will not change their preference for the company easily.