Helping first-time users of Playstation VR fully enjoy Rick and Morty: Virtual Rick-ality (RMVR) on their home systems.

Users had high expectations of the title due to the success of its release on Steam for PC.
‍

PSVR hardware imposed significant limitations on the game's tracking and overall performance.

Adult Swim Games was without a Product Manager while I was Quality Assurance Lead on this title. I filled this gap by gathering user-centered feedback from the QA team to present to developers in the form of issues and design implications.

Through a combination of think-aloud cognitive walkthroughs, contextual inquiry, semi-structured interviews, and research of player comments online, I identified several problems that users were likely to encounter in the title. From these problems, I developed design recommendations that I then presented to the developers at Owlchemy Labs.

The title should orient players with a first time user experience. This FTUE took the shape of a tutorial that situated players in the universe, calibrated players' devices, and helped familiarize players with the game's controls, mechanics, and progression system.

The title should allow players to turn around in game space without needing to turn themselves around in real life. This lead to snap rotation being implemented in the PSVR version of the title: one button rotates a player's view 45 degrees to the left, while another rotates it to the right.

The title should allow players to adjust their height quickly and natively, without needing to adjust their height in the PSVR system software. This was implemented as a height calibration menu flow that players may access from any place, at any time.

The title should allow players to perform height calibration without a dedicated menu flow. This was implemented in the form of two buttons that may be pressed to immediately increase or decrease a player's height in the game.

Empowering persons with mobility impairments to research and engage with local parks.

This project was completed during the Fall of 2020, during the COVID-19 pandemic. All user studies were conducted remotely to ensure safe social distancing, with the exception of an observation study in which team members went to local parks to conduct socially-distant research. This introduced interesting opportunities and complications to the project.
‍

Prior to this project, all team members were unfamiliar with the social and physical caveats of working with members of the motor-impaired community. This project proved to be an excellent learning and empathy-building exercise, and all team members are now comfortable and passionate when working with this vulnerable audience.
‍

While existing widespread navigation tools feature some accessibility settings, the accessibility information on these platforms lacks depth. Also, accessibility-oriented trail databases lack the breadth of data featured by widespread navigation tools. How do we satisfy both of these requirements?

Prior to designing and iterating on possible solutions for this problem space, we performed six research activities. These included:
‍

I. A survey distributed to the 75 members of a support group for individuals who survived traumatic spinal cord injuries.

II. Observation of individuals at public parks during which we counted the number of people with motor impairments at those parks, as well as difficulties these individuals may have encountered navigating through these parks.

III. Unstructured interviews with members of, and experts on, the motor-impaired community and their experience engaging with the great outdoors.

IV. Affinity mapping exercises through which we hierarchically organized stakeholder remarks on the problem space and determined user needs.

V. Personas and empathy maps distilled from identified user needs and remarks to better understand and build for the end users of our product.

VI. Journey maps that provided the team with explicit user stories that our product might be used as an intervention to improve.
‍

From the above research activities, our team collaboratively identified eleven high-level findings, several of which we determined were particularly important to understanding our stakeholders, and ultimately the success of the project. Below are the four critically-important research findings:

I. Users want more engagement with natural parks. Therefore, our solution should enable users to engage with natural parks more frequently than they currently do without our solution.

II. Users want nature to be as unaltered as possible, but many accessibility solutions involve the physical alteration of that nature. Therefore, our solution should avoid physically altering nature wherever possible.

III. Users value collaboration. Therefore, a crowdsourced data model would likely be effective for the case of our solution.

IV. Users value independence. Therefore, our solution should assume an ethos that focuses on empowering users rather than helping them accomplish tasks.

Show what factors influence the accessibility rating each time it appears.

The 2D interface should be designed with mobile devices in mind, if not specifically for mobile devices.

Users should be able to customize what warnings they see.

Convey the surface material of trails to users, such as whether they are paved, gravel, or grassy.

Reduce the amount of information present on the watch face so that users are able to more easily interpret it.

Refine visual design for clarity, and confirm this clarity with further user feedback sessions.

The platform should rely less on color to convey information, and the interface should be designed with colorblind users in mind.

The platform should allow for multiple forms of input, such as voice and gesture interactions. This will allow more of our stakeholders to seamlessly interact with the platform.

The system should dynamically suggest parks to users based on pre-existing knowledge of the user's abilities. This could be done by syncing with an account that the user has in an app within this platform's ecosystem.

The platform should not ask users whether they want a tailored experience too frequently or immediately after the FTUE, but it should allow users to opt into a personalized experience at any point.

From the wireframe feedback sessions and previous research findings, we distilled feedback from users into four design recommendations for the final design of our platform. These design recommendations indicated that the current iteration of the Spatial platform was a more effective solution than the smart watch app in the problem space. Due to the structure of the course this project was for, the team decided to only move forward with this Spatial prototype. The four design recommendations are below:
‍

I. Allow users to customize which UI elements they are shown in any platform moving forward.

