The above images are photos taken from one participant's user-value ranking session. Some project topics, such as training and healthcare, were interesting but not needed. Some project topics, such as exhibit design and guest engagement, were fairly needed but not interesting. And some project spaces, such as passive health tracking and spatial enrichment, were both fairly interesting and needed in this trainer's opinion.

I then normalized these findings on a scale from 0 to 1 for each trainer, and averaged those results in the below graphs.

I generated graphs with the averages of each participant's responses normalized between 0 and 1 to better understand how trainers and curators felt about each project space. Based on the lowest graph above, passive health tracking and spatial enrichment were both the most interesting and most potentially beneficial to the sea otters of all of the projects proposed.

To gain a better understanding of what sea otters perceive as signifiers and affordances within the context of enrichment devices, and to inform the design of future high-fidelity prototypes, I designed, built, and tested four low-fidelity prototypes for the five sea otters to play with across two sessions for a total of 40 trials. These devices were unique in that they were all novel to the animals, they all had food secured in them in different ways, and they all required modes of interaction rather than smashing or biting to retrieve food.

The above four images are the four low-fidelity prototypes that I used to identify how sea otters understand and interact with toys. These prototypes were an orange toy with a slit that could be opened by pressing, a white open toy that food could be retrieved from by grabbing, a white closed toy that needed to be unscrewed to be opened, and a kelp toy with food tied in a square knot at the end of a piece of car wash felt tied to a jolly ball. In these usability testing sessions, otters were presented with a toy stuffed with food. Sessions were timed and recorded, and certain key moments during these sessions were marked and visualized: first touch (when the otter first touched the toy), first food (when the otter first begins retrieving food from the toy), last food (when the otter stops getting food from the toy or the toy no longer has food in it), and last touch (when the otter stops touching the toy).

From the above low-fidelity prototype testing sessions, I derived eight key takeaways:

I. The kelp toy was most effective at soliciting interactions from the sea otters, but that is not necessarily indicative of the prototype being most effective for health tracking, as ideally the sea otters will want to give the toy back to trainers in exchange for food. Furthermore, the kelp toy would by far be the most complex to instrument with computational elements and maintain for prolonged use by a nontechnical audience without the regular intervention of technical experts. Therefore, this design would not be effective in the long run.

II. Gibson and Mara were anxious about new enrichment devices, but they gradually warmed up to the kelp toy across the two different sessions. In combination with feedback from trainers that these two sea otters were the youngest and could do with desensitization to new enrichment devices, we can assume that they would similarly warm up to other new enrichment devices over time.

III. None of the otters were able to retreive all of the food from the orange toy. While all but one of them were able to retreive some amount of food from it, they did not learn during the 40 sessions how to press the toy to empty it of all of its held food. The sea otters also did not exhibit any measurable banging, smashing, or biting behaviors on the toy; therefore, similar to the kelp toy, this design would not be effective in the long run.

IV. The white open toy was the quickest for the sea otters to interact with, and they were able to retreive the food from it with relatively little difficulty. However, similar to the orange toy, they did not exhibit any measurable smashing, banging, or biting interactions on the toy, so this would not be effective in the long run.

V. The white closed toy solicited the most measurable behaviors from the sea otters (smashing, banging, biting, grabbing), but Gibson, Mara, and Brighton were somewhat nervous around the toy and did not exhibit many interactions. Since the otters warm up to new enrichment devices over time, and since this device encouraged otters to exhibit the most measurable behaviors, I designed future prototypes with this mode of interaction in mind.

VI. Otters assume food will be in the center of mass of a toy. When given the kelp prototype, they all began to search for food by looking at the jolly ball rather than the square knot of kelp containing food. Therefore, the final prototype should have food in its center.

VII. Otters look to any openings in toys for food first. When looking at toys, they will aim to spend as little energy as possible retreiving food from it, which often means reaching into any openings in the toy to search for food. Therefore, the final prototype should have some opening in it that is large enough to visibly indicate the presence of food, but small enough for otters to not be able to simply reach in and grab the food. Alternatively, the final prototype could be designed to be packed densely with snow to form a plug, preventing otters from just reaching in and grabbing the food.

