running playtests for a full AAA dev team

How I own playtest production on an unannounced title: from build readiness and blocker triage to hosting sessions attended by everyone from engine programmers to senior executives. Project details are withheld; this is about the process.

01context

Playtests were just being stood up when I was brought in. Production and development leadership set a mandate: QV would own the sessions, and they would be mandatory for the entire team, designers, leads, and software engineers alike, so that every discipline actually plays major new features during development.

The reasoning is simple and very production-minded: a studio's worth of eyes spots issues earlier than any QA team alone, and the people building the game backend, engine and script work included, often have no other way to experience what they're shipping. Sessions run daily, with the audience ranging from the dev team to senior leadership.

02what i own

My pod covers a significant portion of the game, and I run its playtest sessions twice a week end-to-end. On the remaining days I co-run and support sessions led by other QV designers. Owning a session means owning everything that can go wrong before the studio shows up:

• Build readiness. Selecting the build candidate, running smoke passes, and confirming our slice of the game holds up before anyone else touches it.
• Blocker triage. When the build isn't ready: logging issues, assigning them to the owning dev, and chasing the fix so it lands before the next event.
• Running the room. Hosting and moderating the team-wide Zoom sessions, distributing roles (like server hosting) across a small QV team, and troubleshooting so every dev can connect and play.
• Risk escalation. As my pod's QV point of contact I keep a direct line to my lead producer and report quality status to the Development Director: flagging blockers that threaten future sprints or UXR studies, and calling out when features moving through my pod are ready for playtest and UXR inclusion.

Production and design leadership decide what each event focuses on and what each pod owns per sprint. My job is to make sure that when the session starts, the plan survives contact with the build.

03a session's lifecycle

04results

The clearest win is speed of discovery outside QV's expertise. With software engineers, designers, and audio in the same session, issues surface that QV alone would have found later or not at all, and they route fast: participants request tickets or flag us live, and we get the bug to the dev who'll own the fix.

The second win is risk visibility ahead of milestones. As UXR studies and sub-milestones approach, consistent problem patterns become a production conversation: I bring the evidence to development and production leadership, explain what's failing and why, and we decide together whether a feature stays active in the study build.

05what i learned

The night before our first UXR event, we caught a major feature issue that should have been found a week earlier. I stayed late with senior colleagues to get a fix through that night, then smoked the build before they travelled. The event ran; the process behind it clearly hadn't.