Jump to content
Site Stability Read more... ×
  • Advertisement
  • 10/01/18 12:37 AM

    7 UX Lessons From The Trenches

    UX for Games

    • Posted By PaulSim

    This article will be a run-down of several UX / UI-flow lessons we learned by carefully observing a couple of hundred people playtest an early build of our game Steamhounds at live events recently.

    The Steamhounds expo demo setup (AKA "the trenches")


    For context, Steamhounds is a turn-based game, mixing JRPG and tactical/grid-based combat. Players can battle against the AI, but we encouraged them to compete against their friends (sitting side-by-side in front of a pair of monitors) whenever possible.

    Now, our game’s basic layout and presentation of information were not terrible going into this whole experiment. Experienced gamers and players familiar with the genre generally had no problem getting up to speed without any back-seat driving on our part. But at these live events, there are people who may have never even touched a similar game before, and these players can reveal a lot about the hidden quirks and assumptions in your design.

    Anyway, without further ado, on to our observations:


    Problem #1: People Don’t Read Text

    I think most devs are aware of this one. A surprisingly large proportion of players will skip through any text you put in front of them. We observed that the vast majority (>80%) of players would click straight through the instruction screen we added at the start of the demo, which explains the basic flow of the game:

    How-to-play menu.  Only 20% of players bother to read it (and then 100% of them win their battle)


    We’re guilty of this too – honestly, who bothers to read the manual when you buy a new gadget? The expectation is that if something is user-friendly, then you can learn how to use it more or less entirely by intuition and experimentation.

    We anticipated this, but a bigger issue is that once in-game, many players also skipped over our on-screen prompts. This impacted player experience most seriously when they didn’t notice instructions which tell them what they need to do next:

    Teeny tiny 'select position' prompt


    The Solution

    We know that on-screen text is generally the last thing players are inclined to turn to when they are stuck. So, let’s make it impossible to miss:

    New all-singing all-dancing 'select position' prompt


    We use movement to draw attention to the prompt as it appears, and then keep it animating until the player follows the instruction.

    The text was simply too hard to notice before. By forcing the player to pay attention to it, we practically eliminated instances of players asking “so, what do I need to do now?”.

    We could probably improve this further, by having the animation and positioning of the text draw the player’s attention in the direction of the tiles which they need to click in order to select a position.


    Problem #2: Interactable Stuff Needs To Be Clear

    Let’s get the obvious part out of the way: buttons should look like buttons, and it should be clear to the player what choices are available to them at any given moment.

    In Steamhounds, the player needs to select an action from a menu on their turn (some kind of ability like “ranged attack” or “defensive stance”). When this happens, a menu pops up:

    Expanding radial menu


    This works great – there’s a distinctive sound cue, and an eye-catching spinning animation as the menu expands to fill most of the screen. Nobody has any trouble realising that they need to click one of these buttons. The issue is that after selecting an action, the menu disappears and the player needs to select a position on the battlefield in order to target their ability.

    We observed that some players would get stuck here, searching around the screen with their mouse, looking for something which could be interacted with:

    A player hunts around looking for something to click on, their frustration increasing by the second


    The Solution

    Although we highlight the clickable tiles, this is somewhat subtle. It’s made worse by the fact that players often look briefly towards their opponent after selecting an action, not noticing the tile highlights appearing. So, here’s our fix:

    Flashing tiles attract the player's attention


    If the player doesn’t hover over a valid tile for a while, we make them flash.

    This simple change had the intended effect – at the next playtesting event, we rarely had to prompt a playtester to let them know that they needed to click on a tile to continue. We’re once again applying the well-known principle that movement/animation can be used to draw attention. Once the flashing draws them in they inevitably hover the mouse over one of the tiles, and the subsequent highlighting makes their purpose clear.


    Problem #3: Calls-To-Action Should Be Immediate/Contextual

    Indies often talk about the idea of a “call to action” when marketing their games – you want people to “sign up for the mailing list!”, “wishlist the game!” or “leave a review on Steam!”. But there are also moments in-game when you want the player to make a choice or perform a particular action. So why not apply some of the same principles, making the next click or decision the player needs to make as clear as possible?

    Before a battle in Steamhounds starts, players need to set the starting positions and stances (“formation”) for their team. The flow for setting up the formation is not immediately obvious to all players.

    This is what the screen used to look like:

    Boring, wordy instructions for setting your formation


    While this tells players everything they need to know in order to set the formation, there are a couple of issues – (a) players don’t read text, and (b) the instructions are presented in a single block, which doesn’t really feel like a clear call to action. Not great.


    The Solution

    Since we already implemented fancy attention-grabbing animated text, why not use it to break up this intimidating block of instructions?

    Step-by-step, context-based instructions


    Now, we guide the player through the process step-by-step, first to “click a character to set their stance”, then to “select stance”, “select position”, and so on.

    Use contextual prompts which tell players what they need to do right now. This way, they are guided step-by-step through the whole process, and not put off by long sequences of instructions.


    Problem #4: Terse/Technical Language Needs To Be Used In Moderation

    As students of game design, we’re all comfortable with the kind of hyper-specific language used to convey game rules. You know – the keyword-laden stuff you find on a Magic the Gathering card or in a board game rulebook – “targets one creature”, “discard 3 cards”, “hits all adjacent characters”. If you’re used to this language, these instructions are perfectly clear and unambiguous. But I’m sure you’ve had experiences playing games with more casual players, who sometimes interpret these rules in ways which your designer-brain tells you were clearly unintended.

    In Steamhounds, most of this rules-heavy text is found in the tooltips which appear when you’re selecting one of your character’s abilities to execute. Our first instinct was to keep these descriptions as short and direct as possible – after all, we don’t want giant multi-line blocks of text in these tooltips – so we tried to keep them down to one, or at most two, brief sentences:

    Satisfyingly short, but problematic description of the 'focus' ability: 'gain focus'


    Seems fine, right? But we noticed that this ability was being underutilized by players.


    The Solution

    We think the main reason behind the unpopularity of the Focus ability was this: players who didn’t carefully read the rules presented to them previously didn’t have the context needed to understand its significance or benefit. Lots of players will skip through the rules introduction, and hovering over this button will be the first time they encounter anything relating to the “Focus” mechanic. So, we made this change:

    A slightly elaborated description: 'Gain focus. Unlocks your most powerful abilities'


    It’s a bit more wordy, sure. But we noticed an increased rate of people using this ability. The new text both “sells” the ability to the player, and provides additional context so that they can understand its significance, even when viewing this tooltip in isolation.

    The general principle we’ve learned from this is to describe things in ways which sound cool or attractive and try to make the basic mechanical effects clear without assuming players have internalized information presented elsewhere.


    Problem #5: People Have Preconceptions About Certain Words

    We made some interesting observations about how the language we used caused certain players to interpret rules text in unexpected ways. It seems like this is the result of the ingrained associations they have with particular words.

    Old description for 'Vigor Potion': 'Pick a target. Their next attack deals double damage'


    What’s the problem here? The word “target” has a connotation of aggression.

    “Target” is often used in rules text as a neutral term for anything targeted by an ability. Experienced players are very used to this, and understand that the ability pictured above is clearly a buff which you would use on your own characters. But the association between the word “target” and an offensive action was so strong for some players that they would understand this to be an ability which you would use on an enemy, causing the next attack against them to deal additional damage.


    The Solution

    It seems like we may need to move away from using such technical language. Here’s our fix:

    Refined description: 'Power up an ally. Their next hit will deal double damage'


    As a designer this is a bit painful – it feels a bit unnecessarily verbose. However, we observed that this new text basically eliminated confusion about how this ability worked, and players stopped trying to target it against their enemies. Devs should consider their desired tone and target audience, and find a balance which works for them. Overly long rules text is surely a problem, but being slightly redundant is an opportunity to reinforce your game’s tone and character.

    The lesson here: observe playtesters to see if your choice of language has any unexpected implications. Even among English speakers, this can absolutely vary by culture.


    Problem #6: People Have Associations With Certain Colours

    This is similar to the previous subject about the connotations of words. Colours are also associated with certain feelings or concepts. We were already attempting to make use of this, by highlighting tiles to show the effects of abilities. Red for aggression, green for support/protection, etc.

    Scary red tile highlights


    For the most part, this works fine. But there was one association which we didn’t anticipate, which tripped up a couple of players. They associated red not with aggression, but with something being invalid. So when they hovered over a target to attack them, they were confused because they thought the game was telling them that they couldn’t target that character (in reality, the game just doesn’t show a tile at all if it is not a valid target).


    The Solution

    We needed to try and avoid “overlapping”, conflicting associations. The fix:

    Almost exactly the same (but not quite) red-orange tile highlights


    We just shifted the red highlight toward a slightly orange hue. It remains to be seen whether this has really solved the problem (which only affected a couple of players to begin with). But anecdotally, we haven’t had anyone else getting tripped up in the same way.

    So, once again, double check that your presentation doesn’t interact in an undesirable way with existing associations in the minds of your players.


    Problem #7: Extra Clicks Are Evil

    This is one we were absolutely aware of, and had already designed and tweaked the UI flow to remove unnecessary clicks. The problem came with a last-minute addition we made to the build of the game used specifically for live demos.

    At the end of a battle, a fanfare plays and a big “Victory” or “Defeat” message appears on-screen:

    Exemplary sportsmanship


    Then, the user can click anywhere to exit the battle and return to the main menu. We modified the demo build to display a mailing list signup prompt after the user leaves the battle.

    This seemed like a great idea – but there was one fatal flaw. The moment the “victory”/”defeat” message appears on-screen is precisely when the players share a good-natured handshake (or start trash-talking each other) and get up from their seats. The battle is over, resolved, and there’s no reason for them to hang around. So, they would leave without ever seeing the mailing list prompt.


    The Solution

    Have the game automatically display the newsletter signup screen after a couple of seconds.

    Auto-nag 3000


    Honestly, we should have caught this one beforehand – blame it on the last-minute addition of the feature. But the simple change of removing the unnecessary click increased our newsletter signup rate to 3x what it was previously. Ditch those unnecessary clicks!



    • Use movement/animation to draw attention to text prompts
    • Make interactable UI elements clear
    • Think of prompts as calls-to-action. Make them immediate and contextual
    • Be careful about overly technical language, and try to provide context to help players understand the decisions they are making
    • Check for unexpected mental associations of colours, words etc.
    • Smooth out the UI flow by removing unnecessary clicks


    Hopefully, some of the points outlined here will be directly applicable to your own game somehow. But mostly, we hope that we can convince you of the value of the general approach – observe new players, work out where they are getting stuck or confused, and then extract general principles and try to apply them across the board.

    Data and notes collected at PlayExpo London. I love spreadsheets


    We added metric-gathering code into our demo build to record data about battle results, how often each character and ability was selected, and various UI timing information. This was certainly helpful and allowed us to be somewhat scientific in measuring the effects of the changes we made. But probably the majority of the insights here came about the old-fashioned way – watching over players’ shoulders, filling pages with scribbled notes.

    None of us here are UX experts (and so the unofficial alternate title for this article is “7 UX Screw-Ups We Should Probably Have Avoided”). Like most teams without a dedicated UI/UX person, we try to follow common sense and stay up to date on some simple best practices. But with your head so deeply inside your own project, it’s impossible to view all of the rough edges objectively. The fresh eyes of a new playtester are incredibly valuable – make as much use of them as you can!





    Steamhounds is a multiplayer turn-based strategy game. You will take control of a team of steampunk mercenaries, doing the dirty work of the shady factions who fight for control of a once-great industrial city. Put together a team and build up their strength by deploying them on missions, uncovering dark truths about the city and its inhabitants as you do so. Then challenge your friends in competitive team-vs-team battles, or attempt to climb the online leaderboards in ranked matches.

    If you’d like to help with playtesting, just jump into our Discord server . Or if you want to stay updated about our progress, follow us on Twitter or sign up for our email newsletter here.



    [Wayback Machine Archive]

      Report Article

    User Feedback

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Advertisement
  • Game Developer Survey


    We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a $15 incentive for your time and insights. Click here to start!

    Take me to the survey!

  • Advertisement
  • Latest Featured Articles

  • Featured Blogs

  • Advertisement
  • Popular Now

  • Similar Content

    • By Tomato Head
      Hello everybody,
      I'm very interested in learning what is your process for discarding core game concepts that you've have come up with. Knowing that it is very hard to work on more that one development at once and plenty of people have more than one idea for games in their head, how do you discard or prioritize your concepts? Have many of you created prototypes and only then found the concept is not good? Have you found that there are core concepts that are bad and can never be iterated to get a playable/good game?
      Any advice is very much welcomed.
    • By Loosearmy
      Concept for Delayed Shots in a Fast Paced Shooter
      The base for this concept is that with each click or trigger pull there is a X-second delay before the gun would actually fire. This would make it alot more difficult to time shots and could create unique design elements that would cater to this delay. (i.e sharp corners and hallways where it would be hard to time when to click in such a tight enclosed space). Ive had this concept for a minute and i know we could code it to work but my main concern with this is, would it be a good design choice?
    • By Octane_Test
      I want to render an ocean where players can change waves’ amplitude in real-time. Initially, I would render rolling waves (see picture). As the amplitude increases, I need to transition the rolling waves into breaking waves (see picture). For now, I am not going to show the shoreline onscreen so I don’t need to render breaking waves interacting with the shoreline; I only need breaking waves on the open ocean.

      I’ve tried three different approaches so far and I’ve only had success with rolling waves using approach 1. Breaking waves have been impossible so far with all three approaches.

      Approach 1: Mesh deformation

      a.     I can create smooth rolling waves using the Sine and Gerstner equations.

      b.     Since I can’t use these equations for breaking waves, I tried to implement them by using this free plugin whose output is similar to this paid mesh deformation plugin. But there are 2 problems with this plugin approach:

      ·      There is no smooth transition between rolling waves generated by approach 1a and the breaking waves generated by the Deform plugin

      ·      The output of the plugin does not look similar to real breaking ocean waves in three different ways:

                                                     i.     No smooth blending with the ocean surface

                                                    ii.     A large depression is created below the crest

                                                  iii.     The entire wave is the same height (rather than with more realistic variations)

      c.      I considered using vertex shaders but this approach seems similar to mesh deformation.

      Approach 2: Fluid dynamics + metaballs

      1.     To render an ocean I will need thousands of particles which will be too expensive in terms of performance (especially for mobile devices).

      Approach 3: Using mesh files

      1.     I can create breaking waves using some 3D software like in this post but then I can’t modify the ocean in real-time. It will be more like a pre-rendered simulation.

      To summarize, I am looking for an approach where I can vary ocean waves’ amplitude for a smooth transition between rolling waves and breaking waves. Please let me know if you have more questions.

    • By keki123
      Hi there,
      I need help! Based on my own experiences, I have a theory that if we (game designers/builders/creators of awesomeness) were to have a simple method for collecting and analyzing feedback about our games we could:
      significantly improve the early game-play and feel of the game,
      reduce the time it takes to keep or kill our ideas,
      improve the time it takes to go from thinking to world building (idea to production),
      stay engaged whilst on the journey to full production.
      So before I go any further with my theory, I’d love to get your thoughts and opinions. Are the problems I face just mine or are you experiencing them too?
      Please help me by completing this quick questionnaire:
      https://www.surveymonkey.com/r/9SFXKHD (it should only take 2-3 mins) 
      or providing any comments you feel might help (please be constructive ;)).
      Thanks in advance!
    • By Pepsidog
      I'm wanting to create a hybrid game between turn based and action.  I'm looking to create a system where the player has a list of attack or move options on their turn, but I want to add a skill minigame in order to make the game more engaging for non-strategists.  I figured some sort of minigame or something.  Any ideas are welcome.  Thanks in advance!

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!