Credits: The images used as banners and icons here were derived from

23lunes Creative Animation Studio. (2014). Ender’s game. 23lunes.studio. https://www.23lunes.studio/work/enders-game/#PhotoSwipe1656762412402

<aside> 🌐 Back to Vikki’s Portfolio

</aside>

Moving away from heuristic evaluations, the recommendations we put forward for this game was based on a self-moderated usability test. However, with my regularization to a full-time job at the time, I presented the findings to the lead developer/ story writer / character designer of Team Kizuna through a Miro board instead of giving a written report.

Below is a snapshot of the board we used to discuss my recommendations, with the summary of the research insights in bullets on top.

One benefit of having more collaborative synthesis or insighting sessions over just sharing a written report is having the opportunity to correct or clarify important points on the spot. For example, in the battle sequence (sampled in the screenshot below) you’ll see 2 bars for HP and SP. I never got into a situation in the game where the SP feature was used so I easily assumed that it was your usual Skill Points in an RPG. Turns out, they were ‘Shield Points’. These are used as a buffer to your Health Points but only fills up if your character has the ability to supply it.

A screenshot of the battle interface from my playthrough of the game, Softwar.

I either would have learned that at a much later time or not at all, if we skipped having a more personal conversation*.* Especially since (let’s be honest) people rarely read written reports thoroughly.

Moving to solutions, from the top of my head, I referenced how Divinity 2 : Original Sin executed their ‘Armour Points’ side-by-side with the player’s health points during our discussion. Then, later on, added it to the board with visual references for inspiration on what may be done to clarify what SP really is.

I tried my hand at iterating how the battle interface could look like and came up with some possibilities to consider. I wanted to try bringing up a range of options with varying complexities since I was not familiar with what Ren’py was (this was being used to develop Softwar) and what it’s capable of in Raseruuu’s hands. In the end, these were some of the iterations, side-by-side with the original interface.

From right to left, you’ll see: (1) an iteration that makes use of icons to communicate what each of the elements on the screen are; (2) an iteration where HP and SP were reworded to Life and Shield; (3) an iteration that makes use of only 1 bar to communicate how much Life the character has and whether or not any shield is reinforcing that.

We also talked about the story, some bugs I found in the menu features, navigation, controls and the lack of visual cues/aids in certain portions of the game. However, the more important thing I wanted to highlight with this project was the reminder I got about the importance of having closer working sessions with developers and designers about the results of testing efforts.

Those kinds of working sessions always helped me, as a researcher, to eliminate more biases or blind spots in my work. More importantly, it better solidifies the insights in stakeholders’ minds, while avoiding anything to be lost in translation. Involving them in translating observations to insights is really the way to go.

I am happy to have been able to bring this lean approach to the table on my personal projects. On the other hand, I’m hopeful to be able to move that further by trying to open an opportunity for developers and designers to observe uninterrupted / raw interactions between players and their games. Experience is, after all, the best teacher and nothing helps people build empathy better than observing what happens for yourself.