On the razor’s edge. How to make a mobile game interface and not get buried under the rubble of elements.
The problem
We at Donut Lab are developing a mobile shooter game called Donut Punks. The game has already been soft-launched and acquired new functionality over a few months. This why we needed to incorporate all the new mechanics into the interface.
For mobile games, this is a classic case, and an extremely painful one. Over the years of updates, interfaces swell: the number of buttons and info blocks grows, the player is besieged by unceasing pop-ups and there is no end to notifications.
We were faced with the task of finding a reasonable balance between intelligibility and functionality, maintaining the flow familiar to the player and helping them to easily master new features.
Stage 1. Finding key elements
So, we have a set of features, most of which cannot captivate the player on their own. They make sense only within the game cycle, and the interface, as a result, must guide the player in this cycle.
Together with game designers, it is necessary to identify not only the priority of certain elements, but also their dynamics: when and how they can manifest themselves, attract attention or vice versa, disappear from view.
Example:
Donut Punks is a session shooter, therefore the main element is the “Fight” button. It starts a battle, during which the player obtains resources in order to spend them later in the metagame. And in this regard, the title screen is a portal to all available features.
Naturally, we prioritize the battle start button, and organize secondary functions according to their value. In our case, the most important factor is the long-term retention of the player.
The priority order is as follows. In the center is a character who completely determines the battle tactics. Surrounding the character are elements with a set of customization items. They are followed by Donut Pass (our battle pass system), which is a key element of player retention. Next is another element of retention, i.e. Trophies. And finally, there’s a set of navigation tabs.
Plus, keep in mind possible new features: in this case, we leave some space for displaying special offers from the store, quests, and a list of friends.
Having clarified what is more important for us, we move to the next stage.
Stage 2. Wireframing
Wireframe is a detailed image of the future interface, in which the structure and location of all elements are already visible, but there is no interactivity or graphics.
Since we have an idea about the priority of certain elements, we can form the first draft of the future interface. Wireframes themselves allow you to do this very quickly and immediately involve all stakeholders in the development.
And in this sense, wireframes are an important communication tool. Their visual language is clear to a game designer, an art director, a technical leader, and a product manager.
Example:
At the initial stages, the GD wanted a list of quests displayed right on the main screen. Then the player would see all their tasks and current progress, and this would help to extend the duration of a gaming session. But in this case, the size of the rest of the elements on the screen would have to be reduced.
The art director, on the contrary, wanted to enlarge the existing interface elements and therefore increase their value. This concerned, first of all, the Donut Pass block.
Given the difference in opinion, the wireframing stage came in very handy. We were able to consider all possible cases and choose the ultimate solution: abandon the idea of displaying a full list of quests, reducing its volume to a simple button. It didn’t take up much space and allowed to redistribute emphases to other elements. And we didn’t forget about the future development of the game: we made it possible to display notifications about the successful completion of the quest right there on the main screen.
This decision turned out to be a compromise. On the one hand, we lost the ability to immediately set quest tasks for the player from the main screen. On the other hand, we managed to avoid bulky elements and enhance the existing elements that worked to retain the player. The quest button eventually took its place in the block with additional features already familiar to the player, so access to new functionality should not cause problems for the player.
The decision-making process when working with interfaces takes quite a lot of time, and yet it is justified. It is crucial to question every idea and, over the course of discussion, look for all the potential shortcomings of any given option.
Stage 2. Prototype
Unlike the wireframe, the prototype is interactive, i.e. you can not only see the interface structure, but also interact with it. The implementation of a prototype is an order of magnitude more demanding than a wireframe, but its undoubted advantage is the live testing of user flow (the way a user solves a task within the interface) and identify its downsides.
However, this does not mean that prototypes must be used all the time. They will be extremely useful at the early stages of development, but if your game is already out (released or open beta) the cost justification drops. Most likely, all changes to the interface at this stage will be targeted, and the flow will be well known to both developers and players.
Therefore, the prototyping stage can be skipped. Or simplify.
Example:
While working with the main screen, we made several prototypes for individual features, since most of the user scenarios remained unchanged.
Therefore, first of all, we prototyped the functionality that we wanted to add in the near future and for which it was important to leave free space on the main screen.
So, for example, we made a prototype for the squad system (similar to clans). It’s a quick job, and the result is very crude. But the main thing is that there is now a prototype for this feature. It works, which means that in the future it will greatly simplify the work and speed up the development process.
If we are talking about finalizing the existing functionality, then you can skip prototyping and immediately get down to the mock-up (see below).
Stage 3. Mock-up
The mock-up is not interactive, but it contains the elements of the final design, all graphic elements and texts. For simplicity’s sake, one can say that this is a screenshot of what the user will see in the game.
Hence all the specifics: mock-ups are made at the very last stage, and they give an almost final idea of how the interface will be like.
Example:
When the development was streamlined, we began to use mock-ups for the final assessment of all new features in the interface.
Did you add new information icons to the battle results screen? Make a mock-up. Did you improve the resource bar? Mock-up again. And so on!
Stage 4. Testing
There are many approaches and ways to test the UI, but user flow check is essentially the main one. Here you need to answer the questions: “Does the player understand the purpose of the UI elements?”, “Do they follow the scenario that was intended?”.
If you are a start-up and your resources are limited, you run tests on your own. Invite colleagues and set game tasks for them. For example, “raise through the ranks and take the prize”. Record all steps and watch how the player interacts with interfaces. Are they getting on? Is everything obvious? And then analyze this experience! Organize feedback and make changes.
Example:
We are a start-up. That’s why we succinctly call interface testing “playing”. We put together a build with all the new features, get together and see how convenient everything turned out. For example, in one of these tests it turned out that it is not always easy to distinguish the received award from the one not yet received. Or that some buttons are perceived as speech bubbles of the characters, and as a result, they are not tapped on.
These kinds of nuances help to understand the player and their experience, make changes and make interfaces cooler!
The result
Experience has shown that the problem of overloaded screens in mobile games cannot be completely avoided. Platform limitations play a key role here, and we can observe a similar phenomenon, for example, in console games, where you cannot reduce the size of elements, hence they are all large.
And although it is impossible to completely get rid of the overload of details on the screen, there are several solutions that visually simplify the layout and help the player to avoid confusion.
When working on the title screen, we decided to focus the player’s attention primarily on those elements that work for retention. At the same time, we did away with overly specific immersion in functionality. This allowed us to bring all the variety of features that the game offers to the main screen, and keep the focus on what’s most important, i.e. the character and the battles in which they can participate. To support this, for example, we enhanced the customization elements and the mode button.
And we also reserved free space on the screen. In the future, this will allow scaling the functionality of the game and adding new features without any problems.
But the main thing is that this option is not final. The game will be developed further, and with it the interfaces, which means that the search for optimal solutions will be an integral part of the workflow. And it seems grand!
