27 Photos
UX/UI Design
Level Design
Puzzle Design
Project Management
Team
Timeline
Roles
Project Lead
Design Lead (UX, Game, Level)
One Constraint
The whole game runs on one constraint: a camera that holds 27 photos.
You play as Cam, moving through a flooded, memory-filled tower with a retro, 2000s PlayStation 1 aesthetic. Her only tool is a camera. It holds exactly 27 photos.
The loop is short. What the camera limit does is make every step of it cost something - a photo becomes a decision, something to consider, and to weight. Does this image matter? Each image gives a caption with story, lore, hints to a puzzle.
Player Flow Diagram
Leading the team
I led four designers and specced work for four disciplines I couldn't build in.
27 Photos is a Yale student project. 26 people are credited across five disciplines over the year. I worked with four designers on the design team, and we split UX, game, level, and UI between us, and I ran the assignments board every other discipline worked from. Design was the center point of the team - we requested and wrote out documents for the other teams, working collaboratively so we understand constraint, style, and technical requirements.
26 credited contributors across five disciplines.
The first demo
The first demo showed players didn't trust the system.
Our April 2026 alpha demo put a fully complete vertical slice in front of real players, and for the first time they could play from start to end with all of the art and music.. Across 10+ testers, we synthesized the findings - one line from a testing session set the direction for all of future development: "Players don't trust the systems yet."
“27-photo limit made me overly conservative taking a photo felt like punishment rather than freedom.”
— Playtesting Quote
“Taking a photo didn't feel like the primary interaction, more like a last resort.
— Post Mortem Analysis
Turning point
I rebuilt the photo limit so running out stopped feeling like a punishment.
The original design was a soft roguelike: hit 27 photos and the game reset you, on purpose. Scarcity was supposed to make each photo matter. It made players cautious instead, and the tutorial never said a reset wasn't a loss. I rebuilt the mechanic around continuation.
Before: Hitting 27 photos forced a reset to the start of the level.
After: At 27 photos, delete one to keep going. No automatic reset.
Decision
Storage over reset
Reasoning
Encourages exploration and engagement rather than fear of running out of photos.
The idea underneath survived. Deciding what to let go of still carries weight. It just became a real choice later in the game instead of a penalty for playing too much.
The camera still holds 27 photos; what differs is whether hitting the limit ends the run or challenges the player
Delete Animation in Album Menu
What players stop for
Loosening the photo limit let players take more photos. The environment needed to cue what was important.
The storage change fixed the fear and exposed the next UX and game design problem. A hard limit had been doing hidden work: when photos are scarce, players only spend one on something unmistakably important. Loosen it, and far more objects have to show their importance.
At first, we discussed a glow, a UI indicator, a sound effect that cues a player into an object's importance. An audit of the whole level current design made us realize that we needed to focus on environmental cues for important actions - lighting, positioning, animation.
Design analysis of object relations and weak links between important objects.
Mahjong Tile - placed it in a location that would be strange and noticeable, and near the associated puzzle.
Bus Pass - placed behind the counter as a secret, but using color to highlight its importance. The area is locked by a puzzle.
Puzzle Confusion
The same lack of prominence had turned Floor 1's puzzles into a number hunt.
The same blindness ran one level up: players who couldn't read which objects mattered had no chance of reading which keypad a code belonged to. My diagnosis at the time: "The player feels like they are scavenging for a number, and that feels arbitrary and random." This brought about a series of design decisions across the experience.
Decision
Standardize 5 digit keypad codes as passwords.
Shorten distance between hints and puzzles
Add captions and hints to each locked door
Add alternate paths of objects to the same answer
Solving the mahjong puzzle and receiving a new object
Chain of related objects
Visual Systems
None of it cohered until the interface was also nostalgic (and a bit kitsch).
I designed the interface at minimally invasive: something a player would believe was really there, an early-2000s object with real weight, that got out of the way the moment it wasn't needed. This style was to reinforce the sense of nostalgia and memory that persists through the game. Motion follows the same rule as the type and colour, feels like of the 2000s era.
Blue: #58b2cd
Violet: #b2b5db
Yellow: #fdfdcb
Sofia Pro Soft — the game's only typeface. Soft, retro, cartoon-y. (References: Kingdom Hearts, Pokemon Snap, DS-era games)
Logo Explorations in 2000s style
Final Logo (Dark Mode)
Photography Animation
The environment teaches
Then I let the environment teach what a tutorial couldn't.
Every UI prompt in the game is contextual, it shows up once, only when it's actually needed. The interface should feel like one object with the world and contain only what is necessary - and only photo-related objects. The album is paged and bookmarked like a real album you'd hold; each floor is a stamp. A simple prompt with little other instruction or a diegetic puzzle allows for immersion more than anything.
Diegetic Keypad UI
Status
Two floors are finished. The third is on its way.
One design question is still open: "Players feel like observers rather than explorers." This is a classic UX vs game design question - how much do we want players to know, how much agency to hand players, without undercutting what the story needs them to notice? This challenge is a trade-off I'm still working through.
The 27 Photos Team
Reflection
What I'd take with me as I continue building
Most of my reasoning lived in my head and in meetings. That worked while I was in every room. It won't scale, and it's the first thing I'd change: write the why down the moment I make the call.
The observer-versus-explorer problem isn't solved just yet. How much guiding is too much hand-holding, and how can UX serve game design? We are continuing to build and test and iterate, over and over again, as we work towards the final release.
