[GUIDE] Leaving effective feedback

The idea of a “how to feedback” has been a long running joke in this community, but it’s high time that we had a good, serious look at how to leave purposeful and effective feedback. It’s not that we have too many people leaving jokes in the feedback section (although this will get addressed), but simply that people try to leave useful feedback that ends up just not making sense to the creator of the map.

Leaving good feedback is a matter of using efficient language. You want to convey as much information as possible with as few words as possible. How do you accomplish that? You have to think from the perspective of the map maker looking at your feedback. They aren’t in your shoes, and they don’t have any of the context to what was going on when you left feedback. All they have is a little bit of text, and possibly some coordinates. That’s a lot less information than you have!

1. Reporting a bug

Let’s take a look at an example. Suppose the mapper made the mistake of copying and pasting a door prefab, and as a result, the doors sometimes close right in people’s faces, or open when nobody approaches them. There’s a lot of different ways you might approach this!

You can use the catch-all method of explaining every last detail of what the issue is. “Sometimes this door will open with nobody near it, or will close in people’s faces.” There’s nothing wrong with this, but it’s a bit long to type in the middle of a game. If you ever really need to leave something like this, there’s nothing wrong with hopping into spectator mode and leaving feedback that way. Remember, we don’t just run custom maps for fun. These are actually map tests, and the map is the important thing here (not your KDR). If all else fails, leave a comment on the map’s forum thread.

Let’s say that you happen to know that this exact issue of weird door behavior is caused because the mapper copy-pasted door prefabs instead of creating new prefabs for each door, so you leave “Don’t copy/paste your door prefabs.” That’s all well and good, but the mapper might not know why that’s a problem. If they’re not familiar with the issue this causes, they might just dismiss the feedback because they don’t know what it means.

The best short message you can leave is something that says “This door doesn’t act right.” “This door acts funky.” Best yet, “This door closes randomly.” It gives the mapper quite a bit of information: The door isn’t completely broken, but it doesn’t act like it’s supposed to either. This prompts investigation, and hopefully a solution. Though, if you know the issue, you should include it. “Door acting funky, copy/pasted?” would be better and help give newer mappers a direction.

2. Giving suggestions

There’s a few other situations where careful wording leads to better feedback. You should try and word suggestions in a way that aren’t commanding, but imply that there should be a change made. For example, maybe you keep on hitting your head on the skybox when you’re doing some perfectly reasonable explosive jumps. “Raise the skybox” doesn’t actually tell the mapper why they should raise it. “I keep on hitting my head on the skybox” or “The skybox is pretty low” tells the mapper that the skybox height is an issue, and they should reach the logical conclusion of “Raise the skybox.” It’s a subtle difference, but it’s considerably more effective (and therefore, more likely to make a change in the map). Also,the mapper might reach a different conclusion than the one you did, and provide a better solution than the one you had in mind!

Another situation: suppose that the map is particularly good for scouts. “I keep on getting killed by scouts” doesn’t help, because that’s a thing that could be very well attributed to the skill of the other team, a lack of skill on your own part, or just specific gameplay circumstances. “Way too many scouts” also falls into the same category. You’d be better off leaving something like “Map is too scout-friendly,” or better yet, “This layout gives scouts an unfair advantage.”

3. When feedback isn't needed

In some situations, careful wording isn’t the issue. Rather, the issue is whether or not you should even leave feedback at all. When a map is in alpha, the focus is on gameplay. Chances are, if there’s a cosmetic issue with an alpha map, the mapper either knows about it already and doesn’t care, or isn’t experienced enough that they should be worrying about it. Don’t leave feedback about cosmetic stuff on alpha maps, period. It’s a waste of your time and the mapper’s. Unless the mapper forgot to pack content and the missing materials/models significantly interfere with the gameplay, it’s pointless.

(Note to mappers: unless you’re trying to finish up a map in literal minutes before a test starts, there’s no reason to skip on packing or cubemaps. They do make the filesize a little little bit larger, but black and magenta checkerboards can get pretty distracting too.)

People really like to leave jokes in feedback, and there’s some situations where it’s totally okay. I appreciate a good joke that breaks up the monotony! For example, you might know the mapper personally, and they’d appreciate the joke. However, you should keep in mind that a joke is only funny if the person you’re telling it to finds it that way. If you say something like “kill you’re self” to a stranger, you’re going to come across as a jerk.

4. Acting human

There’s one final aspect of feedback that I’m going to touch on, and that’s the human aspect. Mappers are in fact real human beings! Bad feedback (vague, useless, or even rude comments) can be hard to take in stride, especially for new mappers. Bad feedback isn’t just something you can just filter out and ignore: it actually detracts from the overall quality of a test, much in the same way good feedback makes the test more effective.

That’s not to say it’s not okay to leave negative feedback! You can still be critical of a map without being mean. “You should remake this” is a lot less harsh than “Delete and start over.” “I’m not having fun” is preferable to “This isn’t fun.” If you want to point out that something isn’t fun but you’re not sure why, say so: “I don’t know why this isn’t fun, but it isn’t” lets the mapper know that investigation is needed. Also, “bad” just makes you look like a lazy idiot who doesn’t know what they’re talking about.

5. Summary

