Sharing Games User Research Findings

Communication is one of the most important skills for a researcher to have - here is the lowdown on sharing games user research findings.

Last updated:

User researchers find problems with games. But it’s usually someone else who has to fix them.

This means communication is one of the most important skills for a researcher to have – and sharing games user research results is critical to having an impact on the quality of games. 

In this issue, we’ll look at some approaches for sharing research findings, and share some tips from the pros! 

Get future games user research lessons direct to your inbox in our monthly newsletter, sign up at the end of the article

Sharing games user research results accurately creates an impact

From our playtests, we learn how does the game currently differ from the design intent. Much more crucially, we also understand why it differs – what caused players to not understand, or to do the wrong thing. 

Understanding the why is essential to making the right decisions about how to fix the problems. Usually, it is someone else who actually makes the final decision on what to do to fix it – a game designer, art director, level designer, etc…

Full and accurate communication of the issues, their causes, and the impacts mean that our colleagues make the right choices. 

Making a traditional research report 

The most common way of sharing research findings is to write a report. I have an old example of one on my blog, which – although I would do some things differently today, is still a good idea of what a research report might look like. I’m also sharing a new, real, research report as part of an upcoming GRUX Online talk – look for that in a future issue. 

As you will see, the report runs through each of the issues in turn. They are grouped by topic. Matching your groups to ‘what discipline would be working on fixing this issue’ can make distributing the findings to the right person easier. 

For each issue it explains what the issue was, why it occurred, and what impact it had on the player – this information will help teams make the right fix and prioritise the issue appropriately. 

When writing reports, it’s important to write concisely, and use plain language – we’re trying to make sure we’re understood. Complicated words don’t impress anyone, and just confuse your readers! Here’s some tips on how to write better. 

I would always recommend presenting the report to the team live. People are much more likely to pay attention, will have the opportunity to ask questions if they don’t understand, and it just gets a whole lot more engagement. Although it can be tempting to send a report and say “let me know if there are other questions”, I suspect that this leads to reports being ignored, and reduces the chance the team will react to your findings. Ignored findings make running user research pointless, so let’s try and avoid that when we can.

A report is not right for everyone

Its really easy to get into the trap of thinking ‘a user researchers job is to make research reports’. Our job is to make the game better, and that a research report might not be the best way of doing that. 

For some teams, a report isn’t appropriate and would be ignored – instead consider alternative methods of sharing findings:

  • An interactive workshop
  • An email covering the top 5 issues
  • A message on slack
  • A research insight database that they can interrogate
  • Access to the raw data 
  • A conversation 

When starting with a team, think about how much time they have, how they communicate currently, and use that to decide what is the right way to share the results so that they don’t get ignored.

Research has multiple audiences

As well as the team who asked for the study, there are some secondary audiences who will also be interested in aspects of your study. They might need a different method for the findings to be shared with them.

Some of those audiences can include:

  • Executives who don’t need to know the detail, but do need to know if there is a big problem
  • Other teams working on different projects which some of the findings might be relevant too
  • Yourself in 12 months time, trying to remember if this study is a topic you’ve done before or not. 

Many of these won’t have the time to read through all of the detail of your report – consider some of the other methods that might be more appropriate for sharing research findings with them.  

Some prompts to think about:

In interviews, you are likely to be asked about your experience sharing research findings. Some aspects to think about in your answers include:

  • How did you decide what was the right method of sharing the findings?
  • Did you understand the needs of the audience and use that to inform your decisions?
  • How did you evaluate if you had been understood correctly?

Some research results tips from the pros

I asked the community if they had any tips for a successful debrief. Here’s what they said. 

I like giving my results a hierarchicy that relates to the research problem. That way we circle them back to the research questions and it helps staying in scope. I also use a usability severity rating attached to insights so that it can have an impact on priorities in the debrief with designers :)

Laure described how prioritisation is important for making sure the results are relevant. A common mistake I see (and do myself) is trying to fit in all of the findings, and make them all prominent, when all the team really need is ‘what is the most important thing we need to do next’ – which Laure’s method addresses.

For a usability rating scale, I personally like using this severity scale described by userfocus – but other’s exist too! 

You should definitely make sure to know for whom you are writing your report. The vocabulary you use might be different based on who reads it. Also, the level of details might vary based on how much time readers are willing to dedicate to your report. It's also a good idea to have quick takeaways at the very beginning for people who don't have time or to pick up interest of others.

As Raphael says, understanding your audience is incredibly important. At the start of a project, make sure you know who will be interested in the results, so that you can tailor your delivery to them.

Playtesting at Develop Conference

A busy month ahead for me. I’ll be talking at Develop Conference next month sharing some lessons on running affordable playtesting for teams who can’t afford full-time research support. 

Steve Bromley Develop - Better Playtesting for Indie Developers

Do come and say hi if you’re attending! (and if it’s a topic you’re interested in, do sign up for updates on when I publish more resources to help indie teams)

Have a great month and good luck on your games user research journey!

Steve (follow me on Twitter for more games user research news throughout the month!)

Get the free games user research career guide

Ready to finally start your games user research career?

Every month, get sent the latest articles on how to start a career in game development, and find games user research jobs.

Plus get two free e-books of career guidance from top games companies

Free Games User Research Ebooks
Author image

Meet the author

Steve Bromley is an expert user researcher, who works with studios of all sizes to run playtests, and integrate user research into the game development process.

Learn more

Keep Exploring

Managing Stakeholders

Managing stakeholders to increase research impact

Low impact studies are often rooted in misaligned teams.

Test A Game With Kids

How to test games with kids

Practical guidance on how to get high quality data from your playtests with children. 

How much to playtest

How much playtesting is enough?

When to start (and stop) playtesting throughout game development.

Master Games User Research

Free monthly new articles teaching playtesting & how to be a games user researcher. Join the most interesting conversations about games user research, discover job opportunities, and be introduced to new ways to think about game development.

Which best describes you?(Required)