UX Case Study
Hyper Rush
Description
Hyper Rush is a high-octane, cart-racing game that was the first original IP game from Mighty Kingdom. The perfect project to help integrate UX processes into a pipeline that was lacking a player-centric mindset. By pinpointing our players’ needs we were able to better serve them with our design decisions.
My Role
I led design, research and communication to stakeholders plus artifact creation that helped define a clear view of our players. I also collaborated with product and development to ensure we were focusing on the right problems each step of the way.
In addition we created a template for UX functions within the development team that we could reuse for new projects.
Player characters from Hyper Rush
Challenge One
How do we add UX processes to the pipeline and instill a player-centric mindset in the team?
Introducing UX processes
Upon arriving at Mighty Kingdom in 2020 I identified that the UX maturity of the business was extremely low. The lack of player representation and voice also increased project risk due to the potential for poor player reception to our games.
By analysing the current pipeline we were able to spot areas where we could add UX processes such as gathering persona information and collecting player data via play tests. Adding these gave us clarity on how to solve the issues we were having, and where they were coming from.
Collaboration was also a key factor in improving the UX mindset of the company. Through this we were able to become involved in conversations that would benefit from UX input. Player-centric design became more popular over the course of the next 6 months and within 12 months we were being invited to collaborate with teams (completely unprompted) on important design decisions.
Solution
Methods
Research objective planning
Assumption mapping
Information sessions
New UX processes we added to the regular development pipeline
Challenge Two
Discovering who our players are
Solution
Player research and artifact creation
Initially created proto-personas to help flesh out who our players might be. These were used as the first step on the journey to understanding our players. We then set about validating our personas using real data, surveying our current database of 1000+. Upon survey completion we discovered a few key takeaways to help guide development.
Key learnings
Our target player archetype did exist.
Competition was a key motivation for our players
Gender was irrelevant to player motivations
High frequency of play i.e. nearly every day.
Methods & artifacts
Player interviews
Surveys
Personas
Proto-personas were created to have a first best guess at who our players were. We then refined the personas, created after player interviews in play testing.
Challenge Three
Gathering data and converting it to usable insights for the team
Solution
Play testing
During my time at Mighty Kingdom I introduced play testing as a data gathering method which had never been explored before. Play testing was a core part of understanding how our players played our games, what they liked/disliked and how the responded emotionally. We spent sessions with stakeholders defining research objectives and hypotheses to help us gain clarity on what we wanted to learn. We then ran in-person play tests with players which contained player interviews, surveys and recordings of their sessions. These sessions were then repeated at regular intervals to help gain continuous feedback from our players and guide development.
Methods
Stakeholder engagement
Player interviews
Play testing
Survey creation
Research objective planning
An outline of how we planned our play tests with the team and the steps required for success
Player pain point example
Players felt like they were alone while playing a multiplayer racing game
An example of an issue that arose was that even though players were participating in a race with up to 15 others, they were feeling as though they were alone. Interactions with other players were few and far between. So how did we tackle this? In the gameplay footage we could clearly see that other players were within their view, but yet in their interviews they claimed that there was “nobody around them”.
An example of how we tackle these types of issues is illustrated via the diagram shown. We first tested, observed the player and then highlighted the pain point that they mentioned, plus what we observed. In this case we were able to see that the issue wasn’t that they couldn’t literally see any other players, it was that they were too far away from them to be able to interact. The review with the team highlighted this as a high priority issue that needed addressing immediately. The ideation process then hit upon a solve: smaller levels with more convergent points within the design. Once we had this implemented we were ready to test again with new hypotheses.
The result was that players stopped mentioning this as an issue at all and spent more time playing sessions that involved positive responses to interactions with other players during races. Success!
Our play testing system allowed us to pinpoint reasons why players felt a certain way and discover how they were reaching their conclusions.
Accessibility
Games for everyone
Our approach to accessibility was guided by the Games Accessibility Guidelines. Ensuring that we adhered to at least the basic level of accessibility for our game was something we considered from the very start. This removed the possibility of rework later on due to the fact that we had a clear level of commitment to an accessibility bar.
Accessibility guidelines were used from the beginning of the process to ensure that it was built in from the start.
Outcomes
Better game feel with a focus on “just one more try”
Addictive Gameplay
Between persona creation and constant testing with the right players, we were able to create an addictive and satisfying gameplay loop. We gathered insights to share with stakeholders and other team members that helped inform their choices. This in turn led to better game feel and overall player satisfaction. Feedback, surveys and reporting led to players feeling heard and game design choices becoming data driven.
Clear Player archetypes and personas
By inserting new UX processes into the pipeline we were able to discover more about our players than we ever had before. We could also prioritise important issues, safe in the knowledge that they were the right issues to be solving.
UX functions blueprint
Last but not least, we were able to create a blueprint for UX interactions in the development pipeline within the business. This was then used as a template for approaching new projects going forward.