A Practical Guide to Improving Feedback Communication
TL;DR: Use a feedback framework to better communicate with your teams. Break your feedback into categories and set expectations for how recipients should use the feedback and how to respond. Consider a three tiered system, called DFN:
Direction (requiring action)
Feedback (requiring response)
Note (requiring no response or action)
Direction/Feedback/Note Framework
As the Proletariat team scaled I wanted to stay involved with the product and design teams. During product reviews or creative meetings I considered myself a member of the product or design teams, not the CEO of the company. My title would have more weight than intended and it often led to an offhand comment I made becoming a high priority task. That is not what I wanted. I needed a shorthand way to give feedback that would convey priority and required action or response.
The DFN framework is not something I can take credit for, but I did use it many times. I found categorizing my feedback was helpful for both the recipient and for me. I would categorize feedback like this verbally, written, and visually, like on screenshots. When providing written feedback, I would color code the categories to make it even easier to understand.
Direction
This is the most forceful category of feedback. Direction requires a change or action, typically in a specific way. When I would give direction I would always include a suggestion on the action to be taken. The recipient of direction is not required to take that suggestion but follow the direction given and make an adequate change.
Example: “This area of the map is too open, it should be more enclosed. Consider adding some additional trees and reduce the width of the path. We want the player to feel claustrophobic.”
In this example it is acceptable if the recipient comes back and says “I don’t want to add more trees, but I will create a ledge here.” If that still satisfies the goal of making the player feel claustrophobic then it worked.
It is not acceptable for the recipient to come back and say “I don’t want the player to feel claustrophobic here”. If there is a disagreement at that level, it requires a deeper conversation on the vision for this area of the game. If I was frequently giving direction to the same person it was an indicator of underlying disagreement or misalignment on the vision.
Feedback
This is the most common category of feedback I would give. This does not require a change or action, but it requires a response. I would sometimes provide a suggestion as part of this feedback, but not always. The recipient is allowed to push back on the feedback directly or to find their own way of addressing it. Either way, it requires a response and follow up.
Example: “This jump is really hard to make. Should these ledges be closer together to make it easier?”
The recipient of this feedback can simply push back on changing the distance of the jump if they think it is the right choice. However, a follow up conversation was needed for the individual to make their case. I would tend to allow people on the team the freedom to make their own calls with this category of feedback. That would change if this feedback was given by multiple people or in cases where we had data to indicate a change was needed.
Note
The last category of feedback is what I would consider coming from a player or user. This is how I felt as a player, not as a developer. Notes rarely would include suggestions and do not require a change, a response, or a follow up from the recipient. This is for the recipient to consider and internalize on their own.
Example: “There are not enough power ups in this area so I spent a lot of time frantically searching for health packs.”
This is a note because it may be intentional and what the designer wants the player to feel. It might also just be a gut reaction from a single play session. I would trust the individual to get notes from many people on the team, distill it down, and use it to help them improve their area of the game.
Final Thoughts
A feedback framework like this one is only valuable if it improves communication across the team. It should be one tool leaders use to cultivate the feedback culture they want in their creative, design, and product teams. If you can’t describe the feedback culture for your creative/design/product team, it may not have one, and that is the first place to start.
This specific feedback framework may not work for your team or culture. Find a structure that allows the team to provide feedback that doesn’t overwhelm, contradict, or confuse the recipient and ensure the recipient knows how they are expected to respond.