VIII. If an otter thinks food is in something but cannot see that food, it will attempt to smash it open. This occurred with all of the prototypes except for the white open toy. Therefore, the final prototype should be designed in such a way that signifies the presence of food to the otters, but does not have food immediately ready for the taking. The prior point of stuffing the toy with food and snow to form a plug would be an effective means of accomplishing this.

First, I sketched out several potential layouts for an otter view screen. This would show a user details on an otter's most recent interactions on a toy, as well as more detailed information on a particular otter. This screen would not show in-depth information on the otter's most recent interaction, and a user would not be able to report health anomolies from this screen. The screen was designed with both landscape and portrait possibilities in mind. Ultimately sketch A most informed the layout of the final prototype.

Second, I sketched out several wireframes for an event view screen. This screen would show a user all of the details of an otter's most recent interaction on a toy down to time, local extrema, sum of an interaction, difference from last interaction, and difference from average interaction. The line graph showing the difference between an otter's latest and average interaction on a toy in sketch B most informed the design of a similar graph in the final prototype.

Third, I mocked up a report view screen. From this screen, a user would be able to send data and related questionairre-style information or photos to management and veterinary staff. Sketch D from this phase of wireframing most informed the "contact vet" user flow of the final prototype.

Next, I realized that the most functional approach to this dashboard would not require a user to navigate between different tabs for different degrees of functionality: all of the information a user might want on an otter should be presented to them at a glance, and they should be able to access any information on other otters with at most one tap on the screen. To best meet my audience's wants and needs, I designed a landscape-style dashboard that constantly displays an otter's health information, latest data, average data, and whether or not that otter might have a health concern to viewers. From this multifunctional tab-based overview, a user can see all information on an otter or tap on another otter's tab to view all information on that otter. From any otter's page, a user can access the platform's settings or contact vet staff.

The above image shows the first interactive prototype of the dashboard, built in Figma, running on an iPad Pro 12.9". The prototype displays all information that trainers indicated would be useful (name, species, age, weight, sex, health history, medication) on a given otter, shows an otter's latest interaction and average interaction with the instrumented toy, shows an AI-generated summary on the otter's health, shows all otters as interactive openable tabs, and allows users to open settings or contact vet staff at a moment's notice.

From the four trainers and four UX pros interviewed, I generated the below chart depicting average responses with action items for SUS criteria most in need of intervention.

From the above results, I generated the four most-needed interventions to improve the design of the dashboard, shown below in Wireframe Issues.

By taking all of the above stakeholder feedback into account, the dashboard design is now in a state where it is ready to be implemented. This task is currently being taken on by a rising 2nd-year MS HCI student as a part of his Master's project.

While the above design affords the desired interactions from sea otters, can hold food, and contains computational elements, this first instrumented prototype needed to be redesigned for several reasons. The below image shows a whiteboarding session I had with a physical prototyping instructor of mine, Noah Posner, on how to effectively redesign the toy to meet all of my design requirements.

During our discussion on the shortcomings of this first instrumented prototype, we discussed the need to use a different material, the need to use sufficient datalogging internals, and the need for a housing redesigned specifically for machining and waterproofing the electronics.

All of the components that I were modeled in SOLIDWORKS, and each variety of component was manufactured in its own unique way. For the UHMW components, I generated drawings that I then sent to a machine shop to be made by hand, a process that I helped out with. For the electronics package, I generated STL files and 3D printed those files with a ProJet 3510 HD in Georgia Tech's Prototyping Lab. For the gaskets, I generated an AI file to be imported to Cricut's software, which I then used to cut the components from 3mm rubber and 6mm silicone. For the circuitry, I ordered components from Adafruit.com!

The first image above depicts the base of the electronics housing when I first incorporated captive nuts into the design to allow for fine-tuning of gasket pressure. The second image above depicts the exterior of the UHMW shell when it was first machined.

While implementing the IMU datalogging functionality of the device, I decided to allow a user to select specific otters before beginning trials with the device. This information, as well as whether the device is currently active, is displayed to the user through the onboard OLED display. To save battery life and improve SD card longevity, I implemented an algorithm to write up to 16 datapoints to flash memory at a time before saving those datapoints as one bucket to the end of a CSV file aboard the SD card.

