Hootie Puff


Games are rich territory for designers. The challenge of crafting a compelling narrative, beautiful visuals, and interesting gameplay is one I would be happy to explore many times over. 

This story illustrates how my partner and I designed and developed a mobile side-scrolling game called Hootie Puff in a user-centered way.



My partner and I were tasked with creating a mobile game in a tight deadline. The game had to be designed, developed, and accepted onto the iOS and Android app stores within 12 weeks.


We created a mobile side-scrolling game called Hootie Puff. The game featured set goals and levels to appeal to the casual gamer. With each level advance, we hoped players would feel satisfied and accomplished, yet challenged enough to continue playing.


Our game, Hootie Puff, is available to download for free on Google Play and iTunes. Our feedback from users thus far has been positive.


I led the UX and motion design efforts, and my partner Grace Tooher created the music and sounds. We both owned the visual design, animation, and development of the game. We took on this project as part of our Creative Digital Media master’s degree at the Dublin Institute of Technology.



Producing a game is an interesting challenge in narrative and design. The market is already saturated with casual games—more than 260,000 existed on the iOS app store alone at the time of our project. We set out to create a game that was a cut above the rest. Specifically, we focused on crafting a compelling narrative, producing great visuals, refining the interactions, and delivering a sound user experience. We aimed to not only design an enjoyable game that we would like to play, but one that truly resonated with users.

Understanding the Domain

What Makes a Game Fun?  

I conducted initial research on industry trends and mobile games, specifically side-scrolling platform games like Super Mario and Flappy Bird. I reviewed competing games and apps, and analyzed their main mechanics and flow. My findings showed that platform games have remained popular since the 1980s. Mobile devices, which typically have smaller screens and allow for fewer controls, are particularly well suited for these types of games.



User Interviews

Together Grace and I conducted a handful of user interviews to learn about people’s game-playing behavior. During our sessions, we asked users to show us their favorite mobile games. We asked open-ended questions to learn more about what made these games enjoyable, such as, “What do you find challenging about this game? How do you feel after playing? How intuitive are the controls?” We observed them carefully and took note of how long they played, the context in which they played, and how many times they played a given game.

These are the key insights that guided our product:

First, users enjoy games with specific goals. Games like Flappy Bird, in which a player guides a bird between pipes indefinitely, are addictive at first, but ultimately frustrate users. 

Design Solution:  Our game features set levels and goals. With each level advance, we hoped players would feel satisfied and accomplished, yet challenged enough to continue playing.

Second, users like to explore a world. They meander in a game scene and do not necessarily zoom toward the finish line.

Design Solution:  This led us to rely on a non-scrolling background (as opposed to a persistent forward-leaning camera pan) in our game. Users also have the option to pursue two separate objectives—collecting shrimp for a high score or racing to the end to complete the level.

The Initial Concept

After completing our user and domain research, we solidified our initial concept of Hootie Puff. 

Here’s how it works: Users must maneuver Hootie the pufferfish along the ocean floor and dodge perils like sharks, squids, and underwater volcanoes by floating above or under them. If Hootie collides with adversaries, he blows up in shock.

User Flow

Next, I modeled a user’s flow through the game by creating a user flow diagram and storyboards of the various screens. 

The user flow turned out to be quite simple. Basically, users could start a game, exit a game, view instructions, and view high scores. The more interesting interactions occurred within the actual gameplay, which I will cover in more detail later on.


Rough sketch of user flow


Wireframes and Prototypes

At this point, we began to sketch the game interface. I usually create wireframes that are clearly low-fidelity or high-fidelity, so users know what to expect and how to interact with them. With Hootie Puff, though, I explored a middle ground approach that combined wireframed elements with actual assets. Since Grace and I were designing in tandem, it was important that we see all the assets in one spot to ensure that their placements and styles worked well together.

Because we were responsible for development, actually making a version of Hootie Puff in GameSalad was the easiest way to prototype it. Once the game was in code, we could better tailor our visual assets. For instance, we gave users an incentive to keep Hootie small by adjusting the platform levels in a way that gives preference to Hootie at his smallest size, which we could only do with the true pixel count. 


Design, Test, Iterate

