Yesterday I showed Flip to three developers. The Big Developer was annoyed by the flashing sign that said “Too many moves”. He likes to tinker with things, try out possibilities, and the fact that the game told him that he was already beyond the move count felt frustrating to him. The Medium developer mostly ignored the sign, because he is used to playing games that tell you when you are not going to reach your objective. He played and solved some levels, and others he just skipped. The Small developer was not even aware that a sign was flashing on … Continue reading Usability, Design, and the three bears
You are testing your game with someone. You see her not understanding what to do, having a hard time realizing that some feature is there, or just struggling to click on some object, and you feel bad. You feel like she is suffering because of you, too shy to say “I don’t understand this!” because you are there, and you want to ease her suffering. Don’t explain, wait. Unless what they are struggling with is not what you want to test, keep your mouth shut. Just tell them something: like “I will explain later, I promise, but now I want … Continue reading Quick Design Note: do user testing with eyes open and mouth shut
As a player, would you prefer to be told “to revert your previous move, click on the UNDO button located on the bottom left corner“, or for such a button to be clearly shown to you, and when clicking it (after being subtly induced to do that), seeing the result? From my experience, most players don’t like reading and will ignore a text even as short as that. And when playing, they expect an active experience (interacting) rather than a passive one (reading). The trick is to induce them to do something without telling them explicitly . But sometimes some … Continue reading Quick Design Note: show, don’t tell… unless you have to.
If you are hiring people to professionally test your game, then you can just tell them to ignore placeholder content, bugs, etc. They will (should!) professionally ignore them and report you on the things that you actually ask them. But when testing with “real” people, users who might casually try your game for just a few minutes, having features not in working condition is not a good idea. It will attract a lot of their attention, and it will be hard for them to ignore them, even if you ask them to. They will assume your game is broken, which … Continue reading Quick Design Note: don’t feed unfinished features to casual testers
Sometimes you try to switch the state of the game quickly to let the player “flow” fast and easily through it (people playing mobile games sometimes don’t have a lot of patience). Imagine in a puzzle game, when the player finishes a level, you drop her immediately in the next one. But what happens when you do it really fast, and the levels are similar? Many players will not understand that a state change has occurred, and will think that you just reversed their last move, or that they are still in the same. Stating that a puzzle was finished … Continue reading Quick Design Note: Make state changes explicit
If I have to choose the task that takes the most time for Flip, it’s without doubts the user interface / user experience. I go around everywhere with a tablet with the game loaded, and on every occasion I have, I ask people to try it and takes notes. And I take *Lots* of notes. I’ve probably already tested it with 30 people, and there is not a single time where I do not notice some improvement to make. And it’s not only about changing fonts or colors, it’s about people understanding what is going on without me having to … Continue reading Interface design for Flip