It’s Not You, It’s Us

The pitch

“It’s Not You, It’s Us is a 3D point-and-click adventure about a group of animal characters coming together to make their town a better place. Explore a cozy town as you meet the Urbanimals that call it home, and discover that taking care of the environment, and each other, is something nobody can do on their own. With charming graphics and simple controls, anyone can engage and have fun in this short gameplay experience!”

My role

I was the UI/UX designer on the team. That covered the dialogue & quest systems, character switching, hover feedback, and every menu from the start screen to the credits. I researched, designed, and implemented each system myself in Unreal Engine 5, using UMG and Blueprints.

The design goal: readability for non-gamers

Our client wanted a game that gets people talking about sustainability. The target audience was non-gamers, people who might never have played a game before. That set the main rule for every UI decision: if a non-gamer can’t see what to do, the feature isn’t finished.

This was harder than it sounds. Things that felt obvious to me and my team kept turning out to be confusing in playtests, so I had to keep questioning what “clear/readable” really meant.

Dialogue system: a tool, not just a system

Every character in the game needed conversations, and several teammates needed to write them. Instead of building each conversation separately, I made a reusable dialogue component. Any developer can add it to a character, write the dialogue lines, and add answer options for the player.

The component includes functions for opening and closing conversations, moving through dialogue, branching on the player’s choice, and switching the dialogue once a quest is completed. I also added a legend and a worked example inside the project, so teammates could use it without asking me every time.

Quest and pause menu

The quest menu is designed as a paper notebook with stickers, to match the game’s cozy, hand-made style. When the player completes a task, it gets struck through, so progress is visible at a glance.

Because the game uses mouse-only controls, I combined the pause menu with the quest notebook rather than giving it its own screen. The game also doesn’t fully pause, since there’s no danger in it. Instead, opening the menu disables movement and enables UI selection. The quest button has a small attention animation that’s switched off during cutscenes and dialogue, so it doesn’t distract at the wrong moment.

Feedback on every interaction

For non-gamers, the hardest part of a game is often knowing what you can do. So every interaction gives feedback:

• The cursor changes when hovering over something interactable, and the object gets highlighted.

• An indicator shows which characters have something to say.

• Using the right or wrong ability on an object shows a green or red overlay.

Character switching

The player switches between animal characters, each with their own ability. The switching screen has hover animations, locked and unlocked states, and selection indicators. Characters unlock as the player completes tasks.

My first version locked characters for everyone, including my teammates. That blocked them while testing during development. A teammate flagged it, and I added an option to unlock all characters outside normal progression. Looking back, I’d also build the character slot as one reusable widget instead of duplicating it five times.

Menus and game flow

I also designed and built the start menu sequence (with a fade and the team and BUas logos), the settings menu with quality, resolution, and accessibility options, the credits, and the end sequence. One detail I like: the tree on the main menu is dead when you start the game, and alive again once you’ve completed it.

Working with artists and the team

Before implementing anything, I put together UI guidelines for each feature: reference images, colour palettes, layout notes, and conclusions. This let the team give feedback and iterate on the design before it reached the engine. In the post-mortem, the team called these guidelines extensive and useful.

To make working with the visual artists smoother, I also created:

• A UI Artist Handbook: a guide to the UI pipeline and asset workflow, meant to reduce revisions.

• A priority list: which UI assets I needed and by when. The artists said this really helped them plan.

• A screen navigation flowchart: how all my screens connect in-engine, which made integration easier for everyone.

I used placeholder assets in-engine so artists could see what was needed, and I regularly shared work-in-progress on Discord with a short summary of what was done and what was left.

The result

The client told us the game achieved its brief: it made players think and talk about sustainability without feeling preachy, and it was fun to play and looked great. Since the whole audience was non-gamers, I took that as confirmation that the UI did its job. The game also won the Best Design Award among the Year 2 projects.

What I’d do differently

• Test with the real audience earlier. The settings menu took longer than expected and pushed out our planned non-gamer playtest. Next time I’d schedule external playtesting early, because it needs organizing and can’t be squeezed in at the end.

• Design for teammates, not just players. The character lock taught me to think about how my systems affect other people’s day-to-day work.

• Make sure important documents get read. I shared the UI Artist Handbook only once, and it was forgotten. Now I follow up and check that information actually lands.