So, to summarize: Don’t tell mappers what to do directly. Instead, tell them why you came to that conclusion without actually stating your conclusion. It’s their map, let them draw their own conclusions (Mappers, don't be afraid to ask for help on fixing problems). You can leave negative feedback while still being supportive. Don’t be afraid to leave positive feedback. Leaving feedback on cosmetics for a map in alpha will only serve to irritate people. Lastly, we don’t just run custom maps for the fun of it. When you join a gameday, you’re there to test the map. Don’t leave half-assed feedback, because you’ll get half-assed maps in return.

No good and simple rule exists on how or when you should or shouldn’t leave feedback, because there’s really no good and simple rule on how humans work. Use your best judgement, and try to leave the best feedback you can. Remember, one of the best services this community provides over others is our ability to rapidly test and iterate maps through our gamedays and impromptu tests. However, the tests are only as effective as the people testing the map make it. If you want to get better feedback on your map, you can start by improving your own.

All feedback quotes in this article are either direct quotes or paraphrases taken from notes left via the feedback system. Thanks to Frozen for helping edit this!

A couple insights I've had into ways to make the feedback system work for you:

One, if you have a long annotation and really don't want to go into spectate, copy-paste is your friend. You can type the comment while in spawn and post it once you return to the trouble spot.

Two, the feedback page keeps posts in the order they were made, so feel free to make two-part annotations like "When I stand here..." "...this prop disappears prematurely." (Or something like that. Insufficient fade distances should be conveyable with only one annotation, but you get the idea.)

So, to summarize: Don’t tell mappers what to do directly. Instead, tell them why you came to that conclusion without actually stating your conclusion. It’s their map, let them draw their own conclusions.

Click to expand...

Counterpoint: I actually appreciate when more experienced mappers have an actual suggestion rather than a general comment to the effect that something isn't working, because I often have no idea what to do. If it's unsolicited, all the better! It means it was immediately obvious to them what ought to be done, and came from their better-mapper instinct. Even a bad idea sometimes sparks an idea to do something similar that's not so bad. But that's just me.

So basically, don't say X, say X but with barely different grammar and no meaningful difference.

Click to expand...

Basically, say X but don't say the whole alphabet, and without any attitude.

EDIT: Something else that I meant to mention to Ido when he was writing this: Ask questions. ALWAYS ask questions to the author. "Hey, you have this doorway here, I don't think it's very helpful, what was your reasoning behind it?" or "Hey, whats your vision for this map, whats the goal you're trying to achieve gameplay/aesthetically?" These can REALLY help you focus your feedback, instead of just giving generic feedback.

I would also like to add that if something is happening and you do know why, please tell the matter even if it's not a technical issue. e.g. "This area is really soldier friendly". Reason? "They can spam down from on top of building without contest". Don't leave the mapper to infer what you're saying later on.

Avoid making feedback off initial impressions. It's an old problem.. brand new map, no one knows the layout, and one team loses. Losing team instantly concludes that the map is slanted against them and whines for a scramble or floods chat with "this map sucks" complaints.

The first time you play a map you probably shouldn't feedback anything except maybe technical errors.

It seems to take players two or three plays of the map before they get used to the flow and start to exploit the map features to their advantage. Handing down a verdict in the first five minutes is completely useless.

It seems to take players two or three plays of the map before they get used to the flow and start to exploit the map features to their advantage. Handing down a verdict in the first five minutes is completely useless.

Click to expand...

On MvM even longer. In skullcove i repeatedly had the comment that there was no good spot to get away from the front. While at the same time i see no one using a certain door.

The comment i got was that they couldnt get away quickly from the front. Even though there was a door. The problem however in that case was simply that the door wasnt visible that well due to the map being dev textured.

Not all feedback even though correctly formed is actualy correct. That someone is flawed at some point could be because they simply didnt spot a thing.

In my case adding a border around that door already fixed the issue there.

But we can expand this. What if people dont know about a certain spot ment for cover. They might get killed by scouts alot while if they made use of that tiny corner scouts suddenly would get it hard.

Even though the shape hasnt changed, a simple texture change can throw over the balance of a map.

Good write up. I would add that there are 3 levels of feedback which are all useful:

1) What you felt while playing."It was frustrating attacking this point"

2) What you perceived the problem to be."There are too many long sight-lines"
3) Your suggestion to fix the problem."You should put more doorways here and block some parts off with rocks"

Usually I try and hit all 3 when giving feedback, because even if my suggestion sucks and I'm wrong about the real problem, #1 will always be true.

"It was frustrating attacking this point, because there are too many long sight-lines. You should put more doorways here and block some parts off with rocks"

Your guide flowed well and had good information. But at a glance it was exhausting because it is a wall of text. I'd recommend putting headings between sections, and itemizing your main points with bullet points.

This Guide was exhausting and I didn't feel like reading the whole thing, because it is a wall of text. A great way to improve it would be to put headings between sections, and itemize your main points with bullet points. Trim down unnecessary text, or at least leave long explanations between bullets that are easy to process.

Click to expand...

I understand that this was an example, but I wanted to add that it was written in good English and flowed quite well (and therefore was not painful to read), though Spud's ideas still apply.

I threw some headers in and did a few small edits. I need to go back and edit this more, but I wanted to get something out as soon as possible what with the beta maps that Valve just dropped on us. I really like your 3-tier feedback idea!