Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
August 28, 2014
arrowPress Releases
August 28, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Building a Solid UI
by Jon Shafer on 09/24/12 06:13:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

You can read more of Jon's thoughts on design and project management at his website. You can also find him on Twitter.


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 designermust 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 stylecould 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 coloralone 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 toeverything. 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 playerexperiences 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!

- Jon


Related Jobs

Yoh
Yoh — Vancouver, British Columbia, Canada
[08.27.14]

Rendering Engineer Job
Yoh
Yoh — Vancouver, British Columbia, Canada
[08.27.14]

Multiplayer Designer Job
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[08.27.14]

Quest Writer (m/f) for The West
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[08.27.14]

Game Designer Tribal Wars (m/f)






Comments


Andrew Thatcher
profile image
Great article, Jon! UI design is something I'd like to begin doing more research on. It's so deceptive; it appears really simple and basic at first, but once you get into it you realize that there's just so much to consider! This article is a great primer on what to take into consideration. I especially enjoyed the first point. Function over form is a concept I've always held dear, but I've never heard it explained in the way you've got here. Love it. :)

I do disagree with your assessment of the OotP13 menu, however (although it's worth remembering that I'm by no means an expert!). I feel that it's a sleeker, cleaner display. Granted, some work could be done to more clearly indicate which text heading belongs to which bar (if it takes me any time to realize that the text is referencing the bar above the text and not the bar below it, I get frustrated), but overall I think that it's a more successful layout.

Honestly, having the "real" and "potential" values split in 12 just confused me. I didn't really understand what I was looking at at first, but upon looking at 13's combined menu it's more immediately clear to me that the value is 6 *out of* 7. As you said, though, the color choices could be improved; I could easily see somebody with red/green color blindness not being able to differentiate between the real and potential values of the 3rd and 4th lines, for example. Perhaps that's why they added the grey boxes at the ends of the lines? I feel that with a better color choice, that would have been unnecessary, haha.

That small issue aside, though, I loved the article. Will be checking out your site for more!

Rob B
profile image
Perhaps the most worrying thing about UI design is that while I agree with just about every single point in this article I disagree entirely with the analysis of OOTP12 and 13.

A disclaimer, Ive only played the games very briefly. Whether that makes me a better unbiased judge or a worse ill-informed judge Ill leave up to you.


The bars in OOTP12 are small and a great distance from the text, it makes the text descriptions look disconnected from the overly condensed bars. (Not a huge problem with these small values, but still cramped.)
In OOTP13 it uses less screen space but feels more open and the text is much more clearly attributed to each bar.

The separate and different descriptions for each bar also obfuscate the fact that they are related to one another. It may be obvious to people already familiar with the game that 'Homerun Power' and 'Eye / Discipline' are being measured agained 'Power Potential' or 'Eye Potential', wasnt so obvious to me at first glance.

I agree that perhaps the colours need to be more carefully considered but by layering the bars it again uses less screen space but immediately gives you more information. There is no confusion in what is related either by distance between the bars or differing text descriptions, and while in OOTP12 the cramped bars and distance between them mean you have to rely on just reading the numbers to be sure of where you are, in OOTP13 the progress of the player is immediately apparent.


All of this could be moot, while I think Ive made a fairly objective argument I cant say categorically whos argument is better and others could join in and bounce back and forth opinions all day. So perhaps some better points I can make in addition to whats discussed in the article, is that even the simplest of UIs are surprisingly difficult to pin down and in a serious project I wouldnt let a UI out of the door that I hadnt done a lot of user testing with. (Preferably with a lot of statistics on how they were using it to compare and contrast with their opinion.)

Jeanne Burch
profile image
What he said. I actually blinked at that part in the article because I thought I'd misread it.

One of the things I hammer home to my students is "proximity." Things that relate to each other should be close together. The gap between text and bars in OOTP12 makes it hard to glance at the chart and see what's going on. OOTP13 is far easier to understand at a glance.

Cody Kostiuk
profile image
I thought the author was smoking something too, when I got to the OOTP12 - 13 part. Still a good article though.

Anyway, a game UI that comes to mind, as function over form, is Bioware's Neverwinter Nights. That interface was quite well done, I felt.

Tom Franklin
profile image
"Another reason is because truly putting yourself in the shoes of a brand-new player tends to range from extremely difficult toimpossible(sic)."

This is very true and highlights the importance of "fresh-eyes tests" where people who have never played the game at all come in and are thrown in to the game with no introduction and no guidance from devs. This is crucial in understanding where a UI falls short (informing new players of mechanics must be considered one of the major pillars of UI development), and lends credence to your next point ... that iteration is crucial to a successful UI.

Jon Shafer
profile image
Some good points everyone, and I can't say I disagree. Looking back on it now, the point I made is not really what I'd intended.

While I prefer the OOTP12 version because of its readability, I wouldn't actually call it GOOD. The OOTP13 version is closer to what I'd want, but the poor execution derailed the solid intentions. In retrospect, I probably should have went ahead and made my own mockup for what I would have done!

- Jon

Tyler Yohe
profile image
Wow, colorblindness!

That is something I never thought of! I am considering sound bubbles over subtitles, so hearing impared people can get directional references in my game (thus if something is being yelled offscreen tehy know which way to pan the camera), but I never thought to consider the needs of colorblind gamers.

Thanks for the article - it was all thought provoking & useful, but now I'm excited to go back and check if I need to change some color schemes!


none
 
Comment: