It might just be confirmation bias, but I feel like I’ve been hearing the same question a lot lately: how do you present your results from your user experience research?

I don’t think of the question in this manner.  When you state the problem in this fashion, it presumes that there is one way to do it, and that you do it once and that’s it.  My goal in conducting research is to have it make an impact.  I can do the most awesome user experience research that has ever been completed on any product anywhere in the world by any researcher, and it’s meaningless if it doesn’t actually result in an improvement to the product.  I think that the correct question to ask is, “how do you share the results from your user experience research such that they get acted upon?”

Presenting your research results is never a single task that you do once and never do again.  You will share the results of your research over and over again throughout the development process, regardless of whether the process is agile or waterfall or some mix therein.

The first thing that you should do when you are conducting research is ensure that you have buy-in from whoever you’re going to need it from.  This certainly includes the designer and program manager, and usually includes others as well: additional researchers and designers who are working on related projects, software architects, engineering managers, QA managers, and anyone else who could block the adoption of whatever results come out of your research.

The second thing that you must do is ensure that you and the designer are always on the same page.  After you have conducted the research and are in the process of analyzing the data, you need to involve the designer to ensure that you have captured all of their concerns.  When I am crafting recommendations, I usually create a first pass of them as part of the analysis, and then work with the designer to get their perspective.  In my eyes, that first pass at recommendations is a strawman, intended to kickstart the conversation about what the final results should be.   You want your final results to include recommendations that are the user experience recommendations, not just the user experience research recommendations.  You don’t want a designer to feel like they’ve never heard about an issue until an official results presentation meeting, and you certainly don’t want them to feel like your recommendations don’t meet their design goals.

Likewise, if you anticipate that these recommendations are going to be contentious or will require significant unexpected work, you should discuss the research results and recommendations  with those who are most likely to be impacted by that.  These discussions are usually 1:1, and give you the opportunity to understand other constraints.  If there are major constraints, such as scheduling constraints, you can work in advance to prioritize the recommendations, and work with the designer to come up with a design that addresses as much as possible now as well as a long-term design that will be implemented in the next version.

Once all of this is done, the way that you communicate your research recommendations depends on the needs of your audience. Your communication style needs to match theirs. If they communicate exclusively through their bug-tracking mechanism, then your design needs to be communicated there too. If they communicate via wiki, then your design needs to be wiki-fied. If there’s one stakeholder who really needs to buy off on your design and everyone else will follow that person, then you need to figure out who that stakeholder is and figure out how to get them to buy off on your design. If everyone needs to come to agreement that your design is the one that they will implement, then you probably need to have one discussion with project managers and a different discussion with engineering. Each of those groups have different goals and different needs, so having a separate discussion with each of them means that you’re able to address their unique goals and needs, as well as answer any questions that they might have.

As a part of all of this, you might give a presentation to a roomful of people to discuss your research results, and you might write up a big report and send it out in email.  But that’s not the end of the process.  It’s only the beginning.  You’ll need to share your research results more than once. You’ll need to track the development process and ensure that your recommendations are being acted upon, and communicate with the team if they’re deviating from the recommendations. It might be that they’ve forgotten elements of your recommendations, or that someone new has come on board and simply isn’t aware of them, or they disagree with it and so are conveniently disregarding the research, or (as in every software project that has ever existed) they’re having to make changes to their plan (adding features, cutting features, cutting parts of features, etc), and thus parts of your research recommendations are impacted by those changes. If they’re going to make changes or compromises in the design that you researched, you should be a part of that discussion — you know the design and the research recommendations the best of anyone, and you know why you made the design recommendations that you made, and you can help them make decisions and discuss the trade-offs between development time and user experience.

Remember: no-one cares about your work more than you do. For your research recommendations to be truly effective and fully implemented, you’re the one who’s going to have to track it and make sure that it actually happens.