Quick answer: Place a "Report a problem" button in the pause menu, capture a compressed screenshot plus device info on tap, and queue the report to local storage if the network is unavailable. Ship the widget in the SDK itself so you do not have to rebuild the UI for every game.

Mobile players report bugs 5–10x less often than desktop players, and the main reason is friction. On desktop, a player can alt-tab to Discord and paste a screenshot in thirty seconds. On mobile, that same flow requires leaving the app, opening a browser, typing an email, and attaching a screenshot from the camera roll. Most players will not do it. An in-game feedback widget is the single highest-impact thing you can add to increase report volume on mobile. Here is how to build one that does not annoy anyone.

Where to Place the Button

The worst place is the main HUD during gameplay. Mobile screens are small, fingers are fat, and tapping the wrong button mid-combat is infuriating. The best place is the pause menu, which already has a "Settings" and "Quit" button — add "Report a Problem" as a third option. If you do not have a pause menu, put it in the main settings screen accessible from the main menu.

For live service games with a floating social button (friends/chat), an alternate pattern is a small question-mark icon in the top-right corner of the main menu. Avoid the word "Feedback" — players associate it with surveys. Use "Report a Problem", "Send Feedback", or a bug icon.

What to Capture

The goal of an in-game feedback widget is to make the player's job as small as possible. Auto-capture everything you can. The player should only have to type a short description.

All of this is automatic. The player adds a description and a category (optional dropdown: Bug, Suggestion, Performance, Other) and taps Send.

Step 1: Capture a Screenshot Before Showing the Form

If you capture a screenshot after the form appears, the form covers the issue the player wanted to report. Always capture first, then overlay the form:

// Unity C#
public IEnumerator OpenFeedbackWidget()
{
    // Hide the widget button so it's not in the screenshot
    widgetButton.SetActive(false);
    yield return new WaitForEndOfFrame();

    // Capture at native resolution
    Texture2D shot = ScreenCapture.CaptureScreenshotAsTexture();
    byte[] jpg = shot.EncodeToJPG(70);

    // Show the form with the captured screenshot as a thumbnail
    widgetButton.SetActive(true);
    feedbackPanel.Show(jpg);
}

Quality 70 JPEG is the sweet spot: visually lossless for UI elements, small enough to upload on cellular, and fast to encode. For higher-fidelity capture (pixel art games), use PNG and accept the larger file size.

Step 2: Build a Minimal Form

The form has four fields and one button. That is it.

Do not ask for an email. Do not ask for the player's name. Do not ask for reproduction steps. The player tapping this button is already doing you a favor — each additional field is a reason for them to close the form and continue playing without reporting.

If you need a way to follow up, add an optional "Contact me about this" checkbox that, when enabled, pulls their account email from your game's auth system. Most players leave it off, and that is fine.

Step 3: Include a Redaction Tool

The number one reason players hesitate to send screenshots is fear of personal information leaking. Add a simple redaction tool: show the screenshot thumbnail at medium size, and let the player drag a finger to paint a black box over anything they want hidden. No precision required, just a rough smudge tool.

void OnDragRedact(PointerEventData data)
{
    var pos = ScreenToTexture(data.position);
    int size = 40;  // thick brush for finger input
    for (int x = -size; x < size; x++)
    {
        for (int y = -size; y < size; y++)
        {
            screenshotTex.SetPixel((int)pos.x + x, (int)pos.y + y, Color.black);
        }
    }
    screenshotTex.Apply();
}

The redaction happens on the client before upload — redacted pixels are literally overwritten in the image data, so there is no way to recover them server-side. Players appreciate this; their trust in your report flow goes way up.

Step 4: Queue Reports When Offline

Mobile networks are unreliable. Always assume the send will fail and design for it:

public class FeedbackQueue
{
    string queueDir => Path.Combine(Application.persistentDataPath, "feedback");

    public async Task Enqueue(FeedbackReport report)
    {
        Directory.CreateDirectory(queueDir);
        string file = Path.Combine(queueDir, $"{Guid.NewGuid()}.json");
        await File.WriteAllTextAsync(file, JsonUtility.ToJson(report));
        _ = TryFlushAsync();  // attempt upload, fire-and-forget
    }

    public async Task TryFlushAsync()
    {
        if (Application.internetReachability == NetworkReachability.NotReachable)
            return;

        foreach (var file in Directory.GetFiles(queueDir, "*.json"))
        {
            var json = await File.ReadAllTextAsync(file);
            if (await UploadAsync(json))
                File.Delete(file);
        }
    }
}

Call TryFlushAsync at startup, when the app returns to foreground, and whenever connectivity becomes available. Reports submitted offline eventually make it to your dashboard, and the player sees a subtle "Sent when online" indicator confirming the queue.

Step 5: Confirm Without Interrupting

After a successful send, show a brief toast: "Thanks! We got your report." Not a modal, not a popup that blocks gameplay — a one-line toast that dismisses after 2 seconds. The player came to report a bug and wants to get back to the game; do not make them tap "OK" to escape a confirmation dialog.

If the upload queued for later, the toast says "Sent when online." Same treatment: brief, non-blocking, informative.

Measure Whether It Is Working

Track two metrics: widget opens and reports submitted. The ratio tells you how often players open the widget but bail out before sending. A ratio below 50% suggests your form is too long or intimidating. A ratio above 80% is excellent.

Also watch the total report volume. If it does not go up after adding the widget, check whether the button is discoverable. You can A/B test button labels, icons, and placement until you find one that works.

"The average mobile player will never file a GitHub issue, never post on Discord, and never email support. They will tap a bug icon in your game if it is there. Put it there."

Related Issues

For a broader guide to collecting player feedback in-game see how to collect player feedback in-game. For mobile-specific crash reporting that complements the feedback widget, read mobile game crash reporting best practices.

The feedback button should be easy to find, easy to use, and hard to press accidentally. That is the whole design.