Cryptid Quest by Mappa
Respecting players with a balanced and hands-off game tutorial.
How I helped Mappa City with their all new game - Cryptid Quest - by designing a minimally invasive, integrated tutorial that respected players’ intelligence and encouraged learning through exploration.
Challenge and Scope
Cyptid Quest is to be an immersive, open world, mobile and desktop experience where players collect clues, currency, items, build metaverse assets and find mythological creatures - Cryptids. Over a 3 week design sprint, my teammates and I were brought on to design and prototype the onboarding and tutorial process for the game. Our deliverables would include: wireflows for both a desktop and mobile experience and a prototype desktop experience.
I set out to lead the team in the gameplay interactions, the UI design (the client wished to see glassmorphic and claymorphic styles in the UI design), and building the final prototype in Figma.
Understanding our target gamers.
15 Participants | Ages 20-43 | 4 females, 10 males, 1 non-binary
In our user research we wanted to know what motivated people to play games, what made them more or less likely to follow a tutorial in a game, and why they would came back or stop playing a certain game. We synthesized our findings by affinity mapping and came up with the following key insights:
Two main types of gamers - The majority of users fall into one of two categories: Those who play to escape reality, relax, or while multi-tasking, and those who play for socializing, excitement, and lore.
Tutorials should be accessible but optional - Players want access to a tutorial in case they need one, but like to jump straight into a game and first experiment with minimal interruptions.
Prioritize a good progression system - Players want to feel that they are progressing and overcoming large or small challenges in order to stay invested.
Variation to tasks keeps users engaged - Players require variety in the tasks they complete and in the level of difficulty and level of reward to challenges they face.
In order to design the least intrusive tutorial possible, I considered which tasks were the most critical for players to complete to achieve a baseline competency level. We trusted that users would continue to advance through exploration.
Mapping out critical tasks for players
Participants: 10 | Mid-fidelity, mobile | 16 tasks
We tested our initial rough solution against 10 participants. I designed the test that we would used, analysed the data and produced the following findings:
8%
Error Rate*
76%
No Error Success Rate
66/100
System Usability Score*
Testing Our Initial Solution
I synthesized and visualized our data into the graphs seen above. While there was an overall positive response to the design of the prototype, there were issues that needed to be addressed in the following areas:
The bottom navigation that houses most of the in-game controls was too cluttered, leading to confusion and cognitive fatigue.
There was a dissonance between taking action in the game and the purpose and motivations behind what the player was trying to accomplish.
Participants of the test reported wanting more flexibility to skip or hide the tutorial. Sometimes exploration, trial and error were better ways of learning a game than having it laid out at the beginning.
*Error Rate is defined as the number of times a user makes an error compared to the overall opportunities for an error to be made during any given task. Error rate is calculated as a percentage. For example a 10% error rate would mean a user made a mistake 10% of the time when completing any given task.
** A system usability score was calculated with a post-test survey in which participants were asked questions about their experience with the prototype on a likert scale. Example questions include: "This game was easy to play” or “I would need help from an expert to play this game”. Users would then select on a scale from 1-5 from completely disagree to completely agree.
Developing our final design solution
I was tasked with the transition from mid to high fidelity and led the creation of the the prototype including UI elements and interactions. Because a main goal for the project was a mobile-first design, we began designing in mobile to ensure usability and adapted our designs to desktop afterwards. Due to time constraints, adjustments to the mobile design were made and then adapted to desktop shortly after.
Final Prototype
In the final prototype, I was responsible for transitioning the designs from mid fidelity into high-fidelity, as well as creating all the animations and interactions and interactive components in Figma seen in the prototype.
The first day of gameplay is primarily about onboarding players and introducing them to the lore as well as game mechanics. In the first day, players will create their avatar, learn about cryptid lore, and become introduced to quests, helpers, and clues. A revised tutorial flow includes all the necessary lore to understand the context of the game and justify player objectives with the ability for the player to skip portions should they choose to do so.
Day 2 has players continue to collect clues for their quest. Day 2 also introduces the player to the shop and inventory where the player can buy and equip items. Items can be found while exploring or bought in the store.
The final day of the prototype begins with the player being introduced to another collectable in the game: chests. Chests are high-value finds that have a higher than average chance of holding rare items, clues, and large caches of currency. On this day the player also finds the last clue to their first quest and travels to Yetiland to complete it.
The final prototype our team delivered succeeded in meeting client needs, including:
A simple and clean GUI that features glassmorphic and claymorphic style elements.
Wireflows and prototypes for the first 3 days of gameplay.
A tutorial flow that effectively introduces story and lore, mechanics, and vital information to the player from the beginning, while being as non-invasive as possible.
Desktop and mobile designs.
A challenge we faced as a team was a lack of familiarity with game UI design. Unlike mobile or web design, game design introduces complex mechanics and unfamiliar UI elements that we as a team had to quickly learn. The discrepancy in game design and blockchain knowledge between our team and the client made communication difficult at times. An additional constraint was the animation needed to make a high quality prototype was beyond our skills or time frame. As a result, while game UI elements are interactive in the prototype, perspectives and characters are static on screen and require a modicum of imagination in order to “play the game”.