Devon Stanton

Work

MWU Review

Unity

Senior Program Manager

My part: Created, built and ran the program: set the criteria, built the system and worked with the studios

A pre-launch review program I built and ran: Unity staff play studios' games and send back one written report. 70 projects went through it.

ProductInternal processCustomer-reportedHow to read this tag
Illustrative artwork created for this page, not a photo of the real product.

Problem

Studios shipped without outside player-perspective critique; feedback was informal keys passed around on Slack.

What I did

I built a pre-launch review pipeline: an intake form, validation against our games database, fair key allocation to volunteer Unity staff, automated reminders, and a report generator that turns the feedback into one written report per studio. I set the review criteria and ran each review myself, alongside my main role, so it was designed to be as light a lift as possible.

The decision

Open sign-up: Unity staff chose which game to play and registered for a key, within a window of about two weeks and with one written report per studio, instead of ad-hoc feedback.

Result

  • 70projects reviewed, in a program that did not exist before
  • 1,284requests from Unity staff to play studios' games, all handled through the system
  • Under 1 dayto generate the report after the review window closes
  • 98%Steam validation score at launch, credited to the review by one studio

How it started

It began as a side project at the start of 2024. Studios offered Unity free game keys, and I wanted a better way to hand them out than passing them around on Slack. Giving feedback in return made it a fair exchange instead of a one-sided favour, and the feedback turned out to be the valuable part.

Unity's reviewers are engineers, designers and artists, so they look at a game differently from most players. That was the reason a studio would want the report.

How it works

Every step is either automatic, started by me, or a gate that holds things until a check passes. I wanted control where it mattered and no manual work where it did not.

AutomaticI trigger itGate check

  1. 1Intake form

    Automatic

    A studio describes its game and the areas it wants feedback on.

  2. 2Validation

    Gate check

    I check every entry and match the game to our games database before anything goes out.

  3. 3Reviewer sign-up

    Automatic

    Promotional email and Slack posts go to the volunteers, who sign up and give their PC specs.

  4. 4Key allocation

    I trigger it

    I can flag accounts, then press allocate. Keys go out automatically, based on previous participation, so everyone gets a fair chance.

  5. 5Hold and release

    Gate check

    Keys can be held until extra conditions are met, such as signing an NDA, then they go out with an email pack and guidelines.

  6. 6Review window

    Automatic

    Reviewers play, send feedback and bug reports with their specs attached, and three reminders go to anyone who has not responded.

  7. 7Report

    I trigger it

    Once all the details are in, I start the generator. It builds one report from everything collected. Most went to studios as a PDF, and from early 2026 as an online report.

Then back to step 1: Studios come back with an update or a new project.

Every step is logged and recorded.

Each report brings together everything the reviewers sent in, with a summary of the common themes:

Studio report
  • Reviewer comments
  • Bug reports
  • Scores
  • Player PC specs
  • Common themes
  • Raw data
  • Session videosOnline report
  • Player logsOnline report
Reports started as a PDF per studio. From early 2026 they were online, so studios could work with the data and see what players saw.

Built to be a light lift

Reviewers are volunteers, the program has no budget, and I ran it alongside my main role. That set the design rule: anything repeatable had to be automated. Key allocation and report generation run at the press of a button, reminders run on their own, and the report takes under a day, which leaves more of the review window for reviewing.

How it grew

The first version ran on an Airtable form, a games database and Google Docs reports. As studios came back and the volume grew, I kept adding automation around it rather than adding people: the reminders, the key allocation and the report generator.

When Unity's internal language model moved behind the company firewall, part of the pipeline had to move with it. I moved that functionality to the cloud so the reports kept generating.

At the start of 2026, reports moved from a PDF to an online report. That gave studios more freedom to work with the data, and it let us include videos from players' sessions and downloads of their player logs.

What studios said

"...the summary, that the playtest report had, captured a lot of accurate insights. The full report also provided the right amount of detail on the issues summarized, details that have been very helpful to the team and are often referenced in discussions."

Alexandros Kilmpasanis, Senior Producer, Starbreeze (The Tribe Must Survive)

One studio launched with a 98% validation score on Steam and credited the review. Some came back for a second round or with a new project, and at least one credited the reviewers in the game. Unity's sales team also adopted the program on their own, as a way to build trust with key studio accounts.

What I'd change

I would have moved to a cloud version sooner. It would have unlocked a lot more in how well we could serve studios, and made the process better for everyone involved.

I left Unity when the company restructured, and handed the program to the team that was keeping it going.