Foundations: Adding Feedback to Your Designs

So in my previous article Feedback is Awesome!, we looked at how feedback is the game speaking, and covered the various roles of feedback.

In this article, we’re going to focus on adding feedback to your designs, as well as share a few hard earned pearls of wisdom. While this article will talk specifically about games, the information can easily be applied to other areas of design.
Let’s start with a little process.

Adding Feedback Quickly and Cheaply

You do your best to design some good feedback. An artist and sound engineer get to work creating all the art, character animations and sound effects required. A programmer diligently stitches it all together. Finally, you put it in front of a playtester - and they’re more confused than before you started! Crap! Removing the feedback wastes all that work! Tweaking it might save it, but will definitely take more time.
Don’t end up here. It sucks.

Rest assured that smarter people than you and I have fallen into this trap. The important thing is to learn from their mistakes, find a better way to recover from bad decisions and guarantee a good end result. Let’s talk about the No More Tears™ approach - or more correctly - Agile.

Fail Early

Perhaps the most important thing you can do as a designer is accept the notion that your best ideas may fail. Let me reiterate that in a huge font with fancy quote style:
Perhaps the most important thing you can do as a designer is accept the notion that your best ideas may fail. - Daz, 2011
Design is hard! You can’t know everything before it’s built - before you can interact with it. Thinking otherwise is arrogant and likely to get you in hot water. Failing is okay! The real test of designer is how they take risks, and how they learn from failures.

By accepting that you awesome design may in fact be rubbish, the challenge becomes “How quickly can we build and test this unproven idea?” If it fails miserably, that’s fine. Hopefully you can see WHY, learn from it and try a new idea. If it works, you can move onto making it pretty and efficient. This is rapid prototyping.

As you gain confidence working on a project, this becomes less important. If you’ve added 5 different damage effects to your game already, you may not need to prototype the 6th. You’ll get a feel for it over time. Essentially, the less likely it is that a design will work; the more important it is to prototype and fail early.

Placeholder Feedback

What’s the best way to test new feedback quickly?

Add a placeholder! Recolour and reuse an existing particle effect. Flash the character’s model bright red. Play an obnoxious WAV you scored off the internet. Replace the player’s face with a giant cube momentarily! It doesn’t matter. The important thing is that you get your feedback in there quickly and cheaply, and prove that it makes the game better.

(This goes for the coders too! Refactor it later!)

Don’t Expect it to be Better, Later

If your placeholder isn’t fun now, don’t rely on art and sound to make it better, later. While your feedback will probably improve, it may not jump in quality as much as you were hoping - it might not become fun.

Try to make it as fun and cool as you can when it’s still ugly. What’s missing? What’s working that could be emphasised? What could you try quickly before moving on? What would [Blizzard / Nintendo / Valve] do?

When your ugly feedback is great fun, and you decide to take it to the next level, nice art and sound will be icing on the cake!

Cool Ugly beats Lame Pretty

@joearthur_dog is cool
Cool cool.
This is the corollary to the point above.

Often in the process of adding “proper” art and sound assets to placeholder feedback, something of the original’s impact or coolness can be lost; it’s not as funny; the impact isn’t as strong; it’s just not as fun.

This is bad; and it’s your job to fix it! You should identify what’s cool about the prototype feedback and work to preserve it. This is tricky if you used a Mr. T. quote as feedback for collecting a medkit - and you’re searching for something equally cool - but you’ll definitely learn from it!


You’re playtesting your designs, right? And not just when the game is finished?

The sooner you playtest the better! Rather counter-intuitively, playtesting is a great way to save time, money and effort. It allows you to see if your design is working early - buying you time to make course corrections if it’s not. Playtesting removes the guesswork - you can’t assume something will work when every single playtester fails to understand it. Better you know now, right?

For now, just observe a friend playing your game.
  • They should be completely fresh to your game.
  • Let them know you’ll be observing silently. Don’t speak. Don’t answer questions.
  • Sit behind them or somewhere where they can’t easily see you.
  • Write down anything they seem confused about. Write down any questions they ask.
  • Before starting, encourage them to verbalise any frustrations they have - write those down too.
  • Let the test go until they decided it should finish. Don’t stop because you’re uncomfortable - being uncomfortable in playtests in one of the best motivators for fixing issues. Hopefully the next playtest won't be so horrible.
That should give you heaps to work with! Don’t be afraid to let them see your ugly placeholder feedback - they know the game isn’t finished. Hopefully they understand quite a lot, and you can quickly see what isn’t working.

