Game Design 101: UI Mockups
When I told people that I’m a game designer the first thing I used to add was “no, I don’t draw anything”. Now I came to realize that I wasn’t being completely honest.
Let’s talk about the role of the game designer in general. It’s a bit different everywhere, but in small companies or teams they are usually some sort of universal soldier who
- analyzes data
- designs features (preferably together with the rest of the development team)
- writes documentation and explains it to colleagues
- calculated balance
- configures in-game data
You can notice that no item on that list is “makes UI mockups”, but in fact the second and third items imply it.
Let’s say you designed a great game mechanic. You don’t spend too much time on UI, thoroughly describe it in documentation and give it to the UI designer (if there is one) or to the programmer right away.
In the first case, you will spend a week answering questions, arguing with the designer, find out that to realize your design in-game you’ll have to have thirty-two buttons, two sliders and three checkboxes in one window. Two more weeks later you will have something satisfactory — at the cost of your nerves and your own tasks you couldn’t finish.
In the second case, the programmer will just make a window with thirty-two buttons, two sliders, and three checkboxes.
Unless you planned to create the aircraft dashboard you will have to make mockups.
One of the main game designer’s tasks is to convey their ideas to the others, and the game is a visual art anyway, so you’ll still have to learn to draw a little.
Since I mostly work with mobile f2p games, and they mostly interact with the player via UI, I will talk about creating UI mockups. To avoid writing an article in the “do good, don’t do bad” style, I will also use an example.
Usually, during a job interview, I ask candidates to imagine that they need to create a vertical version of Clash of Clans and draw a mockup of the tower upgrade window on a piece of paper. It’s a good exercise because it is usually more difficult to make horizontal UI vertical than vice versa. However, vertical images don’t look too god in articles, so let’s try something different.
Let’s take Hero Wars and try to make a mockup of an imaginary new feature: “allow players to temporarily max out one of their heroes”. The idea is more or less random, so we won’t discuss the quality or utility of the feature itself.
Caution: I wrote “you’ll have to learn to draw a little” for a reason. I’m bad at drawing and I’m no UI designer. Please remove children and real designers from the room: what you’re about to see may disturb you.
1. Make a rough wireframe
Tools: whiteboard, pen and paper (or pencil and paper), Balsamiq Mockups
Try to remember everything you’ll need for the feature to work and sketch it. This stage is a great time for initial discussions with other people, when you draw rectangles on the whiteboard time and time again, and discuss them.
In the case of our “temporary max-out” feature I’d assume that we’ll need:
- header with a timer
- slot for your most powerful hero and slot for the hero you want to max out (because I think it would make sense to only make the hero as powerful as your most powerful hero)
- disabled confirmation button
- list of heroes
- close button
2. Find references
Tools: search engine
As I wrote in another article, don’t try to reinvent the wheel.
First, our ideas are usually not as good as we perceive them at first (and yes, that applies to me too).
Second, it will save you a great amount of time and effort.
In the case with our imaginary feature I thought about AFK Arena at first, because there is a similar mechanic there: the heroes are leveled up to the minimal level of the five most powerful heroes. However, I wanted the mechanic to concern only two heroes and to be temporary, so in the end it didn’t fit.
After a little more searching I decided to base it on a different screen — namely, Hero Fusion. The mechanic itself differed a lot from my idea, but at least the overall structure and elements layout looked more or less close to what I had in mind, so I took Mobile Legends as basis.
3. Add details
Tools: Adobe Photoshop (if you can afford it), Paint.net, any other graphics editor you’re familiar with
Sometimes I encounter an opinion that game designers shouldn’t spend more time on mockups than needed — that is to say more than needed to make a rough wireframe from paragraph 1. The usual argument is that otherwise game designers do someone else’s job and waste time they could spend on “their own” tasks.
I don’t share that opinion because I think that defining how the feature will be seen by the player is the task and the responsibility of a game designer.
Besides, when doing this job, the game designer actually saves his own and his colleagues’ time, because wireframes usually give only a vague understanding of the idea.
For example, take a look at this:
This is my pen-and-paper sketch, digitalized. Does it give you a good idea of what the feature should look like in the end?
If you just give it to the programmer the result might look something like this:
But it really shouldn’t, because it’s the main screen of the feature. It should evoke emotion, so a simple technical window doesn’t suit it well. So you’d have to scrap it and build again, wasting your time as well as the programmer’s.
If you would give it to the UI designer you would still need to spend some time to explain what you have really meant, and in the end, the UI designer would still need to draw several different options to try and guess the right thing. With the mockup of higher fidelity, it would be obvious that some of the options do not suit the idea and do not need to be drawn at all.
So to mitigate that for our example feature we could just start to add details to our original sketch, but we have found a reference already! So I’ll show a different way of doing it. Let’s start with trying to figure out how the feature would look like in the reference game.
For starters, let’s move the hero figure to the side and change the window header.
In case the instructions already look like “…and then draw the rest of the owl”, I’ll elaborate a bit.
First of all, I’m actually using two screenshots from ML: Adventures, one with the selected hero and one with empty background:
Then I violate them with the simplest tools like magic wand and eraser:
It is important not to worry about something being cut too rough or dirty or something — it’s still a mockup, so it’s not intended to be looked at with a magnifying glass.
So with the help of the same simple tools let’s add a slot for the second hero and change some more texts.
Then let’s remove all the UI elements that are absent from Hero Wars or not needed for this specific feature. While we’re at it, let’s change the header once again, since I came up with a cooler name for the feature: “The Dark Pact”.
I think that it is pretty important for game mechanics to have some in-game lore or setting. So it seems that here we’re making a pact with some dark entity that will grant your hero power… but only for a time. And it is important to show that on mockups, too, because how else the team will find out? Not from the long and extensive documentation, trust me.
Anyway, now it looks like the UI works all in all. If your game has no art yet you could stop here (of course, you need to make sure that in the end, only assets drawn and/or owned by your team should stay). Or if your game-without-art-yet setting differs too much from the reference setting you could take some pictures from the Internet and fill your mockup with them (of course, you would again need to make sure that no art you don’t own is left when the work is finished).
However, if your game already has art, it is a good idea to fill your mockup with it.
I won’t use any source files because it’s not always fast, so I’ll take my own screenshots from Hero Wars again:
Then I’ll cut it into elements and start to insert them into the earlier mockup:
Then I’ll do the same with the list of heroes:
And then I’ll insert it into the mockup and get the header block from a different window:
We only need to change the background and the button, but I would also want the heroes to have some sort of pedestals in the end. Also, the plus sign on the hero placeholder slot actually implies that you can press it; in truth, it is not so, you need to press hero portraits. Also, it is a good idea to show how the window would look like with one of the heroes selected.
Is the result beautiful? I don’t know, and that wasn’t the goal. Can you just give it to the programmer to implement in-game? Only if you have no UI designer, otherwise you shouldn’t.
The goal is to create an image — or series of images — that convey the general idea of how the feature works and what it is about as good as possible.
4. Animate it
Tools: InVision, Unity or another game engine you are familiar with.
This is sort of a bonus stage. You see, there are a lot of things that look much better as static images rather than in the game. There are several reasons for that:
- nobody bothered to check how the result looks on the target device. Never do that. If you are making a mobile game, always look at everything you do on the mobile phone
- nobody checked how the window looks in the context of the rest of the game, and in the end it turned out that there are some wonky transitions into that window and out of it
- the window itself has a number of buttons that are not convenient to press and sub-windows that are not convenient to use
You can usually avoid most of those things if you try to transform your mockup into an interactive prototype.
For simple cases, I usually prefer to use InVision. It’s a very intuitive tool that allows you to set transitions between pictures on taps (or clicks, or swipes) at specific zones of those pictures.
For not so simple cases you can use any game engine that you’re eligible to use and which allows you to make UI. Unity is often a great choice, but be sure to check their terms and conditions.
So here is my result. When it is not obvious where to press on any given picture, just press wherever and all active zones will be highlighted.
What to avoid
1.Overpolishing
This is a trap I often get into myself. Yeah, you definitely shouldn’t stop at black-and-white wireframe; however you also shouldn’t polish your mockup forever, removing mistakes that are invisible to anyone but you.
You’ll have to find some balance between the mockup fidelity and effort spent.
2. Lorem ipsum
I’ve seen a lot of mockups with text like “two text lines” (usually only taking one line), “a very long player name”, or just “Lorem ipsum dolor, etc, etc”.
First of all, it is easy to guess the needed space wrong when you do that.
Second, it lowers the mockup fidelity because it gives less understanding of how the game designer imagines the feature.
3. Jokes and vulgarities
That’s another pit I used to personally fall into.
First, as in the previous block, “placeholder” texts may vary in volume from the actual ones. At some point in life, I wrote a joke in the skill upgrade window for some game. So the description of the skill said “Summons a plush Satan”, and everyone liked it, but when it came to making the window in the game engine it turned out that actual skill descriptions are much longer, and they don’t fit properly.
Second, these things are amazingly tenacious and tend to somehow make their way into release. It’s one thing if it’s just an innocent joke, but if some important window has a leftover text with your thoughts on the player’s mom… It’s a real disaster.
Excercise
I hope this article taught you something new about prototyping game UI. If it didn’t — please share your feedback in the comments (if it did, share it too).
And now a few exercises you could train on for a bit! Share your results in the comments or send them to me via email: a.panfilov@protonmail.com
- Adapt the card collection/deck screen from Clash Royale for a horizontal layout
Bonus points: imagine that you’re making a horizontal game with the similar to Clash Royale meta but with the different setting — Lovecraftian, for example. Change mockup accordingly.
2. Draw a mockup for the Hero Wars-like vertical game.
Bonus points: use cyberpunk as setting.
3. Mockup a feature you would like to see in your favorite game.
