Game Genie — Roxanne Cole

Game Genie

UX Design Project

Overview

Category: Mobile application

Project Length: 6 weeks

Team Members:

Scrum Master: Cady Hamby

Interaction Designer: Roxanne Cole

Interaction Designer: Erica Hester

View Game Genie Prototype

The Idea

Gaming culture has grown to be very diverse and attracts new players every day. With more people staying at home due to COVID-19, many people turned to gaming to pass the time or play with friends who they cannot see in person. But if you’re more of a casual gamer, you might find yourself a bit lost when you want to find new games. Game Genie is a mobile app that will help you find new games based on your interests or from games you already know and love!

Design Process (Lean UX)

Game Genie was created in my Interaction Design II class, where we learned how to apply the Lean UX design process to the development of our app ideas. Lean UX is a design management system that is based on assumptions in order to achieve business and user outcomes. Lean UX is managed by consistent communication between team members and with users. This design process allowed us to develop our app prototype quickly and efficiently while listening to users throughout the entire process.

For the purposes of our class time, our team worked through two design sprints, each 3 weeks in length. We prepared for the sprint in a design week (Week Zero), assigned each team member specific tasks for Week 1 and Week 2, and conducted four interviews as a team for each sprint. This sprint structure allowed us to decide what assumptions we were validating, when we were validating them, and how user feedback would revalidate these assumptions. Due to COVID-19 social distancing, we worked remotely and collaborated over voice calls while using Miro and Figma.

Sprint 1: Week Zero

Before building the app, we needed to understand who our users were and what our app needed to benefit them. Our first Design Week, our team collaborated in Miro in order to produce a problem statement, assumptions, a product backlog, proto personas, and a sprint backlog. Our initial app name was Game Match, but this would be changed to Game Genie later.

Problem Statement

Our first step was to construct the problem statement. We identified the issue our users were having with game recommendations, how our app would address this issue, and how our solution differed from other competitors. Our problem statement was constructed using the New Product Template and is as follows:

“The current state of game recommendation services has primarily focused on being a search engine rather than providing its own information within the same website. What existing products/services fail to address is game genre, platform, and why it is similar to games you already played. Our product/service will address this gap by recommending games related to ones the user already likes, describe what type of game is being recommended, if it is playable on the device the user has, and what genre it falls under. This would all function within the app instead of jumping to different websites like existing services do.”

Assumptions

Each member of the team wrote a list of assumptions about our app individually. These included both user and business assumptions, and anything else we thought would be associated with our idea. We then came together and discussed what we wrote in order to help us all come to a mutual understanding of what we thought our app was going to be and who we thought was going to use it. Notably, we all agreed that our app would include a recommendation feature that matched users to games that could be swiped right or left, like how a dating app functions.

Product Backlog

Completing a product backlog helped our team understand how to analyze our assumptions and implement the appropriate solutions to users’ problems. We conducted an affinity mapping exercise, in which each team wrote down their assumptions on sticky notes in order to fill in the template below. We then shared our sticky notes and organized them by category. By doing this, we were able to organize our thoughts into business outcomes, proto personas, user outcomes, and features. This helped us understand how our assumptions related to each other and how we would address the user’s problems with our app’s features.

Proto Personas

We created two proto personas who represented what we assumed the users would be like: a frequent gamer and a casual gamer. We worked together to figure out who these users were, what problems they were having, and how our app fit into their daily life. These proto personas helped us begin to build our app based on our initial assumptions, but they would change when we returned to revalidate them after user interviews.

Sprint Backlog

Finally, we used our proto personas to analyze the product backlog. This helped us decide which outcomes were most important and necessary to the user’s needs and select which features to complete during Sprint 1. In Lean UX, you tackle the biggest problems first because they are the most significant to the user. We concluded that accurate recommendations and information on new games was most important to our users, so we picked these features for our Sprint 1 backlog: game profiles, matching users to new games, a tag/filter system, and a game catalog.

Sprint 1: Week One

This week consisted of building the structure of the most important features of our app: game profiles, matching, tag filters, and a catalog. We constructed our assigned wireframes separately and conducted two interviews as a team. 15 minute stand-up meetings were held every two days to discuss the work we completed and maintain a shared understanding of our progress. These stand-up meetings continued for every Week One & Two of each sprint.

Low-fidelity Wireframing

Our most important functions were individually assigned to each team member in order to construct low-fidelity wireframes that would serve as the basic structure for each page. Our team’s frequent communication and shared understanding allowed us to complete this clearly and efficiently.

User Interviews

User interviews were conducted as a team over voice calls in order to follow COVID-19 social distancing guidelines. When each interview was completed, we started affinity mapping on Miro. This exercise ensured that every team member was able to share what they learned from the interview, and how all of our thoughts related to each other and benefitted our process. Every future interview session included affinity mapping for this purpose as well.

One of our first affinity maps. All of our thoughts were placed into categories about the participant’s gaming habits, needs, and obstacles finding new games.

Our first two participants happened to represent the two types of gamers we assumed would be users: frequent and casual. Thanks to their differing perspectives, we were able to learn what specific information or features our app needed in order to satisfy both of their needs, including a filter for consoles and a review feature.

Sprint 1: Week Two

We began medium-fidelity prototyping in Figma by using our low-fidelity wireframes as a basic structure. We continued to work on our assigned features and functions individually and researched specific games for their own profiles. A rough idea of the matching algorithm was created to better understand our tag/filter system. Two more interviews were conducted as a group as we wrapped up building the most necessary features of our app.

Prototyping

Using our wireframes from the previous week, we began medium-fidelity prototyping in Figma individually. Each team member chose three games to research in order to complete nine game profiles and matching cards. This is where we began to establish the visual design of our app as well, in which we chose a color scheme that was similar to other game-related apps. Erica learned how to mimic the swiping animations seen in dating apps for our matching page, and with that we had finished everything in our sprint backlog for Sprint 1. We had implemented what was necessary for now, and the interface of some pages would be altered in Sprint 2.

Sprint 1 Game profile

User Interviews

Our two interviews for this week were both casual or new gamers, so we began to learn how much more these types of gamers would benefit from our app than a more frequent gamer would. With their feedback, we learned some more useful features that would help our users navigate our app and buy new games. This included a brief tutorial for swiping on the matching page and a link to purchase a game on the profile. These would be implemented in the next sprint.

Sprint 2: Week Zero

In a retrospective meeting, our team discussed our progress in Sprint 1 and what we learned from our interviews. We agreed that we needed to analyze our interviews more deeply and improve the interface of the prototype, and because of this we discovered a few changes that had to be made during Week Zero. This included making changes to our personas and drafting new interface designs to be used in usability testing later in the sprint. We also decided on the official name for our app at this time: Game Genie.

Revalidating Personas

After discussing our user interviews in Sprint 1, we learned that casual gamers were our primary users, and that we had a new type of user to take into consideration: users who were completely new to playing games. Our proto personas were changed to reflect this. Jared became our primary persona, Madelyn became a secondary persona, and our new tertiary persona was created to represent our new user, Josh.