Sharing and communication

In our introductory course, we learned about the importance of communication and discussed a number of different ways you can communicate research insights and findings. In this step, we will explore communication more deeply in the context of this week’s theme – working in an agile team.

Ongoing communication

User researchers are an integral part of government service teams. As we have learned throughout Weeks 4 and 5 of this course, user research should take place consistently across all phases of the service life cycle, meaning that the user researcher should consistently be communicating with their team members and stakeholders.

Communication happens easily and naturally in this situation because the user researcher is working so closely with the rest of the team.

Contributing to regular team meetings and ensuring that research is prioritised during planning means that the user researcher is always able to advocate for the user and ensure that their findings are taken into account during the development of the service. If the team works together in the same office, user researchers can collaborate directly with developers and designers, providing feedback and insights during the design and development process rather than just looking at a proposed solution after it has been built.

User researchers also contribute to the team wall, which we mentioned in the previous step.

A team wall is a visual display of everything the team is working on and has learned through the process. Different teams may construct their walls in different ways and sometimes you will use an online tool rather than a physical wall, but the idea remains the same – it is a repository of information that gives an overview of the whole service and everything known so far. User researchers can share their findings here, including things like

• user personas
• journey maps
• key insights from user research sessions
• interfaces annotated with feedback from user testing.

User researchers can also use the team wall for shared analysis, by writing quotes and key insights from users on sticky notes and attaching them to the wall (or using virtual collaboration tools). These are then grouped around shared themes that are identified through analysing, comparing and contrasting what different users have said. This is called affinity mapping, which we learned about in our introductory course.

Team members or even other colleagues can then look at these findings and sometimes offer suggestions or spot connections that the team might have missed.

Show and tells and research playbacks

In the previous step, we discussed 4 agile ceremonies and how the user researcher can contribute to each one. These ceremonies are for the whole team to contribute equally and give each other feedback, and while user researchers should have time to share with the team, it can be helpful to organise dedicated sessions to discuss user research findings and insights

In agile, a show and tell is very similar to a sprint review – it is a presentation or demonstration of work that has been completed. Show and tells are all about showcasing the user’s experience and the service. They need to be as impactful and useful as they can be. For user researchers, a show and tell would be an overview of what research has been done and what has been learned.

The key difference is that show and tells often involve people beyond the team, such as colleagues from different departments, external stakeholders, including senior leadership or management, or even just anyone who has an interest in your project.

As your audience will be diverse and will often include people who do not already know anything about your project, you should always be prepared to give a high-level overview or introduction to what you have been working on before getting into the details. Always be open to questions during your presentation as well as making time at the end for an open Q&A discussion.

Most importantly, you need to have something to show.

During a show and tell, you can show things that you would include on the team wall, but these might not be immediately understandable to people who are unfamiliar with your project, such as a journey map or a prototype service interface.

Human stories and first person accounts will hit home and create empathy. Show video clips from research, hearing actual users speak with their emotion is more impactful and influential than text.Compile a slide deck with key points, short anecdotes, direct quotes and insights to communicate your research to external audiences and keep them engaged in your presentation.

Understanding how to communicate to different audiences is essential.

You need to be able to show your audience the value of your findings – what you have discovered and why it is important. Explain them in a way that demonstrates what that means to the service. Highlight risks, show the benefits of making suggested changes or how insight has been acted on to improve the service.

Like many things in user research, presenting your research is a skill that takes time to learn – and public speaking can be daunting! Just remember that people are there to learn from you about the research you have done. Keeping things simple and preparing beforehand will help you feel more confident.

When compiling a slide deck, design your presentation slides to be simple and accessible – stick to the key facts and avoid overloading your audience with lots of information.

Remember that you might also be doing multiple show and tells through the service development process, which means that you do not need to say everything all at once. Keep each show and tell focused on the most recent and relevant work that you have done.