UX Research and Design

I have a passion for seeing people enjoy using something I create, which is why I got into game design. I discovered this passion could apply to UX design in my first UX class at DigiPen. Since then, I've taken several classes and an independent study relating to UX, and I've specialized in both UX research and design. I've also worked as a Teaching Assistant for "UX Design 1" and "User Research and Testing." I have experience with playtesting, tutorialization, feedback, information architecture, personas, mindmapping, prototyping, and virtually all areas of UX that can be applied to games.



Summary of Experience

  • "UX Design 1" Teaching Assistant at DigiPen Institute of Technology

  • "User Research and Testing" Teaching Assistant at DigiPen Institute of Technology

  • UX Researcher on 3D Networked Multiplayer Action-Stealth Game (Night Heist)

  • UX Designer on an independent mobile game for Android (Unnamed project)

  • User Researcher on a 2D Co-Op Platformer (Shortstack)

  • UX Designer on Mobile UI Prototype (HeartBreaker)

  • BA in Game Design, Minor in Psychology, Graduating December 2019


 

Night Heist: UX Research (in progress)

UX Researcher, Project Manager

Sept 2018 - Present

Unreal Engine 4

21 Person Team

While on Night Heist, I've tested our game and created a writeup for every project milestone. This has meant creating many surveys, writing scripts, and conducting playtest after playtest to gather data. Next, I analyze and compile that data into writeups. The first pages are all for documentation and methodology, whereas the last few pages are results and actionable data that I discuss with the design lead so that we can create tasks on our scrum board, including bugs, balance changes, etc.

 

Night Heist: Process (in progress)

I'm a very goal-oriented person, so my process always begins with a goal. The goal of testing is to answer questions the team has and to gather data about how to improve the game. The writeups I do aren't graded, so they're done with the specific purpose of helping the team out, which allows me a lot of freedom to work. As backstory, the game I'm drawing examples from is a 3D multiplayer action-stealth game where thieves try to steal artifacts from a museum, and guards try to stop them.


1. Consulting the Team

I start my process by seeing if the other developers have any questions they want to be answered about our game. An example of this in our current game might be "which character is more fun to play as, thieves or guards?" It's important to write everything down, as sometimes I'll hear questions that would better be answered at a later date. For example, if we're reworking how movement works, we wouldn't want to ask the question "Does movement feel responsive?" as that question is more useful once the rework is complete.


2. Operational Definitions

Once I have the questions the team wants to be answered, I have to operationally define terms. For example, if the question is "Which abilities are the strongest, and which are the weakest?" I have to operationally define "strength." Is it the number of times players use an ability? Is it some correlation between use of the ability and winning? It might be a combination of multiple things, but it's important to look at the data from multiple angles to see if anything needs to be adjusted. For example, if any abilities are almost never used, we want to explore why that is, and possibly try to change it by increasing the effectiveness of the ability or something similar.


3. Creating the Testing Instrument 

Once I have all of my questions and operational definitions, I need to create the testing instrument. My testing instruments usually consist of a simple script, pre-test survey, and post-test survey. The goal of the pre-test survey is to collect basic demographic data and try to account for bias, which is especially important because I typically use a convenience sample. The goal of the post-test survey is highly variable, but it always aims to gather data on certain aspects of the experience. I also make a form for myself to fill out during the test to gather observational data, such as the number of deaths per player. The screen of the player is typically recorded, and occasionally we might record player facial expressions in the future if given consent.


4. Testing

I normally conduct these tests with an assistant to make my life easier, as our game requires 4 players to be playing simultaneously. The testing process begins with a convenience sample, because DigiPen, unfortunately, has nothing close to a human subjects pool. I read from the script and administer the pre-test survey, then I explain anything we need to explain about the game. The players sometimes have a few minutes to play around with the controls and explore the map, then the actual test begins. Players play the game in teams across the room from each other while we observe their play and reactions.  I record anything noteworthy using the form I create for myself in the previous step. Finally, I ask players to fill out a post-test survey, ensure the test didn't cause any sort of serious stress (debriefing), and send them on their way.


5. Results, Analysis, Write-Up

After the testing is done, I analyze the results and create a write-up for my team. Some of this write-up is documentation for our future selves, but the primary focus is providing actionable data. I start by using the data to answer any questions asked by the team, then I move on to other things we could improve. This is what I mean by actionable data, an example of this was "Guard mobility: We might consider giving the guards increased options for mobility, unless the design team wants the contrast in mobility with the thief to be as significant as it
currently is. Either way, the guard currently seems to feel clunky, so we might want to work with the camera and character controller to improve the gamefeel." This is how I usually try to keep things, I might propose a solution, but I try to leave that up to the appropriate department. I always discuss individual problems more carefully with the individuals that would be responsible for solving them, but this is a great example of a problem we are working on solving. The players repeatedly described the guard as "clunky" and "too slow" when asked about them, so we've been working to make them feel large and powerful instead of slow and clunky, as the lack of speed is an intentional design decision. However, now players feel like they're a powerful behemoth, so they rarely complain about the lack of mobility.

If you have any questions or criticisms, feel free to contact me, I'm always looking to improve wherever I can!

 

Proton: UX Design (in progress)

Solo Developer

Jan 2019 - Present

Unity

Proton is a solo-project mobile game with the guidance of a professor at DigiPen. The purpose of the project is to learn the skills to design and create mobile games with a focus on UX. The game is based on another popular minimalist infinite runner, but I've been working on enhancing the UX through feedback and guidance, as well as expanding on the simple and addicting mechanic and creating intuitive UI.

 

Shortstack: UX Research

Entered into PAX10 by DigiPen

Showcased at PAX West by DigiPen

UX Researcher, Level Designer, Associate Producer

Jan - Apr 2018

Custom Engine (C++)

8 Person Team

While on Shortstack I got the opportunity to work in a custom game engine written in C++, and I was able to test both the game and the engine to improve the UX of both. I conducted expert tests with design professors and more traditional playtesting.