II. Offer hands-free input wherever possible, and do not require tactile input as a prerequisite to verbal input.

III. Prompt the user with output across multiple sensory channels to better alert them of upcoming hazards or prompt them for feedback.

IV. Make iconography as simple as possible, free of potentially-ableist imagery, and without text wherever possible.

I. Involve more users. There is so much diversity within our stakeholder audience, that our team feels as though we weren't able to fully capture the needs of our users, or their sentiment toward our product. This is due largely in part to the difficulties imposed by COVID-19, the size of our user population, and the tight 4-month schedule this project was operated on.
‍

II. Park alteration research. While we learned that users were generally opposed to park features that they felt worsened their experience in nature, we did not learn much nuance about where this sentiment was coming from, or how we might circumvent this user need while making physical changes to parks.
‍

III. Iterate. The iterative process of this project was greatly helpful to its rapid growth and likely success at fulfilling its purpose, but given more time, I would like to keep iterating on this project until users indicate that it is ready to be released into the wild.
‍

IV. Business model. If the team were to continue this project into the future, we would need to establish an effective business model to keep the project afloat for the foreseeable future.
‍

V. Establish audience. Users are just as important as functionality when it comes to the success of a platform. If this project were to be implemented and published, we would need to establish a group of users for the platform to maximize its chances of success in the real world.
‍

VI. Implement and publish. With all of the previous steps taken care of, we would need to finalize the platform's functionality and polish, then publish it to the appropriate platforms. Depending on the business model of the platform, this would likely be followed by a live ops plan.
‍

Making a third-person platformer that feels great to play.

With very little prior experience in Blender and Unity, I decided to independently create this third-person platformer as a personal project during the summer between my undergraduate and graduate studies.
‍

During development, I actively implemented mechanics and graphical features that build toward the "feel" of the game, such as procedural animation, jump fine-tuning, inverse kinematics, physics animation, and tight controls.
‍‍

Early development involved plenty of experimentation with the mechanics that go into making a 3D platformer feel good. To accomplish this, I modeled and animated an ermine character that I could use to navigate through an environment. With this character implemented, I rapidly prototyped and fine-tuned numerous features that are often present in platformers that users often don't think about, Including:
‍
I. Character model procedurally tilts toward direction of acceleration.
‍
II. Character acceleration and deceleration fine-tuned to feel as though the character has weight, but is easily controlled and stopped on a dime.

III. The character jumps higher when the jump button is held, and falls faster when it is not.

IV. The player may make the character sprint, crouch, and slide, each of which affects the animations, speed, and movement behavior of the character.
‍
V. Jump/fall animations are procedurally combined based on vertical velocity of character while airborne

VI. The character "sticks" to the ground when walking or running downhill, but falls as expected according to gravity when running off of an edge.

VII. If the player tries to jump immediately after falling off of an edge, they are still able to jump, allowing users to better control the character and recover from mistakes.

VIII. The character's feet "stick" to the ground with a hand-implemented inverse kinematics algorithm.

IX. The character's scarf hangs behind them and is physics-animated, behaving as though it were physically a real scarf.

X. The camera is fine-tuned to smoothly follow the character, pivot around the character, and not intersect with terrain via a ray-casting script.

XI. The character's object lives inside of a squash & stretch controller, which makes the character's movement appear dynamic and fluid.

First, I would like to fully implement combat and puzzles to bring a more engaging experience to the project. This would include weapon and enemy animations, behavior, AI, and additional mechanics.
‍

Second, I would like to further build out a compelling environment for the player to not only navigate through, but meaningfully engage with. I would like to accomplish this with small-scale procedural interactions and animations that would afford the player a greater degree of agency in the world.
‍

Third, I would like to further develop the project's narrative to provide the player with a reason to exercise their agency in the game.

Optimizing and polishing a VR meditation tool in a fast-paced startup environment.

Before the inception of the startup Satori Studios, ZenVR was the Master's project of Rachel Feinberg and Matt Golino, two now-graduates from Georgia Tech's MS HCI program.
‍

While Matt and Rachel had designed and implemented the title, it had numerous graphical, functional, and performance issues. Matt knew that I had experience in Unity and Blender, so he invited me aboard to optimize and polish the title.
‍

The team was well aware of several of these issues, but they had not tracked them in an organized database. I took on the task of logging and tracking known issues with Trello during my time with the team.
‍

Through a combination of functionality and exploratory testing, I was able to identify several issues, each of which had a clear correspoding solution.

I retopologized and UV unwrapped the meshes of all assets that were unnecessarily complex, and I ensured that the remaining meshes were low-poly enough to run smoothly on the Oculus Quest. This vastly improved the performance of the title with no discernable difference in graphical quality.

I combined the materials of assets into large complex materials that contained the textures of many meshes. Through this method, I was able to reduce the number of materials in the project's environment from 40 to 2. Similar to the previous solution, this improved performance with no significant hit to the title's graphical quality.

I configured the Unity project to use Unity's Universal Rendering Pipeline, this time improving both performance and graphical quality.