POCUS Carnival
Educational Mobile Game
Unity3D
UX Research
C#
Overview
This mobile game was developed during my time as a game design intern with Indiana University eLearning Design & Services, in collaboration with the Indiana School of Medicine. We wanted to create a game to introduce first-year medical students to basic ultrasound image identification. During my time on this project, I was the primary designer and solo developer (Other members of the team included 2 project managers, one instructional designer, and 2 collaborators).
The development process of this mobile game was long and required much back-and-forth with collaborators. Because of this, I was able to use this as a great opportunity to hone my UX research and iterative design skills.
One important goal for this project was to make something that medical students of varying ages and gaming backgrounds could engage with. Because of this, I frequently iterated designs, and conducted playtesting sessions with prototypes. At the completion of this project, I had the chance to playtest with over 160 unique students.
Status: Published
Team Size: 6
Tools Used:
- Unity3D
- Figma
- Adobe Products
Contributions
- Designed and iterated core gameplay mechanics
- Conducted playtesting sessions with 160+ unique players
- Programmed gameplay functionality
- Coordinated with key stakeholders and team members
- Gathered and analyzed feedback from stakeholders and players
UX Research & Iteration
The initial idea for this game was simple: “We want to make a game that we can give to medical students for ultrasound subject learning!”. Because of the broad target audience, we knew early on that we wanted it to be a mobile game. This would allow students to download the game on a device that they (probably) already processed, and didn’t require them to own a laptop or computer.
I quickly created a prototype that combined the ultrasound learning goals with an escape room type of theme. In this prototype, the player would tap and move their finger around the screen to control a first-person perspective character. They were able to move around the room to different areas, and interact with certain environmental objects. In the center of the room, the player could move an ultrasound probe around a patient’s chest. Moving the probe into a predetermined orientation would allow them to see real-life ultrasound images that correlate to that specific probe orientation.
After testing this prototype with students, I gained a lot of feedback. I was initially confused, because most of the students seemed to have a great bit of difficulty playing the game in ways I had not anticipated. I took a step back, and looked at the differences between my expected outcome, and the actual outcome of these playtests. I quickly discovered one of the most valuable lessons that I’ve ever learned:
- I am not my target audience
This lesson might seem obvious, but at the time I had not considered that the players I was designing for would have vastly different experiences from my own. What I thought were intuitive game mechanics were difficult and clunky to the players.
Because of these results, I wanted to break down and analyze feedback so that I could decide on specific change that needed to occur. After doing so, the most meaningful feedback was related to one or more of the following:
The game mechanics are not fun
Controlling a first-person character on a mobile device is difficult
The intended flow of the game is not clear to players
The most notable issue was that the game mechanics were simply not very fun. Additionally, because the learning goals were not efficiently conveyed, why would students want to spend their time on this game instead of something else?
As mentioned before, the first-person character was difficult to control. Many students indicated that it was disorienting, and the controls did not feel intuitive to them. Because of this, many players would rotate their camera around, and when an environment element would highlight, they would not realize they could interact with it.
Finally, the game flow was not obvious. Students indicated that they weren’t sure what they should be doing at any given time. I believe that this was due to not only a lack of clear instructions, but also because the player was given too much agency.
In order to address these issues, I began a new prototype. This improved prototype aimed to address the flow and disorientation issues by making the game linear and 2D. Additionally, the prototype aimed to more effectively blend learning and fun elements to achieve a flow state within the game, where the students consistent short learning segments are rewarded with fun gameplay segments.
After conducting playtest sessions with students, I found that this prototype effectively addressed the issues present with the previous version. Many students indicated that they found the gameplay to be fun, and felt like they always understood what they should be doing. Feedback about this prototype primarily related to visual or smaller mechanical elements instead of indicating fault with core gameplay concepts.
However, it was decided that the game should be primarily used as a study tool, and the direction of the project changed slightly. Because of this, there was concern that some of the gameplay elements could detract from the efficiency of the learning objectives.
Because of this, it was decided that the game should resemble the first prototype, while still addressing the issues found with that specific version. With this new challenge in mind, future prototypes contained narrative clinical-diagnosis elements for the purpose of guiding the player. In addition to this, even though the game was 3D, the camera would move along a track to predetermined locations, in order to make navigation easier.
These prototypes were tested with students. After conducting several playtest sessions, participants indicated they would probably not play the game in their own time. Despite addressing some of the issues they aimed to, one big problem remained:
- The game was not very fun
The students indicated that they preferred the simple 2D prototypes to the complicated 3D ones. Even with additional direction, they would often feel confused and lost when playing the more complex prototypes. This was a big problem, and prevented the player from ever entering a flow state. Because of these findings, we decided that it would be best to pivot back toward a more simple 2D format.
However, even though we were pivoting back towards the 2D prototypes, it was desired that the game still focus primarily on the learning elements. Because of this, we focused on developing 3 separate mini-games, each with their own gameplay and learning outcomes. This was intended to keep each individual game simple and fun while still focusing on its overall learning objective without making it feel monotonous.
After continuing the process of prototyping and user testing, we arrived at the final form:
This project started out with many challenges. Designing for a specific, yet broad player base proved especially challenging. However, these challenges gave me the opportunity to grow by exploring creative solutions. These solutions were consistently informed by extensive playtesting, which helped me further understand the types of players we were making this game for.
Key Takeaways
- I am not the target audience; a game’s mechanics should be looked at through the lens of the specific player base
- Consistent prototyping and playtesting is essential to identifying core issues present with a game
- Player testing should be conducted early-on in projects, so that issues can be identified before even more time is spent building upon something that will need to change later