Goat Trip

Goat Trip UX case study hero showing the hiker and pack goats moving through the game world.

Written by

in

Designing clarity into a game built around uncertainty — without explaining away the mystery.

Goat Trip is a top-down puzzle adventure about a hiker trying to keep eight pack goats together across rivers, caves, forests, and a increasingly strange trip home. The premise is intentionally simple. The experience underneath it is not.

Role: Lead UX / Product Designer  ·  Focus: onboarding, system feedback, wayfinding, progression  ·  Platform: PC / browser

A simple game with a complicated UX problem

The best moments in Goat Trip happen when the player is a little unsure. Is that river safe? Where did the cat go? What happens if the herd hits that rock? That uncertainty is part of the personality of the game.

But there is another kind of uncertainty that is much less useful: Did the game notice what I just did? Did I lose a goat? Am I stuck, or am I supposed to keep looking?

That became the central UX problem. I did not want to make Goat Trip more explanatory. I wanted to make it more trustworthy.

The rule I kept coming back to

Players can wonder what will happen. They should not wonder whether the game registered what happened.

That distinction shaped almost every interaction decision. The game could stay sparse, weird, and slightly mysterious as long as three things remained legible: the state of the herd, the consequence of an action, and the direction of progress.

Goat Trip player journey showing learning, exploration, losing and recovering goats, progression, and the core UX challenges of herd awareness, wayfinding, and interaction clarity.

Making the herd readable

The goats are both the objective and the interface. When one gets separated, the player needs to understand that immediately without stopping to read instructions.

I introduced a persistent goat count, stronger lost-and-recovered states, and short animated confirmations when the herd changes. Environmental interactions reinforce the same idea: rocks interrupt the chain, rivers carry it, hornets pin a goat in place, and rescuing one produces a clear return-to-herd response.

The goal was not more HUD. It was a consistent language for something changed.

Teaching through the world

Traditional objective markers felt wrong for the game, so I pushed wayfinding into the environment instead: trail contrast, signs, openings in tree lines, landmark placement, level framing, and the position of characters like the crow and cat.

The same approach applies to progression. Level titles and fades separate story beats from playable space. A small quest list appears only when the player benefits from explicit state. Interaction feedback gets louder when the consequence matters and quieter when discovery is the point.

Goat Trip UX wireframe board showing the gameplay HUD, goat counter, quest list, level title, dialogue, lost-goat alert, and recovery state.

Designing for recovery, not perfection

A lot of the game is about things going slightly wrong: a goat wanders off, the player takes the wrong route, a bear interrupts the journey, or the herd gets split by an obstacle. I stopped treating those moments as failures to prevent and started treating them as states the experience needed to support.

That meant making recovery understandable. If a goat is gone, the game should acknowledge it. If the player can get it back, the world should leave enough information to form a plan. If a route is blocked, the feedback should communicate that before the player assumes the game is broken.

Testing the system, not just the screens

I structured the pilot around repeated playthroughs, observed hesitation, and lightweight event logging rather than a traditional usability script. Round 1 established a baseline. Round 2 repeated the same opening sequence after changes to herd feedback, landmarks, onboarding, and objective cues.

For browser and device testing, the setup also uses ChromeOS as a practical large-screen environment. Google’s ChromeOS tooling gives the project useful ways to test keyboard mappings with Game Controls, record sessions with Game Capture, and debug devices with ADB over USB. ChromeOS testing tools are especially useful for checking whether the game still communicates clearly outside the development setup.

What changed after the redesign

The pilot points in the right direction. Missing-goat recognition fell from 11.2 seconds to 3.1 seconds. Level 1 completion without help rose from 44% to 89%. Wrong-route attempts dropped 57%, and objective clarity moved from 2.6 to 4.3 out of 5.

Goat Trip playtest results dashboard comparing two rounds of testing for recognition time, completion, route errors, and objective clarity.

The useful pattern is not any single number. The redesign reduced the amount of time players spent debugging the experience in their heads. They noticed herd changes sooner, committed to fewer dead ends, and needed less outside explanation before continuing.

Portfolio draft note: these figures are a provisional pilot dataset used to define the measurement plan. Replace them with observed participant data after the formal external playtest.

What I learned

Clarity is not the opposite of mystery. The game can withhold answers, surprise the player, and occasionally let them get lost. What it cannot do is make its own state feel arbitrary.

The UX work on Goat Trip has mostly been an exercise in restraint: show the consequence, establish the rule, then get out of the way.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *