I’ve been working on a single project for 2 years – Pearl’s Peril. The game has been live however, for 5+ years and work began in it a couple years prior to that. In the space of those 7 or so years, several UI artist and UX designers have come and go and a great many features have been added to the game, as well as new platforms/methods for it to be played on and some which have gone a way (like Flash). Because of this, they game has gone through a great deal of change and has, naturally, lost it’s coherent look and feel over the years.
After a new senior UI/UX professional joined our team, we decided to rectify this and bring the game together, unifying the style across all scenes/features/menus etc. Not only would this spruce up the visuals to help make the game more competitive today, it would make the user’s experience drastically more intuitive and frustration-free.
With this experience, I’d like to discuss the use and and importance of a style guide today. We’ll also look at what would content go into one, for a hypothetical mobile game.
Why Do We Need a UI Style Guide in Mobile Games?
A style guide, first and foremost, has 3 major benefits:
- If applied, it aids the maintenance or creation of a logical, consistent, user interface, this helps players have a frustration/confusion free experience and learn the ‘rules’ of your game’s interface fast.
- The style guide allows new members of your team to create new functions/scene/features etc without having to waste unnecessary time working on the look/layout etc. They can quickly see what components/elements have already been created and how they should be used.
- A well applied style guide can make your game recognisable and memorable – this can make it more recognisable from screenshots and trailers and help with marketing/branding etc.
Working on a game which did not have a style guide established for many years, it takes a great deal of care and effort to retroactively create a style guide and apply it. It takes rigourous care and testing as – so make sure to create and apply the style guide at the earliest possible point in the game’s development!
What Kind of Content Should be in a Mobile Game UI Style Guide?
Let’s take a look…
The colour palette will largely accomplish 2 things:
- Setting the overall tone/atmosphere or feel of the game. Is this a hidden object game set in a supernaturally charged Victorian England? (This may be a darker palette with alot of blues, greys and greens) Or is it a match 3 game set in a cartoon zoo? (This may be moe pastel shades of primary colours).
- The colour palette is extremely important for buttons and fonts – red and green imply messages of negativity and positivity quite well, but what about information buttons? Links to external web pages etc? How do you want to draw attention to messages like ‘Warning’ ‘Special offer’ etc using colours?
Knowing the common conventions on colour theory is very important but establishing and maintaining in-game logic for these colours is vital too.
Finally don’t forget players who are colourblind, look into this at an early stage so you can confidently choose colours and pair colours which will be distinguishable for as many players as possible.
This ties in well with the overall colour palette as it also establishes the tone and atmosphere. The hypothetical Victorian England hidden object game above might have paper and stone textures, while the match 3 zoo game might have a texture similar to toy-like plastic or paint.
Adding 3 dimensional aesthetics to buttons can also enhance the sense that they are interactable. Having a tactile quality to buttons is a good idea.
The typography must be legible and easy to interpret, above all. It’s important to remember the devices on which the text will be viewed – test it to ensure it’s easily visible on the various devices and choose font sizes based on this. Establish hierarchy with a list of font heights for headers, paragraphs, buttons etc. Remember to use colour to establish certain messages more easily (like a warning in red) as well as effects like bold or italic. Using fonts that reflect your game’s style/mood is also important, such as a sans-serif font with a blocky aesthetic for a sci-fi game or something a little handwritten looking for a game set in the past.
Setting margins widths is extremely important in drawing attention to content and guiding the viewer’s eye, as well as avoiding inconsistencies across menus, popups etc. For example, on a HUD screen, where there may be 5 – 10 buttons such as: Shop, Settings, Play Mission, Leaderboard etc, having set margins between these as well as between them and the screen edges (which may vary on certain devices) is key to a good user experience.
Furthermore in places like menus or popups, where there may be a lot of info on-screen at once, these set margins will help separate headers from descriptions, as well as separate out individual messages for easier consumption. See my example below from Pearl’s Peril.
Iconography is an often overlooked element and it’s easy to mess up, even when devoting alot of time to their creation. The sole purpose of an icon is to communicate a message instantly, removing the need for text, which can be more space-consuming and require localisation. Icons need to share the same aesthetic (2D or 3D, vector, consistent angle of rotation, consistent angle of lighting, in line with the colour scheme established) and, if possible, remain in line with the game’s theme (such as using swords as an icon for combat in a medieval game, not a gun). However, once again, nothing should get in the way of communicating a clear message, so do not allow aesthetics etc to take authority over that.
Buttons have several elements which should be established. SOme of these i’ve touched on in previous segments. Buttons MINIMUM heights and widths should be set. It is very likely (due to localising foreign language) that you will need to have buttons be able to expand flexibly. But this will usually only apply to width. In instances where the button cannot expand much further to fit the text consider using an icon instead or having the text dynamically shrink.
Remember to have unpressed, pressed, disabled and highlighted states for your buttons, and apply the effects used across all colour variations of the button.
Speaking of colour variations. Your buttons must have set colour variations for different usages, as mentioned in the colour palette section. If you have different styled buttons across the game (ones with thicker frames, circular and square ones etc) the colours used must be the same. Never use two shades of red, or two shades of green etc.
As mentioned in the textures section, think about applying a tactile 3d quality to the buttons, if it will break your desired aesthetic (such as a flat sci-fi or minimalist clean look).
Finally remember that some players will be colourblind or suffer from poor vision. Using high contrast will help the text on a button pop (light text on darker button or vice-versa).
If you’re working on a mobile app and in particular mobile games. you will likely be creating alot of popups and also displaying multiple messages on a single screen. In order to keep messaging clear and hierarchy of information clear, it is a good idea to have your containers (which will contain text) stylized in a clear way. These rules are largely up to the designer to establish (what is important is consistently applying in all cases) but the designer should remember to make sure that:
Container edges should have the same border curve.
A container to be held within a larger container should snugly fit the border curve of the parent container. For example a parent container with a border curve or 40px should have a child container with a border curve of 20px. This rule can be broken if the designer has a distinct stylistic goal they want to achieve.
Having touched on popups in the last section, I have some notes to discuss here.
Pop ups are quite annoying to a player, they break their ‘flow’ and interrupt the UX. It’s important to always justify the use of a popup and remember that, as they are not fullscreen pages, the complexity of interactions available in them should be restricted.
I hope this post can be useful to you, I’ll be sure to update it as I learn more.