While helping with Fingerbox, I kept running into the same problem: development notes, playtest reactions, launch tasks, and creator research lived in different places. A decision in one area quietly changed the others. I built tools to show those links.
Start with the player’s question
Fingerbox is a coming-soon puzzle game by Agnomen. It is strange, tactile, funny, and deliberately hard to explain without spoiling it. That makes the player’s questions especially important. At each point in the game, what do they think is happening? What are they curious about? What can they try next?
I mapped those questions alongside the relevant gameplay moments. That gave the team a way to discuss pacing and confusion without falling back on broad comments such as “this section drags.” A playtest reaction could be attached to the moment that caused it, and a proposed fix could be judged against the question it was meant to answer.
A list was not enough
The project already had the normal collection of fixes, assets, builds, store work, clips, tests, and outreach. The problem was not a lack of tasks. It was that a list could not show when several tasks depended on the same unresolved gameplay issue, or when one fix would affect the trailer, the store page, and a creator demo.
I built a connected view of gameplay moments, questions, evidence, dependencies, and next actions. It is still a planning tool, but the links matter more than the columns. The team can see why a task exists and what else changes if it moves.
Research has to change a decision
Playtests, creator research, comparable games, and team instinct answer different questions. I kept the source next to the conclusion and recorded whether something was observed, inferred, or still unknown. That makes it easier to challenge a weak assumption without reopening every earlier conversation.
I also tried to give each research note somewhere to go. It should change a priority, support a specific choice, or remain marked as background. If it does none of those things, it does not need to occupy the team’s attention.
The website should feel like Fingerbox
A normal game landing page would describe Fingerbox from the outside. We instead built a site that behaves like recovered material from inside the game: an archive, an apparatus assessment, and a case that can be passed to somebody else. It still points people to Steam, but it gives them something to do first.
The site stores reports in the visitor’s browser. Shared case links carry limited state in the URL without putting names into server logs. That privacy choice is practical, and it also suits the fiction better than an account system would.
Keep the extra system small
A small game team does not need more administration. The point of this work is to reduce repeated explanation and make the next decision easier. If maintaining the map takes longer than the discussion it replaces, the map has failed.
The useful version is modest: connect the game’s important moments to evidence and work, keep the reasons visible, and stop before the tool becomes a second project.