[Post-Mortem] What "You Fix Spaceships!" Taught Me About UX
First off, hello! :smile:
We are a team of two (my sister and I).
And we made This Little Game which is half about managing a space kiosk, and half about doing some introspection.
If this sounds like your cup of tea, give it a try before reading on - 'cause there will be spoilers below :stuckouttongueclosedeyes:
Why I Care So Much About UX
One of the most important things to me in a game, is game feel. The way a good game can immerse you, make you feel what the author intended you to feel? I love that in a game. That's what (in my opinion) is the mark of a great game.
But game feel is a topic that has been talked about to death, and frankly, I think good UX design deserves so much more credit than it gets.
Just to make sure we're on the same page, here's what I mean when I talk about UX: Games with a lot of good 'game feel' can be fun to play. But in order for them to be fun to play, the player has to know how to access that game feel.
Think of it as, say, instructions for how to have fun.
Take Super Mario as an example. One of the main mechanics in the game is how when you have a question mark block, you can hit it with your head to get a coin or powerup pop out. This mechanic feels good. It's fun to hit question mark blocks with your head.
(Above: Punching a Question Mark block in Super Mario. Definitely not from our LD entry.)
But what if you had no idea you could hit the question mark block in the first place? Sadly, you'd likely miss out on half the fun in a Mario game.
But then the question becomes, how did you know you could do this? The original game didn't come with an instructions page, did it not? You just sort of... knew.
Of course, having the text "you can hit question mark blocks with your head" in the main menu screen would also be a way of telling the player they can do something. A screen full of instructions is definitely a type of UX. But the Mario games somehow managed to do without it. You simply look at the block, and somehow, maybe because there's a Question mark on the block, or maybe because of Mario's limited movement, you instinctively want to hit it with your head. And that's how you learn you can do it, no instruction screen needed.
And that's why I appreciate the magic of good UX.
My Rules of Thumb when Designing UX
I'm no expert when it comes to UX. I have only a fraction of the experience of what I'd want.
What I do have is a couple rules of thumb. A checklist of sorts, things to look for when playtesting, to make sure players don't miss out on different parts of the experience.
It was difficult for me to articulate my mental checklist, but I think the following more or less sums it up:
1. Existence: Did I forget to tell the player about anything I want them to know?
2. Clarity of Existence: When the player receives feedback, is it possible the feedback will be missed?
3. Interpretation: When the player receives feedback, is there any chance they might misunderstand it?
What I'd like to do now, is take each item in the checklist and give examples from our game in this jam - considering both things I believe we did well, and things we could have done better.
Of course, this is both going to constitute of huge spoilers, and also assume you're well versed with the contents of the game - so if you're planning on reading on, I recommend you give it a quick play before continuing. I promise, it's not long. :)
So if you wanna: The link to our game entry is Here. :heart:Post Mortem & Lessons for the Future
Okay, let's break it down. Here's what I think we did better and what I think we did worse:
:one: Existence
(Did I forget to tell the player about anything I wanted them to know?)
Regarding the INSTRUCTIONS
As a rule, I like my games to have as few text-based instructions as possible, while still making them clear to the player. I feel like text-less instructions makes them more accessible to people who don't have the energy to read a wall of text (or even a short paragraph). And if done well, it will definitely make a game feel more immersive.
In our game the controls are entirely communicated by the drawings on the game frame, and a couple words drawn in graffiti on the mechanical blinds. And honestly, I feel like that went over mostly well (but more on that when we talk about Clarity of Existence).
Regarding the PAUSE MENU
There is a pause menu that you can enter and exit by pressing Q. They make both the timer and the tile-swapping mechanics freeze, and only continue once the blinds have gone all the way to the top. Unfortunately, the top of the game frame is not the top of the screen, and as such it can be a little confusing as to when precisely the game is about to continue.
In order to mitigate this, we issued three different types of feedback:
- A strong sound effect marks the end of the blinds moving up. A sort of bang, indicating that the blinds have hit the top of the screen.
- On the bottom of the screen, the flower pot shakes a little when the bang happens, giving a sort of visual indicator in case you weren't paying attention to the audio. (And honestly I think it helps that the flowers are on the bottom of the screen, since it gives you a visual indicator even if you weren't paying attention to the blinds)
- The white rectangular frame marking the currently selected tile in the game disappears from view the moment you press Q to pause, and reappear only the moment the blinds end their animation to show you that you're allowed to keep playing.
Before we added all of these effects, I felt awkward whenever exiting the pause menu, feeling a little uneasy as to when I could keep playing (which was especially important considering the short time in which I have for the tougher spaceships). But little by little, as we kept adding these, entering and exiting the pause menu felt like a much more comfortable task, and I could do it without worrying as much as I used to.
Regarding the END OF THE GAME
This was, I believe, one of the worst UX mistakes we've made in this game.
At the end of the game, after the man-eating planet leaves the game area, an ending animation begins: It starts with the blinds automatically closing, and (without giving out too many spoilers) ends with the game closing on it's own. No user interaction needed.
And on an unrelated matter, as part of the game instructions, there is graffiti on the blinds telling you you can press Esc to immediately close the game.
Unfortunately, those two put together turned out to be disastrous. When the blinds closed in the ending animation, the graffiti saying "Press Esc to Quit" appears. And since players understood that this animation meant the end of the game, they immediately pressed Esc, completely missing out on the rest of the end-game animation.
This was a thing I completely missed out on when playtesting myself, and we only realized after the end of the jam, when letting a few of our friends play the game.
Circumventing this would have been easy, of course: We don't even have to change the graphics. Off the top of my head, we could simply not have the Esc button work during the end of the game. But the fact of the matter is, we didn't notice this, and that robbed a lot of players of a part of the game experience that I really feel ties the whole thing together.
:two: Clarity of Existence
(When the player receives feedback, is it possible the feedback will be missed?)
Regarding the TIMER
There is a timer on the bottom of the screen telling you how long you have until the end of the round.
And despite it containing all the information it should contain, I frankly don't feel like it pops out enough. Post-jam, I've had some friends playtest, and a few of them didn't even notice the timer existed until a few rounds into the game. This is not such a big deal when they managed to fix a ship, but whenever they failed they would end up very confused as to why the round ended (and I'd show them the timer and suddenly things would make more sense).
A couple ideas that I feel would make the timer pop out to make players more aware of its existence: * Beeping or ticking sound effects that go with the timer counting down. The existence of a sound effect make a player instinctively look around for the source of the sound, and when they see the timer animation matching the ticking, they'd know it's important. * A visual blinking or animation of sorts to exaggerate the timer's existence when the countdown is nearing zero. See, even if you know the timer exists, it's easy to forget about the countdown when you're immersed in a puzzle. Having some sort of indicator when the countdown is almost over would be a solid reminder, and would definitely prevent some confusion if the round suddenly ends and you weren't paying attention to the time.
Regarding the GRAPHICS DEPICTING GAME CONTROLS
Consider how the game teaches you about controls: On the bottom right, you have a drawing of the Arrow Keys and the Z Button. On the left, you have a post-it note with the letter Q.
Optimally, I'd want players to first learn about the Arrow Key + Z controls, and only afterwards learn that Q starts the game. This is for two reasons:
- These are the more important keyboard controls to remember, and players will most likely remember the first thing they learned rather than the second.
- If a player decides to experiment with pressing keys, I don't want them to accidentally press Q and have the game start before they learn about the Arrow Keys + Z controls. Once the game starts, not only do they have to already be ready to play, but also the game itself pops out much more than the button drawings on the bottom right, and players might miss it out completely.
But as it turned out, quite a few players did the opposite of what I'd hoped: They read the "Q" post-it note, then pressed Q, completely missing out on the Arrow Key + Z controls, forcing them into having to learn them on the fly.
This wasn't too disastrous, as the first spaceship is very easy to solve (for reasons such as these). But it makes me wonder if maybe we could've noticed it earlier and done better.
- The most glaring issue in my opinion is that the arrow key graphics simply don't pop out as much as the post it note, making the post-it note the priority when players read controls.
- Another issue might be that the post-it note is on the left, and players might have a tendency to scan the bottom-left of the screen before the bottom-right, an instinct matching the way text in English is written.
:three: Interpretation
(When the player receives feedback, is it at all possible for them to misunderstand it?)
Regarding the Z BUTTON
In the game, you need to press Z twice to make a swap. The first Z press marks a tile, and the second press picks the tile to swap with. If for some reason you want to cancel the first Z press, you can make your second Z press on the same tile as the first.
This was not how the game worked for a majority of the time we worked on it during the jam. Originally, we had two buttons: Z and X. Z would select a tile, and if you wanted to cancel a press, you could press X.
The graphics depicting the controls were pretty much the same:
If you would please ignore the lack of transparency making the borders of the image look weird, here is what we had planned:
We thought this was a great way to teach the player about the UI - the Z was green to tell you this was the primary action, and the X was red to give a bit of intuition as to the fact that it could cancel.
Then at some point during the jam we gave the game to a play-tester, and he did something I did not at all expect: After selecting a tile with Z, he tried selecting making the swap by moving to a second tile and pressing X. Not Z. But rather X. And that's when I realized that my love for minimalist instructions carry really big consequences - it's my job to make sure that there is only a single way to understand instructions. Ultimately, this was done by getting rid of the X button completely.
In retrospect, this was a hilariously obvious design move: Not only did the X button rarely have a reason to be used, but the Z button could be used to simulate the same action (by pressing the same tile twice).
This just goes to show, it's very important to let other people test your game. Hopefully I will get better at this with experience, but I truly think that in this jam, had I not had a friend try out the game mid-development, I would've had no way to discover that the X button might be misinterpreted in the way that it was.
Regarding DOTTED LINES AND OTHER TILE INDICATORS
This was a point we had planned on addressing during the jam, but it got sidelined and we never got around to it.
Some of the spaceships are not standard tile-swapping puzzles, but rather there are a couple tiles with items, and you have to place the items in the correct places to fix the ship.
In order to show the player where each item has to go, we marked the places where things should go with some dotted lines or thin bordered versions of the objects that you have to move around.
Here is one example:
There are two main things which I think we could've done better:
In the first example, the dotted lines are very bright. It might not seem so on this post, but turns out that on some computer screens the dotted lines for the nose blend in very well with the spaceship's face, causing some players to completely miss out on the existence of the dotted lines.
In the second example, the red squiggles blend in even better with the color scheme of the real parts of the spaceship (which is already bad). But to make matters worse, the squiggles weren't dotted, which made some players not understand that the red squiggles were the target drawing, and not part of the drawing itself.
Of course, this is all made worse by the fact that these markings have an inconsistent style. The fact that sometimes we use bright green dotted lines and sometimes thin red non-dotted lines is a great recipe for confusion.
As I mentioned earlier, these were all things we originally planned on taking care of (we have alternate art ready for some of the spaceships that makes these things much clearer). They didn't end up in the game solely due to time constraints. Although I do admit, that if we knew ahead of time how much issue would end up affecting user experience, we might have made it a higher priority to fix.
Wrap Up and See Ya
I'm writing this blog post half because I wanted to share my thoughts, but also (and just as much) because I feel that rigorously analyzing a game's UX is the best way to practice UX design.
Whenever I play a game, or try out a new phone app, I try to pay attention to these little details, try to figure out what the UX designer was thinking behind the scenes to make the game/app work as well as it does, and try find things which I believe would improve the UX.
I completely mean it when I say that analyzing UX that was created is a great exercise (maybe even as good as actually building the UX) and so I encourage you to do the same - both to your games and to others' games.
Feel free to drop a comment telling me about what else we could've done better from a UX perspective, and/or just to tell us all your thoughts about UX design in general. I'd love to have any discussion on the topic :).
Until next time! :yum: :calendar: