Steve Bromley (a Games User Researcher) that I know online, have a great deal of respect for, but have not yet met in person did a blog post recently on “What’s in a Games User Research Report.”
There are a lot of great insights in this blog post, especially for junior user researchers that want insight about how to structure a report in a way that can be consumed easily by stakeholders. I am going to present another perspective on recommendations, however.
There is no recommendation for how to resolve the issue...In a typical debrief, we’d pair sharing the usability issues with a session about fixing the issues. This is in place of providing recommendations ourselves – often with something as complicated as games, many ‘obvious’ solutions would not be possible. So, to reduce the time taken suggesting things that cannot be done, instead we prefer development teams to generate solutions themselves. A workshop format means that the researcher can input their usability best practise and knowledge, while still making sure that developers lead the discussion on what fixes are appropriate.
Emphasis added by me. I take Steve’s point, but I disagree with the concept that games are too complicated to make helpful recommendations for. While making poorly focused or scoped recommendations will damage your credibility, I see the following advantages for making recommendations in a report:
Developers often know issues exist, and are unhappy that they are in the game in the first place. It’s very rare to present a negative finding that is a complete surprise to a team.
GURs are hired for insight about games as much as they are for their ability to find data. Having an opinion about what to do about the data makes the GUR a more active participant in the development process.
Developers turn to user researchers in part to help provide data and direction to areas of contention. Once a GUR has built a relationship with a team, the data/direction ration tilts more and more towards direction. Without making recommendations, you lose the opportunity to build that credibility.
Steve (and others in the GUR discord chat) see disadvantages:
Games are complicated, and it’s easy to make a recommendation that’s either impossible to implement or impractical for other reasons.
Making the wrong recommendation damages your credibility.
GURs are usually not game designers, and may not think of the optimal solution.
Here are my strategies for approaching recommendations in a way that preserves your credibility as a GUR while still allowing you a stronger position within your team:
Understand your game, game genre, and competitors: The biggest risk that Steve and others identified is looking stupid in front of your team. The most important thing to do is make sure that you’re as much an expert about your game genre and game as any of the designers or engineers. If someone brings up a point about a mode in a competitor’s game, it’s important to be able to have an answer to that.
Involve stakeholders in data collection and analysis: There is a great risk if the first time the team was exposed to the general trends of your findings is at the report. One way to mitigate this is to involve members of the game team in the research process. Invite them into moderation rooms and jam with them between sessions. Train them to be playtest moderators (you will be surprised how excited designers will be to moderate a playtest session. Let them observe issues first-hand; they’ll be much more prepared to deal with them.
Preview results to key decision-makers (especially the ones that will have to execute recommended changes: One technique I started using at Zoosk that I continue to do to this day is give stakeholders a preview of the results and recommendations 1-on-1, usually at their desk or somewhere similarly informal. This gives you the opportunity to gauge their reactions, get their input on your recommendations, and workshop better, more relevant recommendations. More than once I looked like a wizard in front of the CEO at Zoosk because I came into a meeting with results buttoned up, recommendations vetted, and presenting the plan for addressing the issues with my stakeholders, rather than simply to them.
Know when to push (and when not to): Even in the best case, there will still sometimes be conflict and/or pushback about recommendations. As a researcher, you should know ahead of time which recommendations can flex and which ones represent a clear danger to the game or the user experience. Being flexible about solutions in most cases will give you the standing to push back when its really important.
Note: all these recommendations come from the perspective of an embedded user researcher. Consulting or centralized user researchers may need to approach the problem differently.
Hopefully these recommendations about recommendations were helpful!