Bug reports that work for players and studios

A guided form for the players of Games2Gether, a video game community platform, and a back office so each studio can adapt it to its game.

Complete reports88.4%against 41.8% before the tool
Duplicates9.1%of reports, against 27.6%
First reply1.9 daysmedian time, against 4.8 days

The problem

Incomplete bug reports in the forums, follow-ups and duplicates.

My role

The player journey and the studio settings, in a team of three designers.

My approach

Analysing reports with QA, mockups iterated with the team, then tests of the list.

The result

Complete reports from 41.8% to 88.4%, first response in 1.9 days instead of 4.8.

Role: Product Designer (UX/UI)
Team: Three designers taking turns, PO, developers, QA and community managers
Timeline: Two months of design, then a list update
Tools: Figma, FigJam, Notion, Airtable

01For players: three decisions

Search before you create

I put search inside the creation journey: players can find, vote on and follow an existing bug. Automatic detection alone was not enough, because the same problem can be worded in different ways.

Humankind's Bugs page on Games2Gether: search field, categories, bug lists and personal dashboard — Search for an existing bug before creating a report.

Guide the writing

Category, platform, version, reproduction and attachments: the steps follow what QA needs. We ruled out a single page with every field, to guide input without losing useful details.

Back office: configuring the report form, step 1 bug title, step 2 category and sub-category — A guided form, with the information QA expects.

A bug report: platform and store, description, numbered reproduction steps, vote gauge and a developer's reply — The structured report brings together context, reproduction and the studio’s reply.

Make progress visible

Status and votes show in the list. Players can see progress and the studio’s replies without scrolling through a discussion thread.

02For studios: a form configured per game

A shared framework, configurable per game

Studios do not use the same platforms, versions or files. Rather than one global form, I designed per-game settings in eight steps: instructions, visible or optional fields, accepted files.

Back office: settings for the reporting home page, title and description — The studio writes the titles and instructions of the player journey.

Back office: steps 3 and 4 of the form, basic information, game version management, step by step with its switches — Platform, version and reproduction: settings per game.

See the other configuration screens

Back office: steps 5 and 6 of the form, file upload with file types, screenshots — The studio sets the files and screenshots requested.

Back office: steps 6 to 8 of the form, image, summary before publishing, report title — Step visibility and optional steps, up to the summary.

Back office: a file type's sheet, name, platform, extension, folder, description — The file path helps players find their save.

Back office: the vote threshold setting, set to 4 — The vote threshold is configurable: 4 points in this example.

Connect the studio’s work to what players see

QA filters and exports the reports. The studio changes the status and replies from the same page, and the player finds the reply in their report.

Back office: report list with filters, columns for category, platform, store, version, votes, comments, status, CSV export, titles blurred — A list and a CSV export to handle the reports.

Back office: a report, its status timeline, choice of the new status, message to the player — Status and reply to the player are updated in the same place.

See statuses and filters

Back office: the game's status list with the number of reports in each, descriptions blurred — Three mandatory statuses, plus the studio’s own choices.

Back office: advanced filters for the report list — Filters that match the information collected.

Cells containing sensitive data are blurred.

03A clearer list, after feedback

Cut-off titles and misunderstood statuses kept coming up in feedback from the team and the community managers. I reworked the list hierarchy, prepared scenarios and ran internal tests with several colleagues, then used the SUS questionnaire with the production teams. The feedback made titles and statuses easier to read.

Filtered bug list: sub-categories, platforms, stores, versions and statuses, each report with its version, platform and gauge — Titles and statuses readable in the list, without opening each report.

04Results

The team’s measures at launch, comparing the old forums with the tool:

Measure	Before, forums	After, tool
Complete reports, with version, platform and steps filled in	41.8%	88.4%
Duplicates, a bug already reported the same month	27.6% of threads	9.1% of reports, a relative drop of 67%
Reports receiving a first reply	44.3% of threads	80.6% of reports
Median time to first reply	4.8 days	1.9 days
Community managers' follow-ups to players	56.2% fewer follow-ups

Sources: back-office export, a sample of the old threads and feedback from QA and the community managers. These before/after comparisons are not an A/B test.

Later use, public count

In a public count, 3,903 reports are counted across three games. This count describes later use, separate from the launch measures.

769 reports on Humankind, 2,517 on Endless Legend 2 and 617 on Endless Dungeon. The 3,848 old Humankind threads and the 3,350 threads of Endless Space 2, still on the forum, describe the old channels. They are not a comparison of volumes over the same period.

The 2,517 Endless Legend 2 reports cover the period since its demo, about 180 a month, and 14 were posted in the 48 hours before the reading. These windows are not comparable to the periods of the other volumes.

Nine statuses are in use: Submitted, Investigating, Fixed, Known Issue, Bug filed, Needs more info, Can not reproduce, Working as Intended, Resolved in a future build. Together with votes, they show how the tool works.

Each studio sets its own vote threshold. Two gauge examples: 19 votes and 19% on Humankind, 43 votes and 860% on Endless Legend 2. These percentages measure neither a conversion nor a fix.

05What I learned

I would track complete reports, duplicates and time to first reply over time. I would also test the configuration with a community manager discovering a new game. Maze and Hotjar were not used on this project.