Breaking bad news: how to present negative UX research findings
Taking a diplomatic approach to presenting negative findings.
You and your team have completed a solid body of user research, and now the time has come for you to present your findings back to the project team and senior stakeholders. Unfortunately, the verdict from the target audience is unanimous; they loathe this product/service. This concept doesn’t work for them, in fact, it doesn’t work for anybody, it’s broken, busted, a dud. Evidence from the research demonstrates a hideous litany of P1 fails, and details how the prototype generated an enormous amount of user frustration and dissatisfaction. The key story that your user report will have to tell is that if this project continues along its present path it could lead to serious reputational damage for the organization. And it looks like the enormous investment in terms of time money, resources and money that the stakeholders have made in the project may have been wasted.
This is certainly a juicy story to tell, and novice UX research practitioners often make the mistake, when presenting their findings, of prioritising the bad news. They relish the chance of pointing out all the usability 101 gaffes, the interaction design howlers, the schoolboy errors, that demonstrate their own cleverness and the design concept’s blindingly obvious flaws.
The lure of the ‘big reveal’ and the temptation to throw in some entertaining footage of users failing hilariously, can be every strong. It can also be very wrong.
This can be one of the reasons why novice UXers often struggle in some particular domains, especially those with lower levels of UX maturity. UXers who demonstrate little empathy with teams who have to work within particular constraints and in very challenging environments, such as enterprise software, or in government, can be seen to offer little value. In twenty-plus years as a UX practitioner, I’ve often heard bitter criticism of our discipline from under-pressure development teams: ‘they swan in, criticize everything, and don’t give a damn about how we’ve struggled to even get this far.’
Teams may see a focus on the bad news, on what’s broken, as a direct criticism of their work. They may become demoralized, and stakeholders indignant and unwilling to listen if the message is entirely negative. The result may be a drive to ‘kill the messenger’ or to bury the findings, rather than to take them fully on board.
Remember, be conscious of your audience, your format, and your language. Different stakeholders and team cultures require different reporting styles, it’s up to you to curate the information into a report that delivers the insights you’ve uncovered.
Maze.co, How to write and present effective UX research reports
A key factor in any presentation, but most especially in presenting research findings, is to know your audience, and this is particularly important when the findings can be seen to be negative. Are you presenting to senior executives of the ‘C-level’ suite, or to the development team? The approaches for these disparate groups should be very different, focusing on the specific areas that will be most important to each group. For both however, the emphasis should be on presenting a positive message. This is not to say that the bad news should be hidden or sugar-coated; far from it, as it’s vitally important to be seen to be honest and as objective as possible. Critical to this approach is the need to balance negative findings with recommendations for an enhanced experience: ideally, every pain point should be matched with details on how to address it.
It’s not enough to identify what is broken in a service; it is essential to provide recommendations on how it can be fixed.
Each example of a bad user experience should be seen as an opportunity; an opportunity to address that problem and to provide a much better experience for the user.
User research reports go beyond presenting findings; they offer actionable recommendations for the next steps. By distilling insights into clear, practical suggestions, these reports empower the product team to implement improvements. This ensures that the team doesn’t just identify issues but also knows how to address them.
Blitzllama, UX research report: Write & present your UX research findings
When presenting research findings it is always a good idea to kick off with some good news. There is usually something about even the poorest services or applications that, in the view of the research participants, seems to work well. It may be that users are simply happy to have been asked to be involved in research, happy for once to have their views heard and to have a direct input into the design process of a service. This is certainly a notable finding in itself. Then there could be aspects of the product that users say they would like to keep, or expand upon. It is important to identify these features that could be valuable in a future iteration and make sure you’re not throwing out the baby with the bathwater.
When the time comes to deal with the really gritty issues, the more alarming pain points, it is essential to be properly prepared. You’ll need tact and diplomacy to ensure that development teams don’t think that they are being singled out for blame. You’ll also need substantial primary evidence, enough to assuage any doubts stakeholders may have and to make a very clear case. Often, it is a good idea to let your research participants tell the story through direct quotes or recording snippets. This can have a greater impact and can help convince your audience that change is necessary. Be careful to ensure that all quotes are properly attributed and easily traceable to their source interviews, so that stakeholders can dig deeper if they feel they need to.
Of course, you’ll also need to carefully document your methodology, and it can be helpful to have an overview of your ways of working and of the people you engaged with (and why) in your introduction, and have full documentation available as an appendix. In any case, you’ll need to be able to defend your research approach (which, of course, you’ll obviously have agreed with stakeholders prior to the research commencing) vigorously, as there may be those who want to call into question the validity of what you have to say.
Offer actionable recommendations, not opinions. Share clear next steps that solve pain points or answer pending decisions. If you have any in mind, suggest future research options too. If users made specific recommendations, share direct quotes.
Bruton, L., A complete guide to presenting UX research findings
The recommendations section should be the ‘gold’ in your report. In this section you’ll be providing the balance to the negative findings you have dutifully reported. Here, you’ll help the developers to see how they can move towards better meeting the real needs of their audience by providing practical, pragmatic recommendations on how they can address pain-points and move to a truly user-centric service. These recommendations will be for actions which the team can readily prioritise and ingest into their backlog.
Your initial research on understanding the service landscape will have made you aware of the constraints the team have to work with, so your recommendations will not be pie-in-the-sky wishful thinking, but for pragmatic actions that they will be keen to take on board.
These can be seen as tactical recommendations, whereas the recommendations for senior stakeholders can be seen as strategic. With these strategic recommendations you’ll be looking at the bigger picture. Is there a need to pivot? Should some central tenet of the service or product be changed? What work needs to be done to make the value proposition clearer to users? Where should the future focus lie? What changes need to be made to get the project back on track? As with the tactical recommendations, these should be directly linked back to your actual research — these need to be seen as based on a solid body of evidence, and not as simply your opinions.
Telling the story of a product or service which has tested poorly does not need to be a tragedy. It should not be a chance for a UX team to show off how clever they are by demonstrating how everything is broken; and it should certainly not seem like an occasion to apportion blame. It should be an opportunity to identify the most important problems, to recommend how these should be addressed, and to provide a vision for a truly user-centric future.
Jim McCool is a veteran UX and human-centred design practitioner. He graduated with distinction from RMIT’s Master of Design Futures program and has more than twenty years’ experience in the industry.
