Review research learnings with your team

User research is all about putting the assumptions you are making about your product to the test. It’s about learning what your users are like, and what’s working or not working in what you’re building. But learning for the sake of learning is useless.

The end result of all user research should be actionable learnings that make your product better. If your research isn’t creating insights that your team can react to and use to push their work forward, then you’re wasting valuable resources.

Why share with your team

Sharing with your team is how you create action. In a perfect world, as a researcher, your entire design team will participate in every session, and already have an understanding of the learnings. But even in this often unrealistic situation, it is your job as a researcher to look at the sum of your findings for a particular project, and distill those down into actionable insights. Sharing with your team is the way that you get these insights out of your own head, onto paper, and into action. So what’s the best way to share these insights with your team?

How to run a sharing session

Schedule time — schedule a time for your team to meet, uninterrupted, to discuss your research learnings. The length of this meeting will depend on the volume of information to go through, but it’s often a good idea to err on the side of being a bit longer than you think you might need. It is not recommended that you shoe-horn this session into the end of another meeting (e.g. at the end of standups), or when your team is otherwise distracted.

Remove distractions — if your design team is distracted, the quality of the sharing session will suffer. Put away cellphones, and close laptops (unless notes are being taken related to research learnings, prototypes are being reviewed, etc.). If your team is already adept at running efficient and productive meetings, this should be second-nature already. But it’s up to you to set the precedent that everyone must remain focused for the duration of the session.

Have frank, honest conversations — sharing research learnings has the potential to hurt feelings. Chances are, the design team has worked incredibly hard on the work that went into research, and hearing about what the user didn’t like about it can be a touchy subject. Nobody likes hearing about how the thing they worked so hard on doesn’t actually do the job it was created to do. But in a productive research sharing session, there’s no room for feelings to be hurt. As a researcher, it’s your job to deliver feedback on a designer’s work in a nice and conscientious way.

Encourage discussion — a research sharing session should not just consist of the researcher giving a one-way presentation on their findings. For a sharing session to be effective, there needs to be a two-way dialogue, where the researcher and the team discuss findings, debate rationale, and together make a plan for action. If you’re doing research right, members of your team will have participated in research and already have some insight into research results. Giving them time to discuss and share thoughts on it will ensure your researching sharing sessions stay productive.

Create structure — break down your session into sections — it will help you go through learnings in a more structured manner. You can break it up by parts of the prototype/design that was tested (i.e. “first we’ll discuss registration, then homepage, then the support feature…”), or by what is working, what needs improvement, and what received mixed results. However you choose to structure your feedback, go through learnings one-by-one, briefly discussing outcomes or next steps associated with them.

Document outcomes and next steps — whatever your team decides to do with the learnings, document them somewhere that is easily accessibly by your entire team. Add them to your project/product management tool of choice, and assign to the appropriate people.

Don’t leave them hanging — shed light on further research to be done, and set time to follow-up.

Get your team started running user research — sign up for Field Guide