How to Give Design Feedback a Studio Can Act On

Good design feedback names what you see, describes why it feels wrong, and leaves the solution to the people building it. Most feedback stalls a project not because it is wrong but because it is too vague to act on. "The jump feels floaty and the landing has no impact" is actionable. "This does not feel right" is not.

Why this matters

Feedback is the main tool a founder has during development. Every milestone review, every build playthrough, every conversation about direction runs on it.

When feedback is clear, development moves. When it is vague, the studio guesses, builds the wrong fix, and the cycle repeats.

The skill is learnable, and improving it saves more time than almost any other change a founder can make to how they work with a studio.

Name what you see, not what you feel

The first rule. Describe the observable thing before describing your reaction to it.

"I do not like the menu" is a reaction. "The menu takes three taps to reach play" is an observation. The observation can be verified, discussed, and fixed. The reaction cannot.

Practice this format: "When I [do this], [this happens], and it feels [this way]."

• "When I tap the attack button, there is a pause before the animation starts, and it feels unresponsive."
• "When I open the shop, the prices are shown before the items, and it feels confusing."
• "When I finish a level, nothing happens for two seconds, and it feels like the game froze."

Each of those gives the studio a place to look, a behaviour to observe, and a direction for the fix without prescribing the fix itself.

Describe the problem you experienced. Let the studio describe the solution.

Separate the problem from the fix

The most common feedback mistake is jumping to a solution.

"Make the button bigger" sounds like clear feedback. It is actually a prescribed fix for an unstated problem. The button might be hard to find, hard to tap, visually unclear, or in the wrong place. Each of those has a different solution, and making it bigger only fixes one of them.

State the problem: "I had trouble finding the attack button during gameplay."

Now the studio can investigate. Maybe the button needs to be bigger. Maybe it needs more contrast. Maybe it is in the wrong spot relative to where the player's thumb sits. The fix follows from understanding the problem, not from the first solution that comes to mind.

The exception is when you have a strong preference about how something should look or work. That is a creative direction, not feedback, and it is fine to give it as one.

Just name it clearly. "I want the menu to be dark with large icons" is a direction. "Fix the menu" is neither direction nor useful feedback.

The review format that works

Structure helps more than volume.

A useful review covers three things per issue, in this order.

1. Where. Screen, level, moment, or flow.
2. What. The specific behaviour or appearance.
3. Impact. Why it matters to the player.

Skip the impact and the issue loses priority context. A studio cannot tell whether "the font is small" is a minor preference or a readability problem without knowing the impact.

Keep each item short. Two or three sentences is enough. Long paragraphs bury the point and make the review harder to work from.

Group items by screen or flow rather than by severity. Severity is subjective and changes with context. Location is stable and helps the studio work through the list efficiently.

Timing: when to give feedback

Early and often, but at the right moments.

• After each milestone build. This is the natural review point and the studio expects it.
• After playing for ten minutes without stopping. Your first, uninterrupted experience is the closest you will get to a new player's experience.
• Not during a call. Write it down. Verbal feedback during a meeting is forgotten by both sides within an hour.

Avoid giving feedback on work in progress unless the studio asks for it. Incomplete work looks wrong by definition, and commenting on it wastes both your time and theirs.

The best related guidance on this timing is in Client Role During Game Development.

Five common mistakes

Mistakes that waste cycles even when the feedback itself is correct.

1. Feedback on everything at once. A list of forty items is a list of zero items. Prioritize the top five.
2. Contradicting previous feedback. Keep a record. If you change direction, say so explicitly and explain why.
3. Comparing to a specific game. "Make it like [game]" is too vague to act on and too specific to be useful. Name the quality you want instead.
4. Giving feedback to the wrong person. Design feedback to the designer, art feedback to the artist. Routing through a single contact is fine; routing everything to the producer and hoping it reaches the right person is not.
5. Skipping the positive. Telling a studio what is working is as useful as telling them what is not, because it protects the good work from being accidentally changed.

What we would do

Play the build once without taking notes. Then play it again and write down every observation using the "when I, this happens, it feels" format.

Send the top five issues with location, behaviour, and impact. Save the rest for the next round.

Then protect what is working. Name two or three things in the build that should not change, because a studio optimising around your complaints may accidentally break the parts you liked.

The short version

• Name what you see before describing how it feels.
• Separate the problem from the fix and let the studio solve it.
• Structure each item as: where, what, and why it matters.
• Write feedback down instead of giving it verbally during a call.
• Send five items, not forty.
• Name what is working so the good parts are protected.

Play your latest build and write three observations using the format above. If you want help structuring a review process with your studio, reach out.