Before handing the toy to the otters, we would fill it with some food and pack it densely with ice to form a plug near the lipped top of the toy. This ice formed a plug that the otters could only open by smashing the toy against something.

Above, Brighton is smashing the food-stuffed toy against the ground to break the ice seal and get the food inside. This smashing behavior is exactly what we want to measure and log with on-board computational elements. These early trials with the high-fidelity prototype taught us that the toy's electronics package was totally water-tight, and that the otters would not try to bite the toy apart. Success! Next, we placed computational elements inside of the toy and tested the device with three of the otters, since two of them were off habitat due to some recent habitat renovations.

Above are several visualizations of Gibson's interactions with the toy. To my knowledge, this is the first ever instance of marine mammal behavior being measured with an instrumented toy. The bottom graph is segmented into several sections based on what is going on with the toy at a given point in time. We turn the toy on, close it, stuff it with food, set it down, let Gibson interact with it, and then we open it up. Unfortunately, gibson did not pick up and smash the toy like we had hoped since he was anxious about the new object. Fortunately though, he did briefly bump against the toy around the 400 second mark of the above trial when he plucked a piece of shrimp from the top of the toy.

We repeated the process that we did with Gibson with the other two otters in the habitat, Mara and Brighton. The lines in the above graph all start at the point during which the otters first interact with the toy, and we can already visually tell what the otters were doing to the toys. Gibson was anxious and barely touched the toy, Mara enthusiastically shook the toy and got all of the food out of it within about 140 seconds, and Brighton shook the toy so enthusiastically that the SD card came unplugged at roughly 30 seconds. Future iterations of the electronics package will take this into account and will not allow the SD card to come loose during testing. Until then, the SD card will be taped into place to ensure that it does not come unplugged. By repeating this process longitudinally for each otter, we might be able to quantify a baseline in behavior for each otter at the Georgia Aquarium and identify anomalies in that behavior to identify health concerns before they become visible to the naked eye.

The green "stickies" above show the four high-level takeaways from the affinity mapping exercise: users enjoyed connecting with others, being independent, appreciating nature, and overcoming the limited accessibility features present in the space.

The above journey map shows the actions one of our personas might take to go on a walk somewhere new, as well as his emotional state as he travels along that journey.

The above sketches are for the team's Spatial prototype, mocked up by Christian Gutierrez and Matt Rossman. This platform would allow users to research parks and trails online from their desktops, then view live alerts while engaging with those trails and parks. The team evaluated this interface by performing user- and expert-involved cognitive walkthroughs and heuristic evaluations.

The above sketches are of the team's smartwatch app prototype, illustrated by team mate Lucy Chen. The tool would notify users of upcoming hazards in a trail and prompt them to confirm whether or not the specified hazard was present in the trail. Additionally, users would be able to report issues encountered on the trail that would then be shown to other users. Like the last interface, we evaluated this smartwatch prototype by performing user- and expert-involved cognitive walkthroughs and heuristic evaluations.

The above two flow charts depict conversation flows in the team's third prototype, a voice assistant app made for identifying accessible parks and trails. I created these simulated conversation flows with draw.io. In keeping with the other sketches, we evaluated this interaction mockup by performing user- and expert-involved cognitive walkthroughs and heuristic evaluations.

After taking the sketch feedback into consideration, we rebuilt the Spatial prototype's wireframes using Figma and theasys.io, two online prototyping tools. Similar to the last round of prototypes, all wireframes at this phase were evaluated with user- and expert-involved cognitive walkthroughs and heuristic evaluations.

The smartwatch prototype interface was also rebuilt in Figma, featuring two menu flows in which the user would be prompted to respond to an upcoming trail hazard, and report a trail hazard.

The final prototype of the spatial platform's mobile touchpoint was redesigned from the ground up in Figma, and the theasys.io AR prototype was iterated on with imagery that was deemed more informative, more accessible, and generally more effective by expert and user study participants alike.

