Player Response to Major IP Usage

#FF644E
#5E5E5E

---

Situation:

---

Following 2 in person playtests of the same game a couple weeks apart, I was tasked with analyzingthe player responses from these playtests and writing a report on how the players felt about the games usage of its attached IP [REDACTED]. This was a very large IP, and the characters, designs, locations, and art style of this game were all adapted from it.

Research Objectives:

• Player’s overall feedback about the [REDACTED] IP Content
• Do players feel that anything in game does not match the IP’s style?
• Anything from the IP that players want added to the game?

Challenges:

There were a few challenges in my way. Firstly, I had only been at this company for about a month as a Jr Researcher, and being 1/4 of the UR team conducting these playtests I had not been given any formal training. This meant I was unfamiliar with the stakeholders expectations for the format, length, and scope of the report. It was labeled as a “Mini-report”, but I soon realized this did not mean mini in length. This unfamiliarity and greenhorn status on top of the report being directly related to one of the largest entertainment IP’s on earth had me a little stressed.

Secondly, there was a lot of data to go through from these 2 playtests and very few of the questions asked in the survey and interview were directly related to the players sentiment about the [REDACTED] IP usage. This meant qualitative coding was an uphill battle of sifting through a bunch of unrelated questions to find players comments and responses to the IP usage, and limited numerical data about their feelings as well. This meant I had to get creative with my analysis.

Tasks:

With this situation, I had to accomplish several challenging things as a new team member. The first was to communicate with a senior coworker on my team to define what was expected of me and this report. Secondly I had to organize the scattered data into usable clusters and connections with some numerical evidence while maintaining research validity. Thirdly I had to present these as actionable insights with accompanying evidence. As a team member of about 2 months, the idea of telling stakeholders many years my senior who had been working on this game for years about how players may or may not have liked how they adapted one of the largest IP’s in history felt like a daunting task.

Actions:

To start, I communicated with my mentor to see what was the company’ss general expectations of a report like this. I found out a few main guidelines that helped me write my report:

• Information heirachry per slide was 1) title sentence outlining an insight 2) examples and paraphrasing of player feedback supporting that insight, and 3) numerical or quote evidence supporting that.
• “Mini report” meant a small focused scope (in this case, IP Usage) that was still expected to be explored quite in depth. My report ended up being over 30+ pages long.
• Insights had to come from the perspective of the players, not what the researcher thought after analyzing the player feedback. This was important when communicating to stakeholders who might have been working on a game for year because if they think the report author is the one calling their baby ugly, they aren’t very inclined to listen.

To organize this report that utilized such scattered data, I first defined the core of the [REDACTED] IP and how that set player expectations. Secondly was the IP elements which I broke down into 3 categories most relevant to this game:

• IP Core: I can only be so specific here to abide by the NDA, but the players had very high expectations for overall quality and polish across the board for anything involving this IP. However, the player preference on different styles of adaptation where more varied. The most popular preference was that which most closely resembles the already existing most popular adaptation of this IP. I know that is vague, but I cannot legally be more specific.
• Characters: How the characters visual design, abilities, and roles were received by the players, especially in relation to their adoption from the [REDACTED] IP. Characters players expected to be included in the final game was a big part of this as well. Numerical averages for player satisfaction with the character roster and character design were used heavily as a point of comparison in this category.
• Maps: Both the setting and art design of the maps were discussed by players. As well as setting expectations for future maps. Player quotes and qualitative feedback were especially important here and there were no survey questions directly asking about the maps settings and adherence to the IP.
• Aesthetic: This detailed the player response to the combination of character design and overall art style, and additionally UI art style. Numerical averages of the player satisfaction the character design, environment design, and these designs “feeling” like the [REDACTED] IP were used as comparison points here.

Result:

After my report was submitted, I had limited communication with the dev team due to the structure of the company. However, feedback from my manager said my report was “in line with expectations” which was pretty positive considering the undefined expectations and my new hire status.

My report did not shy away from mixed and negative feedback from the players, but even so the product team had a psotive response to my hand off, and did not havbe any questions for me!

Finally, and maybe most importantly, I saw some of my insights acted upon in future builds I ran playtests for. Obviously details can’t be discussed here, but seeing characters and settings my report explicitly recommended being added to the game was a good feeling. I had both analyzed and communciated the insights clearly so the dev team was able to take them and use it to inform changes, which is all a games user researcher can hope to achieve.

Reflection:

In reflection, this report was a great learning experience for both soft and hard skills. My report writing ability improved a lot through adapting to this particular format of report and the unfocused data that had to be used. It was also a big confidence booster wiring my first report for the company and doing somethingthat was related to such a big IP. It was not free of mistakes however, and one was my efficiency. There was no deadline given to me, so I ended up taking longer than I should have toiling away on useless slides and worrying about things I should not have. Being my first report at the company and being related to such a big Ip may have boosted my confidence after the report was finished, but during writing it was quite intimidating and made me lose sight of my fundamentals. The experience taught me a lot more about remembering my fundamentals when a project becomes distractingly stressful, and prioritizing communication and efficiency over perfection in the workplace.