I’ll try to cover playtesting in detail at some point - it’s powerful stuff! If you can’t wait, Valve has released some excellent info on their processes, available here.

When Should Feedback Be Added?

Now that we have a process for adding feedback, let’s talk about deciding what to add.

You’re adding a new feature to your game- an enemy, a weapon, a llama-mobile... whatever. What feedback does it need? Why add that feedback?

Terrible reasons to add feedback

  • Because StarCraft does it. Don’t blindly copy feedback from other games. Mindlessly copying feedback from other games may come back to haunt you when players are confused by it, or it conflicts with other feedback specific to your game. If you understand the message it conveying in StarCraft, and it applies to your game, then you’re not mindlessly copying.
  • Realism - because it does that in real life. This is an awful reason to add feedback. Just because a bullet hit wood doesn’t mean it needs to sound like it hit wood. Just because you have a dog in your game doesn’t mean he should bark all the time. Just because people seldom stand still doesn’t mean you should add a bunch of idle animations. Feedback is there to serve a purpose; to speak to the player. Real world sound and visuals simply don’t follow the same rules.
    The next rule is somewhat of a caveat to this one...

Acceptable reasons to add feedback

  • Seems really silly without it. Sometimes the absence of feedback can become distracting. You’re working on a kart racing game. Someone points out that the kart’s wheels don’t spin. Players get feedback about their current speed form the engine sound and their speedometer, so spinning wheels aren’t going to convey anything new - but it looks plain stupid. Sometimes it’s just easier to add “unnecessary feedback” than have players distracted by the trivial. This is a risk of dealing with real-world, or very familiar, subject material - if players have strong expectations for how something should behave, you run the risk of needing to add unnecessary feedback.

Good reasons to add feedback

  • There’s teaching to be done! This is a great reason to add feedback. Teach away! The more important the lesson, the more obvious the feedback should be. For example; “That just hurt you!” is usually more obvious than “That just healed you.”
  • The player is confused by something. This is similar to adding teaching feedback, but you’re usually doing it as a result of playtesting. Often this is a case of trying to highlight relationships between elements in the game that the player has simply missed, or making existing feedback more obvious. Examples; collecting an item makes its corresponding UI element animate obviously; the player’s character goes green to show he’s poisoned because the word “Poisoned” on the health UI is easy to overlook.
  • Something is important and the player needs to be alerted! This active feedback is the smoke alarm of game design. Players playing your RTS may be irritated to discover that a single unit has wiped out their base - adding feedback to alert them that something is attacking their base may solve this. Be careful though; chess players may not appreciate an “Impending checkmate!” alert warning their opponents - sometimes the skill lies in assessing threats.
  • Confirming player input. Find ways to reassure players that their input has been heard, even if it isn’t going to result in anything happening. For example; if they try to open a locked door, include a handle-jiggling sound. Don’t leave them wondering if their control pad is broken.

A Focus on Problem Solving

Going a little further into why you might choose to add feedback; consider the following.

At its highest level, the process of designing feedback is about identifying what important information about the game the player doesn’t know, and deciding how to communicate that information.

I strongly believe the best approach is to clearly define the problem (“The player keeps dying because they don’t know how much health they have”) and then design one or more feedback mechanisms to solve that problem - a health bar (“You have exactly x% health”) and a zelda-style low health warning (“You are below 20% health!”).

So if feedback is added to solve an underlying problem, then the more clearly the problem is defined, the easier it is to devise the right feedback. Consider the following example problems, sorted from uselessly vague to helpful:
  • The player keeps dying.
  • The player doesn’t know how close to dying they are.
  • The player can’t make strategic decisions because they don’t know how close to dying they are.
You always fare better trying to fix a clearly defined problem than you will a vague one. Luckily, you can repeatedly challenging a poor problem definition with “Why?” until you uncover the detail necessary to really solve the problem.

A problem based approach has additional benefits:
  • You can easily sort problems by severity and focus on the most pressing issues.
  • Playtesting is all about uncovering problems - so the better you are at problem solving, the more responsive you can become to playtesting.
  • When playtesting, it’s easy to see if a problem has been solved. It’s much harder to see if particular feedback has worked.


Hopefully you now have a better idea of how to go about adding feedback to your game, and with any luck, will avoid some of the bigger feedback traps.

In the next article I’ll put some of these concepts in context as I attempt a post-mortem of a game from my past.

In the meantime, does any of this advice above ring true for you? Have you added ugly or stupid placeholder feedback that people went nuts for? Have you invested too heavily on a feature and had to painfully cut work and retool? Let’s hear those horror stories!



Post a Comment