Giving feedback

Begin with the problem a player experiences

Useful feedback explains what a player is trying to do and where the experience becomes confusing, frustrating or unnecessarily difficult. Start there before presenting a solution. “I cannot tell which ability is selected on this background” gives the team a concrete problem. “Completely redesign the interface” proposes a large change without establishing what needs to improve.

Describe the context: device, mode, feature and moment in the session. The same control can be understandable in a quiet menu and difficult during a fast round. A specific situation helps the team compare your experience with the intended use. You do not need design terminology or a long proposal to make the observation valuable.

Separate a suggestion from a bug

A bug report describes behavior that differs from the expected operation, such as a control failing to save or an ability not producing its described effect. A suggestion proposes a different or improved experience even when the existing feature works as designed. Both are useful, but they benefit from different evidence.

For bugs, provide steps, expected result and observed result through Gameplay & bugs or the relevant technical category. For ideas, explain the player problem and why your proposed change could help. If one report contains both, label the observations separately. A confusing label and a broken save action should not be merged into a single vague claim that the whole feature is unusable.

Describe the current experience fairly

Walk through what you did using the labels and controls actually present. Explain where you hesitated or made an avoidable mistake. If you misunderstood a rule, that can still be useful feedback about how the rule is taught. Be honest about what you knew at the time rather than presenting a later explanation as something the interface clearly told you.

Avoid treating a single frustrating match as evidence that every player has the same problem. Say how often it happened to you and whether you observed others encountering it. The team can investigate scope. A carefully described individual experience is more useful than a claim of universal agreement that the report cannot support.

Offer a concrete, limited proposal

After explaining the problem, describe one change that might improve it. A clearer label, an additional confirmation, a better default or a short explanation can be easier to assess than a complete replacement of a system. Include what the proposed change would let the player do more easily.

You can offer alternatives if they address the same problem, but keep their trade-offs visible. For example, a larger indicator may improve visibility while taking more screen space. Explain which benefit matters most in your situation. The team may choose a different implementation that solves the same underlying problem, so do not make one exact layout the only acceptable outcome.

Include examples that reveal the issue

A short recording or focused screenshot can show the point of confusion. Annotate the relevant area if needed and describe the action immediately before it. Hide unrelated private messages and account details. A full match recording with no timestamp makes the team search for the example instead of assessing it.

If the suggestion concerns wording, quote the short label and explain the interpretation it produced. If it concerns flow, list the few steps you took. If it concerns balance, identify the agent, weapon, situation and result you observed. Avoid presenting a proposed numerical change as proven simply because it would have helped in one encounter.

Think about different players and devices

A feature may be used by new players, experienced players and people on different input devices. Explain which group your suggestion helps and whether it might make another task harder. You do not need to solve every case, but acknowledging the context makes the proposal easier to evaluate.

For example, an extra explanatory panel can help a beginner but become repetitive for somebody using the feature often. Suggesting a concise explanation or an optional reference may preserve the benefit with less interruption. Accessibility concerns should describe the practical barrier, such as low contrast or an unclear focus state, rather than assuming every player sees the same screen.

Example: improve a mission description

Suppose you repeatedly interpret a mission as counting one action, but the actual requirement is narrower. Capture the current description and explain the action you expected to count. State what progress appeared afterward. If the mission works according to its intended rule, propose wording that makes the requirement clearer.

If the counter also fails under the stated conditions, separate that as a bug with reproduction steps. This gives the team two assessable concerns: clarity of instruction and correctness of progress. A single complaint that “missions are bad” would hide both actionable details.

Follow up without creating a vote campaign

Send the suggestion through Feedback & ideas and keep relevant follow-up in the same conversation. If you find a clearer example or a practical drawback, add it. Do not create many duplicate tickets or pressure other players to repeat the same message. Repetition does not replace an explanation of the player problem.

An acknowledgement means the idea was received, not that the exact feature or release date is approved. Development involves priorities and dependencies that may not be visible in a support conversation. Watch official News for announced changes and assess the published result when it becomes available.

Frequently asked feedback questions

Must I write a full design document? No. A specific problem, context, example and proposed improvement are enough to begin. Length helps only when it adds relevant detail.

Can I suggest a different solution after submitting? Yes. Explain why the new option addresses the same problem better and keep the discussion connected.

Does a popular idea guarantee implementation? Popularity is one input, not a release commitment. The team still needs to assess the experience and available work.

Can I report unclear instructions even if I made a mistake? Yes. Explain the misunderstanding honestly. It can reveal where a label or tutorial needs improvement.

Use a simple submission structure

Give the idea a descriptive title. Explain the player problem, where it occurs, what you tried, your proposed change and the expected benefit. Add one focused example and any important trade-off. Choose Feedback & ideas for a proposal and the relevant bug category for a failure that needs reproduction.

Keep the tone factual and direct. Criticize the behavior or design rather than attacking players or staff. A report that another person can understand without sharing your frustration is easier to compare, discuss and turn into a useful product decision.