We created a minimum viable product within two weeks. We continued to build iteratively throughout the rest of the project.

We tested the game with more than 30 users throughout the development period. We conducted usability testing to gauge specific tasks, such as “start the game,” “find the high scores,” and “win the game.” We also held general acceptance testing sessions, where we asked users to simply play the game. And during A/B testing, we tested different versions of designs.

Key Insights

Some of the most significant takeaways that informed our game design are recapped below:

Winning Strategies

When we directed users in our testing sessions to “win the game,” they behaved differently. At the two extremes were, what I called, the “shrimp-gatherers” and the “finish-liners.” The shrimp-gatherers focused on earning points by collecting shrimp and felt that they won the game by beating the high score. In contrast, the finish-liners sped to the end, and felt a sense of accomplishment when they beat a level. Most users employed a combination of both strategies.

This prompted us to make sure the shrimp-gatherers were duly recognized for their efforts. We added a line at the start of each level displaying the number of points earned thus far and a high score section.


Our game supports three actions: go left, go right, and float up. Early testing revealed issues with the placement of our controls. Initially, we planned to put the right arrow on the right side, and left and float arrows on the left side, in order to leave the right-hand side of the screen as visible as possible. We quickly realized, though, that this control design was unwieldy for users, who found it difficult to quickly press vertically stacked buttons. 


Three control placements that performed poorly with users


Design Solution:  Our testing showed that controls placed on the actual game scene, which engage both of the users’ hands, are the most effective. We also learned that separating the left and right arrows from the float arrow worked best (modeled after the game Spout).

To make sure the right side of the screen is visible, we moved the float arrow some distance from the screen edge, and lowered the opacity of all controls by 50%. Three of the setups we tested are shown to the right, with the final setup shown below.

Final button design and placement that performed well with users

Final button design and placement that performed well with users


The Instructions Screen

In our first few iterations, we included an instructions screen, but only one in five users in testing bothered to view it. Most launched straight into gameplay.

Design Solution:  About halfway through the project, we decided to omit the instructions screen. Instead, we created an animated sequence on the landing screen that illustrates the main game mechanics—Hootie gliding over a shark, colliding with a shark and blowing up, collecting a shell and returning to a normal size, getting a shrimp point, swimming atop a platform, and swimming into the light that triggers a level change—all in seven seconds.

We received very positive feedback about the animated sequence, and users did not seem to miss the presence of an instructions screen.



In Hootie Puff, visual feedback had to be sufficient in case users had their sound turned off. 

Design Solution:  In cases where the interaction was uncommon during gameplay, we used animation (e.g. collisions with squids and volcanoes, and Hootie’s death scene). But in cases where the interactions were near constant (e.g. Hootie colliding with sharks, shells, or shrimp), we decided to go with sound and a Boolean state change only. For instance, sharks are visible until they collide with Hootie, after which they immediately disappear without an animation or transition sequence. In all interactions, there are audio cues as well.




An Engaging Gaming Experience

We successfully submitted Hootie Puff to Google Play and the iTunes App Store within the 12-week deadline. Our feedback from users has been great (best review so far: “Pufftastic! Loads of underwater fun!”)

Feel free to download Hootie Puff for free on your phone, or play on the web here.



Several months after the release, one of my friends decided to have a go at Hootie Puff. He loved it and played for 45 minutes, a lifetime for a casual game such as ours. Still, I couldn’t help but notice areas in need of improvement and issues that should be rectified. 

Although we launched many test versions for mobile, we only released one formal version onto the Apple App Store and Google Play. Ideally, we would have released multiple versions, but due to the short turnaround, we prioritized simply deploying the game on deadline. We had a number of other deliverables competing for our attention, including creating a social media campaign, producing a promo video, and navigating the confusing Apple developer process. Eventually, we had to go with what we had so we could deliver the product on time.

Developing Hootie Puff has helped me learn that first releases are imperfect, and that’s okay. Changes are to be expected, even encouraged, as the product should grow and develop once it has been in the market.

No project is ever truly done. There is always more testing to be done, more features to implement, and more problems to solve. But I am comforted knowing that we adhered to user-centered design principles and delivered an actual product that people can use and enjoy.