Client Feedback Form

A large part of being a designer is receiving, analyzing and acting on feedback. Sometimes this feedback comes from playtesters and peers, and sometimes it comes from clients, IP holders and stakeholders. This final group is really important as, more likely then not, they are providing the resources to continue the development of the game. Because of this, it is critical that we have a clear understanding of their feedback and expectations.

This is my favorite format so far for communicating feedback with a client

Let’s break it down:

• Date Given — when the feedback was received.
• Requested by — which stakeholder gave you the feedback. In complex projects you might receive feedback from several places: the IP holder, the platform, the client, etc… As mentioned in the GD-1, their goals with the project don’t always align.
• Milestone phase — Which stage of development the game is at (Concept, pre-production, production, etc…)
• Feedback — The actual feedback you were given.
• Priority — How important this feedback is. You can use numbers (P0 being critically important, P3 being less important) or you can use ‘Must Have‘, ‘Should Have‘ & ‘Nice to Have‘. This is set by whoever gave the feedback.
• Risk — How risky is the ask. It is important to highlight potential issues as soon as possible, so everyone is on the same page. If there is risk, it should be explained in the ‘comments’ section. This is set by the development team.
• Dev Team Status — Many times the feedback needs some work in order to better understand what the best course of action is. For example, if someone tells you the tutorial is bad; you’ll need some time to figure out why and how to improve. In this column we write down what is the status of the team in addressing the feedback. The categories I use are:
  • Accepted — We’ve accepted the feedback and will work on it.
  • Won’t do — We’ve rejected the feedback (be it because of cost, complexity, design decisions, etc…) and won’t work on it. If you do this, make sure to state why in the ‘comments’.
  • Evaluating — We are currently assessing what the cost of implementing the feedback will be.
  • Done — The feedback has been acted up and is in the game.
• Scope — This is how long it’ll take to implement the feedback. I like using days (with 0.5 days being the minimum unit), as it is easy to understand by all parties.
• Client Status — Similar to the Dev Team Status but from the client’s side, this column let’s us know what they are thinking with respect to the feedback status:
  • Scope Approved — They agree with the cost (in work days) required to implement the feedback.
  • Status Acknowledged — They have seen the Dev Team Status and agree with it.
  • Status Contested — They have seen the Dev Team Status and feel it is not appropriate; if you see this contact the client and talk to them asap to see what’s going on.
  • Evaluating — They are currently assessing if implementing the feedback is worth the scope cost.
  • Scope Rejected — They agree with the assessment of scope, but feel that it’s not worth the cost to implement the feedback.
• Comments — This is where we add all the notes and thoughts exchanged in the discussion of feedback. It is important to date any additional comments to later be able to follow the flow of conversation.
• Acknowledgment Signoff — This is a simple column where the client can initial their names on feedback they’ve seen. This is important when sending the feedback tracker back and forth, as then you can make sure that the feedback’s scope and details were received.

This format is kept in a single sheet throughout the length of the project and is made into a table where it is easy to filter based on any parameter in the column. This will be a lifesaver later in the project when you want to track when and why a decision was made.

I first saw this format while working with Katherine Archer at Archiact Interactive.

There is a specific back and forth while using this format:

1. Receive the feedback. This can be either in a meeting, game screening, via email, etc…
2. Record the feedback into the format. Fill in ‘Date Given’, ‘Requested By’, ‘Milestone Phase’ and ‘Priority’
   • If the stakeholder has not given you a priority, send a follow up message requesting it.
3. Discuss the feedback with the team, brainstorm potential solutions and discuss scope.
4. Fill in the ‘Risk’, ‘Client Status’, ‘Scope’ & ‘Comments’ sections.
   • If there are unknowns that need a larger amount of time to figure out (for example technical limits), set your status to ‘Evaluating’. It should not stop you from sending the form.
5. Send the feedback format to the stakeholders. They should fill out the ‘Client Status’ & ‘Ack. Signoff’
   • It should take less than 48h to send the feedback tracker; preferably less than 24h.
6. Once you’ve received the format back, you can divide the feedback into tasks and triage them with the team.

Let’s imagine that we are working on a new rhythm game that uses a new hand tracking device like the Leap Motion Controller. The platform holder, let’s call it JUMP, is paying your company to make this game as it is part of their launch lineup.

Your team has made a vertical slice of the game and, during an update meeting, JUMP’s representatives have given you the following feedback:

1. The tutorial feels too linear
2. The keys don’t seem to align with the music
3. They just updated the controller’s firmware and it can now detect two-finger gestures. They’d like to see that in the game.

So first you add this to the tracker:

Your team then gets together and discusses potential solutions. After much debate, the following conclusions are reached:

1. The linear tutorial is by design. Given that it is new technology, it’s important for players to understand its use correctly. We could implement a “skip tutorial” option for impatient players. This would take 1 day of implementation & testing and would be ‘medium risk’.
2. This had been noted by internal QA before the meeting, but there was no time to address it before the meeting. Designers estimate it would take 2 days to polish, but it is ‘low risk’ as the tools were already there.
3. Adding new gestures is a big ask. The way the game’s architecture was designed with single finger input in mind. The programmers could go in and change this, but it might cause instability and unwanted side-effects. Regardless, the design team would need some time to figure out how these gestures would integrate in-game.

With all this in mind, the tracker looks like this:

You send this to the stakeholder and after a day you get back the following tracker:

Notice the extra comment on the third item. This indicates that, despite the risk, this is an extraordinarily high priority for them. With the tracker in hand, you can assign tasks to your team to work on item #2 and to do some design conceptualization for item #3. Once that’s done you’ll have to set up a meeting with JUMP and discuss the cost of implementing the new gestures. Surely there will be some back and forth on this topic, so be prepared 😀

---