User interface in games is a subject very near and dear to my heart. If I couldn’t be a game designer for whatever reason I would probably be a UI or graphic designer. The way screen elements are laid out is crucial in both educating new users and empowering veterans who want as little as possible between them and the info or result they’re after.
In this article I’ll share a number of UI guidelines that I’ve accumulated over the years. A lot of this information will be nothing new to anyone who’s done professional UI before, but I hope everyone finds it useful and/or entertaining regardless!
Much of what I talk about is pertinent only to the strategy genre or other types of games that have complex UIs (typically PC titles). Someone designing a first-person-shooter will still come away with a few useful tidbits, but they’d be hard-pressed to get much out of button placement suggestions when their game has no on-screen buttons!
Function Before Form
Many development teams lack a true UI design specialist, and it nearly always shows. Ironically, the manner in which this typically manifests itself is that their UI ends up being too pretty. So what’s the problem?
The task of nearly every professional artist in the games business is to make something look as good as possible. I could just make stick figures for the games I work on, but hey, that’s unlikely to get the kind of attention we want. It’s much better if the person making the units has actual knowledge about anatomy and the ability to translate that into 3D.
The problem with assigning this type of artist to interface work is that their goals are likely to be the same as they would be with other art tasks – make something look as nice as it can. However, if a game hopes to be accessible and easy to play, it must prioritize function over form with its UI. Too much decorative framing can confuse and mislead the player. Buttons should look like buttons. Non-interactive panels should look non-interactive. Spending a lot of time and resources making an interface that’s attractive will often backfire and result in a less approachable game.
That’s not to say that every UI should be nothing but plain boxes and text. A super-simple look isn’t right for every game. Decorative elements have their place, and can certainly add a lot of feel and flavor. But such elements should become the focus only after the UI is basically done. You don’t paint a car before its frame is assembled – likewise, don’t gussy up your UI until it’s functionality exactly how you want it.
A very important tip to always keep in mind with UI: every single element on the screen siphons off a bit of the player’s attention. Make sure they’re only spending their limited “pool” of focus on what you really care about.
Prominence Equals Importance
Or: big items are easier to spot than small items. Simple enough, right?
Well, when building a UI this principle has to be applied with extreme diligence. Does that important button look weird being so big? Do you like the feel of the screen better when the text is on the bottom instead of the top? Before making any moves like this a designer must consider what the usability ramifications will be. If that ever-so-important button is made too small players might completely miss it, or spend time hunting it down, frustrated the whole while.
Size isn’t the only factor in an item’s visibility. Placing an element all by itself pretty much anywhere on the screen will bring attention to it. If a player opens up a screen dedicated to a particular city and its name is written in fairly small text at the top, it will still stand out as long as there’s nothing else nearby. In this way, where and how you use negative space can be just as important as any other instrument in the UI design toolbox. Spend your empty space wisely!
A good example of prominence being used poorly in a game is one of my latest addictions, the baseball sim Out of the Park. OOTP 13 provided a number of UI improvements over OOTP12, but in some ways it was a step backwards. One specific case of this was with the player ratings data, which is a combination of text and horizontal bars which indicate a player’s potential and how close to reaching that potential he is. Here’s what it looks like in OOTP12:
And here’s the OOTP13 version:
Both are displaying the exact same information. The OOTP12 version takes up more space, and is certainly less “refined,” but on the whole it does a better job than the OOTP13 one. Why?
In 13 the text and bars are basically the same height, giving them equal weight and ultimately resulting in the elements blending together and feeling cluttered. This style could work if there were more space between each entry, or if the bars were much thicker or thinner.
Another change I don’t like is the merging of the current and potential bars. While it’s nice that this approach monopolizes less room, I find it harder to get an “at a glance” impression of the gap between current and potential. The biggest problem may be the colors used, and maybe a different set would work much better. But hey, figuring that out is someone else’s job – or it should be anyways!
By no means is the 13 version completely unreadable, and I’m sure there are some who prefer the new one. But like life, UI design isn’t black or white, good or bad. And in my mind this particular feature is now certainly a darker shade of grey in 13 than it was in 12.
Group Related Items
This too sounds pretty obvious – just put the amount of “culture” you’re generating next to the meter which shows your progress! But there are also more subtle considerations than this example completely ignores… do you put a city’s culture spending next to the other culture-related info? Or do you put it next to the spending info? Can you do both? Is there even room to try this? If there isn’t, is it worth re-arranging everything to make it possible? It’s a tricky tightrope to walk, but that’s why UI design is a serious discipline that requires a great deal of specialized knowledge and experience.
One of the best ways I’ve found to group things together is using frames, sometimes even multiple ones that overlap. In our culture example above, you could have a vertical frame surrounding the spending info intersecting a horizontal frame containing the culture info. When creating UI mockups even I’ve been amazed at how the feel of a screen can completely change just by drawing a couple boxes. Too many frames will distract the eye though, so be sure to only use them when necessary.
Another grouping tip is to collect all action-related controls into one area. This could get messy quickly and isn’t possible in every situation, but if you can pull it off your players will appreciate your labors. Knowing exactly where to find all of the things you can do without hours and hours of playtime is a godsend, especially in big, complex strategy games.
Use Color to Associate
When players jump into a game for the first time, (in general) they know absolutely nothing about how it works. “What is this ‘culture’ thing? What does it even do?” No matter how good your UI or tutorial system is, it’s simply going to take time before your players become comfortable. An excellent way of smoothing this learning curve is to build associations between related concepts – color is one of my favorite applications of this.
Okay, it’s going to take a bit of time for everyone to figure out how culture works – that’s just the way it is. But if all of the stats related to culture are purple, and the icon for culture is purple, and the buildings which provide culture have a purple outline around them… well, now you’re giving a players a huge head start in connecting the dots. Assuming, of course, that you use purple only in association with culture – if you just throw it around everywhere then you’re just wasting your time and gaining nothing. Red and green are particularly tricky colors since they’re often used as generic indicators of “good” or “bad.”
Speaking of red and green, throw a bone to our colorblind friends and never use color alone to provide critical information. Over the past few months I’ve played the board game Lords of Waterdeep a number of times and while the game itself is quite good, it’s very unkind to colorblind players. One of the four types of spendable “resource cubes” are black, and another type is purple. My good friend and fellow game designer David Heron is colorblind and has slipped up many a time when collecting or spending resources simply because the designers picked two colors that are virtually indistinguishable for someone with his condition. Issues like this are easily avoidable if the UI designer makes it a priority.
Icons and Text – Like Peanut Butter and Chocolate!
This is a smaller point related to the one we just discussed.
UI icons are great. I love them. But they can’t carry the load alone. Players must first figure out what the icons actually mean before they’re at all useful. And if that takes too long, using icons can deal a major blow to a UI’s usability. Sadly, many games forget this and simply throw bare icons at players, either expecting them to automatically understand them, or not even thinking about the potential issues at all. The worst naked icon offenders are those inside tooltips, where it’s impossible to bring up a tooltip for them to figure out what they mean. Icons that you can identify by mousing over aren’t as bad, but I still disapprove in nearly all cases – icons and text should be displayed together.
Yes, this makes it harder to get everything to fit because instead of using a 16 pixel-wide icon you have that plus another 50 or so pixels for a word, but it’s a price certainly worth paying. It’s not like you want to cram everything in to the last pixel anyways – interface elements need room to breathe, otherwise they start blending into a muddy mess of shapes and colors like the OOTP13 stats image above. Icons should be a tool for helping players – not one for saving pixels.
Stack Text Vertically, not Horizontally
Okay, now we’re starting to get into more of the nit-picky stuff that I might get some more pushback on. But I think I’m on the good guys’ side with this one.
I just don’t like horizontal stacks of data. They’re hard to read. But you be the judge – which of these two do you prefer?
Be Wary of Tabs
A lot of people like tabs. And for good reason – they’re an excellent way of organizing a lot of data. But they rarely work well in game UI. The problem is that tabs hide things. This isn’t an issue when you know the contents inside and out – in fact, that’s the whole point.
But nobody is going to be an expert at a game the first time or ten they fire it up. Whatever you hide inside tabs becomes marginalized, sometimes to the point where many players will never, ever see it. This can be appropriate when a tab contains incredibly detailed stats that 95% of players don’t care about. But usually that’s not the case, and tabs are instead used as another sloppy and destructive space-saving measure. I would strongly advise against putting all of a character’s magic info on one tab, their melee info on another, etc. This simply spreads out the data, making it harder to get to.
Audio and UI
Audio design and UI design blend together in some places. Both are trying to convey information to the player – so why not have them work together!
Every action the player takes or event that occurs (interface-related or otherwise) should have a special sound associated with it. These could all be unique sounds, or one sound might be shared by several triggers. Ultimately this just depends on the situation at hand, the designer’s preference, and the sound budget. In general, if actions or events are very similar to one another in terms of their effect on the player, then sharing a single bit of audio for all of them is probably fine.
Not every game has a top-notch sound designer on board, so it can be tough to really push the audio side of the game to AAA levels, but even without an expert around there is one rule that must always be adhered to: every action needs some kind of sound attached. It could just be a generic “ding” or something – just don’t ever have nothing, as this suggests to the player that nothing happened. Confusion, chaos, anarchy… you don’t want all of that on your conscience, do you?
UI for the Elite
The last topic I’ll cover is one that already gets a lot of attention in game UI design: creating interfaces that is tailored to hardcore players. Games nearly always invest in UI features over UI accessibility, partially because most feedback comes in from the dev team, beta testers and QA – all individuals that typically have extensive experience with the game and are looking for more power features. Another reason is because truly putting yourself in the shoes of a brand-new player tends to range from extremely difficult to impossible.
While I’ve focused quite a bit on building a UI that caters to new players, by no means do I think the pros should be left out in the cold. I’m a big fan of options that turn off the most basic help, pack more info into the screen and transform those nice, friendly tooltips into virtual catalogs that would make newbies weep.
The absolute best favor you can do for your most hardcore players is to attach hotkeys to everything. No matter how sleek and streamlined your UI is, players will never be able to perform actions faster than they could by simply hitting a key. Games that lack hotkeys altogether frustrate me to no end, and I very much doubt I’m alone there.
The trick is balancing the interests of both groups of players. Neither new players nor the vets should be underserved, and with enough time and care this is absolutely a realistic goal. Unfortunately, when game development gets cut short for business reasons UI is often one of the features that suffers the most, mainly because of how much it relies on iteration. This is a major loss because the UI is the layer through which every player experiences the game. Playing a computer game with a bad UI is like playing Yahtzee with unreadable dice, or poker with sticky cards – just bad news all around.
Now then – equipped with this great wisdom, go forth, and build exceptional UIs!
11 thoughts on “Building a Solid UI”
– Hire an actual user experience designer rather than an artist, or get an artist that cares more about the game than making things for their portfolio.
– Design of Everyday Things by Don Norman
– Visual Display of Quantitative Information by Edward Tufte (and Tufte’s 2nd book)
I was hoping for more examples 😦
I have to save SOMETHING for future articles. 🙂
You ever play the board game Eclipse (http://boardgamegeek.com/boardgame/72125/eclipse)? Beyond being an excellent game, it’s a massive triumph in graphic design.
I have not played it yet, but it’s on my short list of board games to check out. A good friend called it “Master of Orion in less than 6 hours,” which all by itself is enough to make me want to play it! Very glad to hear it also nailed its graphic design as well, as many board games are some of the worst offenders when it comes to usability issues.
Great article! Overuse of icons without text is something I see a lot in low-budget strategy games, where the problem is compounded by the fact that they can’t afford good specialized UI artists. Having to decipher a complex UI by mousing over incomprehensible icons to see their tooltips is a big turn-off that many developers seem oblivious to.
One personal pet peeve I would add: scalable interfaces for high-resolution displays should be mandatory. Rows of tiny text make me uninstall a demo like nothing else. Torchlight 2 is exemplary here, the UI upscales automatically but also allows users with good eyesight to downscale as desired.
Editing department: conscious -> conscience in the last paragraph before “UI for the Elite”, accessible -> accessibility in the next paragraph. 🙂
Spelling/grammar issues are now fixed! Thanks for pointing it out. I clearly need to either find a new editor or pay him more. 😉
Your comments regarding UI scaling with resolution are very well-founded. That is one of my pet peeves as well (and probably something I should have included in the article… alas, it seems like I’ll have to write a sequel sooner rather than later!). Civ 5 had two different versions of the interface – basically one for big monitors and one for small ones. We could have done more than that, but having two versions seemed like the best results/budget compromise. Definitely looking forward to going even further in my next game.
Great Article! How much concern is paid to circling back and verifing the effectiveness of a UI with tools like Morae or galvanic skin response?
One of the things that annoys quite a bit if when you have this great other way to use the interface, like an overlay for instance, but no tips that point to its existence. Other times the overlay changer is so obvious, but the overlay tells you very little that you didn’t already know.
Overlays are like tabs. The information on them may or may not be useful, but we’ll never know unless… unless the overlay can be laid on transparently enough that it doesn’t interfere, but clearly enough that the player realises that there’s a problem.
Most of the time though it’s much easier to just inform the player (with a text box for example) that there’s a problem when it becomes a problem, like when those colonists on a distant planet are too busy watching Arena of Agony to care about the empire that they pay taxes to.
Of course multiple text boxes popping up can be really annoying especially when you just want to get to your next turn, and the next. Especially when you have so many colonies and you have to jump on the Planets list and sort it by name and then scroll down to the one that’s falling prey to enemy propaganda and that’s assuming you committed the name to memory. Was it Alderan III or Andromeda I? I’ve forgotten now. I’ll probably remember when they break away and join that other empire.
The logical thing to do is add these sorts of location-specific happenings to a watch list, or a collapsible/expandable event list like in Fallen Enchantress. You click on an event, you go there, you can decide what to do if anything needs doing.
Old post, but just found it. All good advice too.
I’d recommend that developers pay careful attention to what their testers do the first time they use a new UI. Don’t give them any hints, just let them loose on it. Anything they get stuck on or have to ask questions about needs some consideration for rework. Never dismiss a criticism out of hand.
Remember, as UI developers, we’ve spent time building a UI and have had plenty of opportunity to adapt to it and will be blind to most of its shortcomings. For instance, if you see someone try to drag and drop something that can’t be dragged or dropped, maybe that’s a hint…