Collecting Feedback From Conference Demo Players

There is almost nothing as valuable as standing behind a stranger while they play your game for the first time at a convention booth. They have no manual, no tutorial they remember, and no patience for your design intentions. Every confused pause, every wrong turn, every moment their hands relax is unfiltered information you cannot get from analytics. The hard part is not gathering this feedback, it is keeping it. Show floors are loud and exhausting, and by the time you sit down at the hotel that night, half of what you saw has blurred. This post is about capturing booth feedback while it is still sharp.

Watch the hands, not the face

Players at a booth will be polite. They smile, they say it is fun, they thank you. Faces lie at conventions because people do not want to insult you to your face. Hands do not lie. Watch where the player's fingers hover when they are unsure, watch the controller drift when they lose interest, and watch for the death grip when a fight gets tense. The body tells you the truth that the post-demo small talk will quietly bury under courtesy.

Train yourself to narrate silently what you observe. The player walked past the first objective three times. The player tried to jump on the wall before they found the door. The player put the controller down during the cutscene. These are concrete behavioral facts, and they are far more useful than a vague memory that someone seemed a bit lost. The discipline of noticing specific actions is what separates a useful demo session from a pleasant but forgettable conversation at your booth.

Ask one open question, then shut up

When the demo ends, resist the urge to explain what they missed or to ask ten survey questions. You have maybe twenty seconds of their honest attention before the next thing on the show floor pulls them away. Ask one open question such as what felt confusing, and then stay quiet. Silence is uncomfortable, and players will fill it with the real answer if you let them. The moment you start defending a design choice, you have stopped collecting feedback and started arguing.

Open questions beat leading ones every time. Do not ask whether the jump felt good, because that invites a yes. Ask what they would change first, or what almost made them stop playing. These questions surface the friction that matters. Write the answer down in their words, not your paraphrase, because the exact phrasing often reveals a misconception you can fix. One sharp quote from a real player is worth more than a page of your own assumptions about what they probably meant.

Capture before the next player arrives

The enemy of booth feedback is the queue. There is always a next player, and the temptation is to reset the demo and wave them in immediately. If you do that, the last session is gone. Build a thirty second ritual between players where you jot the key observations before touching the reset button. It feels slow in the moment, but a booth that captures ten sessions well beats one that rushes through forty and remembers none of them by closing time.

Keep the capture format brutally short so it survives fatigue. A timestamp, what they struggled with, one quote, and a severity gut-feel is enough. You are not writing a report on the floor, you are leaving yourself a breadcrumb you can expand later. If two staff are working the booth, one demos while the other logs, which doubles your throughput and means the person watching is never also the person fumbling with notes when the interesting moment happens right in front of them.

Separate the bug from the design feedback

Convention demos surface two very different things, and mixing them creates noise. A bug is the game doing something it should not, like a softlock when the player backtracks or a crash when they mash pause. Design feedback is the game working as built but failing to communicate, like a player not understanding they can double jump. Both are valuable, but they go to different people and different fixes. Tag each note as one or the other while it is fresh, because later you will not remember which was which.

The booth is an unusually good bug finder precisely because players do things you never would. They hold buttons you never hold, they walk into walls you assume are solid, and they trigger edge cases your QA never imagined. Treat every weird thing the build does in front of a stranger as a potential reproducible defect. If three different players hit the same wall, that is no longer a fluke, that is a priority, and your notes are the only record that the pattern existed at all.

Setting it up with Bugnet

A demo build with Bugnet wired in turns the booth into a real reporting station. When a session goes sideways, a staffer can hit the in-game report button and Bugnet captures the game state automatically, so you get the level, the position, the player attributes, and a screenshot without typing anything on a crowded floor. If the build crashes during a demo, the crash is recorded with a full stack trace and device context, which means you are not squinting at a frozen screen trying to remember what the player did right before it died.

Back at the hotel, everything you logged lands in one dashboard instead of scattered across phone notes, napkins, and three people's memories. Bugnet folds duplicate reports together with occurrence grouping, so when five demo players trip on the same broken trigger it shows as one issue with a count of five, which is exactly the prioritization signal you want after a show. Add a custom field for the event name and you can filter the whole weekend's feedback by booth, comparing how the Friday crowd reacted to the Sunday one.

Turn the weekend into a backlog

The work is not done when the show ends, it is done when the feedback becomes tasks. Within a day or two, while the memories still have texture, sit down and convert your raw notes into actionable items. Group the recurring confusions, rank the bugs by how many players hit them, and pull out the two or three quotes that made you wince. A convention that produces a prioritized backlog is a convention that paid for itself, regardless of how many wishlists you gathered.

Make this a repeatable habit across events rather than a one-off scramble. The studios that improve fastest treat every demo as structured research, comparing each show to the last and watching whether the same friction points keep appearing. If players stopped getting lost at the first objective after your patch, the booth confirmed your fix worked on real strangers. That feedback loop, from show floor to backlog to patch to the next show floor, is how a rough demo becomes a game that strangers immediately understand.

Booth feedback is rich but perishable. Watch hands, ask one open question, and log every session before the next player arrives, because by tonight the details are gone.