At this point the team will have aligned on what happened, and also aligned on a plausible explanation as to why things happened.

Now, there is a further chance to align on prioritising the order of what is most important to address. Reaching alignment on how important each issue is will increase the chances of action being taken to resolve them, and in the most appropriate order.

Prioritising Issues

To help decide which issues are the most important to resolve for the player, we can use a framework to help with the decision making. Having a decision-making structure should make it easier for the team to decide the relative importance of issues, reducing the possibility of a team member providing a biased opinion about what is important.

To prioritise the issues, it’s useful to consider these five factors:

1. Impact - what were the consequences of the issue? E.g. at one end of the scale it might completely block the player from progressing, and on the other end of the scale it could be a minor annoyance.
   
   

2. Frequency - how often does the issue occur? E.g. every time the player does an action, or maybe it only happens once in the game.
   
   

3. Location - where does the issue happen? Is the issue located on a part of the game only few players will see, or is it on a ‘red route’ where every player will experience this issue.
   
   

4. Resolvability - how easy was it for the player to overcome the issue? Can the player work around the issue or will they experience it every time?
   
   

5. Essence - does the issue impact on a feature or system which is at the core of your game, impacting its essence?
   

Now that we know which factors to consider when assigning a severity rating, it now remains to go through the issues in the observation sheet and assign a rating against each one.

Ranking the Issues

There is no agreed-upon rating scale to use, you might want to use a system you are already using for prioritising which features to work on, or for categorising which bugs to fix. The labelling itself doesn’t matter, what is important is that everyone on the team knows which issue is more important to fix relative to another - the order of issues to work on should be clear.

For example, you could decide to use a labelling system of High, Medium, Low, or 1, 2, 3 etc., but what should be clear is High priority issues should be addressed before Medium priority issues, and Priority 1 issues should be addressed before Priority 2 issues.

There are no strict rules about what makes something High priority or Medium etc, that’s up to you to decide, but it might help to think of the five prioritisation factors as a scale, and if an issue might sit on the higher end of any of the five factors, then it may be a high priority issue. For example, if you have an issue that by itself isn’t particularly major (Low on the Impact scale), but occurs every few seconds in gameplay (High on the Frequency scale), then you might consider that a High priority issue and should be addressed immediately.

Once you have assigned a severity rating to each issue, you should be able to produce a ranked list of issues to address. Getting the team to align on this order is beneficial, you want to ensure that the team are working on the issues that will have the most impact on the player experience.

Findings - Alignment Complete

With the team now aligned on what happened in the playtest (player behaviour), why these things happened (plausible explanations), and the order in which issues should be addressed, it’s time to share what has been learned with the rest of the team and studio.

Key Takeaway

Aligning on the importance of each issue will ensure the team are focussing on improving what matters most for the player experience. Having the team align on the trio of what happened, why it happened, and the importance of what happened, should provide significant momentum to change happening.

Next: Step 6. Knowledge Sharing > 57. Building a Culture of Learning