The Mobile platform prototype and AR prototype are both viewable online.

I performed multiple contextual inquiry sessions with users. These consisted of task-based cognitive walkthroughs during which participants were asked to think aloud about the actions they wanted to take in the game. I followed these sessions with semi-structured interviews concerning the design elements and bugs encountered during the tasks of the earlier cognitive walkthroughs. The interviews were also helpful for gaining feedback on general user sentiment around the title, both positive and negative.

The original height adjust menu prompted players to assume a T-pose in front of the Playstation Move camera. This proved bothersome and time-consuming to most participants. To alleviate this frustration, the triangle and circle buttons were configured to increase and decrease the in-game height of players. Users reacted positively to this change both during testing and in online reviews.

While snap-rotation and quick height adjust controls were not available on launch, they were added to the game in the launch of version 1.1, resulting in improved gameplay and user reviews. These changes empowered users to play the game with fewer technical errors, likely resulting in fewer low points along their journeys to completing the game.

Like many of my projects, this one started with an idea: what if I tried to make the most of the time between semesters by having some fun in Blender and Unity? Little did I know that these humble beginnings would lead to a huge undertaking in the form of the most complicated game I've independently developed to date.

I knew that I wanted the game to have a laidback, Pacific Northwest inspired environment due to my interest in the area. Furthermore, I was inspired by a GDC talk on the procedural animation in Overgrowth, and I was determined to try it myself. To start, I mocked up the above animation state machine with pencil and paper.

Next, I wanted to establish a development schedule. I once again looked to the GDC talk on the procedural animation in Overgrowth to provide myself with a challenging, but achievable, order of operations.

I even created a color palette that I would use to drive the visual design of the project moving forward. Taking inspiration from The Pathless, I wanted the game to be full of subtle blues, greens, grays, and browns, with the occasional flash of red to draw the player's eye.

Environment design proved an interesting challenge that I'd never encountered in an industry setting before, so I took my time when mocking up and planning assets to use throughout my Unity game.

From the sketches above, I created several 2D assets for the game's foliage: pine needles, leaves, flowers, and grass were the first of many environment assets to come.

Next came sketches of rocks, and eventually 3D models that I would dot the landscape with. The texture of these rocks was hand-painted with acrylic, and scanned into my computer, and further painted in Blender for what I thought was an interesting visual effect.

Having some environment assets complete and a character model ready for a game engine, I designed and implemented many of the intended aesthetics, dynamics, and mechanics of the project in Unity. Alternating between feedback-gathering and feature-refining proved an effective exercise in iterative game design.

Later in development, I decided that it was time for a visual overhaul to the main character. I also decided that it was time to give him some tools through which he could interact with the world, affording players a greater degree of agency. Weapons are a popular way to accomplish this in games, as well as an interesting area to explore with game feel in mind, so i decided to give him a sword and bow.

I plan to implement an animation in which the character shakes one weapon in the air and it transforms into the other weapon. The metallic ball at the center would function as a unique magical tool that the player can use to pick up elemental charges from enemies or the environment, then later solve puzzles with. This is where narrative development comes in.

The character is fully rigged with inverse kinematics and shape keys for clothing-wearing, facial expressions, and speech.

ZenVR takes place inside of a dojo, in which Wei, your Shifu, guides you through eight lessons on how to effectively meditate on your own. Before optimizing, many of the assets inside of the dojo were unnecessarily detailed. For instance, the pillows on the floor of the room each contained about 2000 vertices. Through some clever retopology, these were brought down to about 40 vertices each.

The assets inside of the dojo, and some of the architecture of the dojo itself, was also due for material optimization. To accomplish this, I combined the texture and normal maps of each asset in Photoshop CC, then remapped the UV unwraps of each asset onto the corresponding texture and normal maps of this new material. Pictured above is the result of combining 16 materials into just one.

The outside of the dojo features mountainous terrain, trees, a Shinto shrine, and the building itself. Similar to the assets inside of the building, the meshes of these assets featured unnecessarily high vertex counts and many materials.

Above are the results of an optimization process similar to that applied to the assets inside of the dojo. During this round of optimizations, I combined 24 materials into one.