Redesign of the game interface. How, and most importantly, why?

Updating the UI design of a project that has already been released is a slippery topic. When, how, and most importantly – why do it? In this article I will tell you how this issue was resolved in our particular case and share my thoughts and advice on this topic.

My name is Kiselev Boris, for the last 12 years I have been working as a UI/UX designer in various mobile game studios. The project that will be discussed in the article is World War Armies — a cross-platform RTS with direct control of units in the Second World War setting, made in Unity.

At the time of writing, the game has been in operation for a year and a half. The interface that eventually became the release interface was initially conceived as a “draft” and was developed in a rather chaotic manner. I think many small studios are familiar with this situation. Initially, such unsystematic development did not seem like a problem: as long as the project does not bring in money, speed and flexibility in development always seem to be more important than correct architecture. After all, polish can be achieved during the cleaning of the project, “someday,” right?

Over time, our UI system became cumbersome, slow and incomprehensible, and the interface itself, although it performed its function, was hopelessly outdated. There was a strong feeling within the team that the UI quality was not up to the average on the market, and that the game deserved more.

This is how the idea for the redesign was born.

Goals and expectations.

In addition to making the actual visual changes to the interface, we set ourselves several more tasks:

1. Combine redesign with rebranding of the project and the entire studio

2. Move away from the style of the Second World War.

3. Transfer work with layouts from Photoshop to Figma.

4. Prepare the interface for the further release of the project on PC.

5. Clean up the part of the file system that relates to the interface.

It was immediately clear that until the launch of the new UI we would need to somehow support the existing system. This means that all new product features during the “transition” period will have to be made in two copies: in the old design and in the new one. It's like driving an old car, in which something constantly breaks down, and at the same time making a second one, fresher and more fashionable. Agree, it sounds like a huge task in terms of labor costs and the number of unknown factors.

What were our expectations? Ambiguous. There was no understanding inside the studio of exactly how the interface update would affect the product. Perhaps not at all. Colleagues from other game studios said that the UI update had a positive impact on their metrics, but this story is very individual and unpredictable. It was also impossible to exclude the possibility that the changes made would have to be rolled back after release due to a significant drop in metrics. It sounds risky from the outside, but in fact this is a fairly standard situation when it comes to visual changes. Subjectively, we, the developers, can believe that innovations will benefit the project. However, it is quite difficult to find confirmation of this (especially before work begins). Often they are either invisible on metrics, or it is generally unclear: what to measure? In our case, the decision was made quite spontaneously. We agreed that we were ready to accept the risks, and that’s what we needed.

This decision was made with the heart, not the mind.

Next, I will talk about the technical component of the process, what problems we encountered in the process and what were the final results of the entire adventure.

A plan as reliable as…

We tried in advance to protect ourselves from a possible hack, so a prerequisite when creating the entire feature was that it could be disabled. In the unlikely (as it seemed to us) case that the new design turned out to be noticeably worse than the old one, we wanted to be able to pull the conditional switch and painlessly roll back all the changes. And then pretend that nothing happened.

Briefly, the plan consisted of the following points:

1. We find a suitable visual style for the UI – we draw several key reference screens that will become references for everyone else.

2. We draw all screens and windows in a new design – already in Figma. In total, we had about 90 screens and windows in the game then. The layouts for them were originally made in Photoshop and stored on Google Drive.

3. When we draw all the screen layouts in the new design, we begin to gradually transfer them to the engine, rearranging them, but not connecting them yet.

4. As soon as a critical mass of redesigned screens is accumulated and the future system of UI elements and components within Unity is formed, we begin to reconnect the screens in the engine, while simultaneously completing the missing ones.

5. We test the new interface screen by screen through QA, fix the bugs found and release it.

6. We record and analyze the results.

There was no deadline initially. It appeared later, naturally, as the release dates for the PC version approached.

The whole plan looked quite promising. Having a list of all the screens awaiting rework, we could easily monitor and predict each stage. In theory.

Search for a new visual UI style.

The setting of our game is World War II. This often implies skeuomorphic interface style. That is, buttons, dies and panels, stylized using real materials and textures, with a muted palette dominated by gray-brown-green colors.

Examples of skeuomorphic interfaces from games with similar settings

In the redesign, we wanted to move away from this concept and aimed for a lighter, simpler and more energetic visual that evokes associations with sports competitions. We also wanted to develop a set of memorable visual elements that would make our game stand out from others.

After several weeks of brainstorming, the art department managed to find an original (and not associated with war) interface visual that caused a positive reaction in the studio.

Examples of “what was then” screens.

Rendering screens. Figma instead of Photoshop.

I'll start with a little explanation for those who don't understand where Photoshop came from. What does it have to do with interface development?! That's right, practically none. No web designer in his right mind would build interfaces in this program, but it's common practice in game studios. The logic here is as follows: games have an increased number of “artistic” UI elements per square pixel. Sometimes game interfaces are real works of art. Complex effects and styles, masks, texture fills, a huge number of layers with a whole zoo of blending modes… Players are accustomed to very high artistic standards in this area. The usual web designer packages are no longer enough and Photoshop comes to the rescue. However, in recent years Figma has been slowly but surely crowding out the old man even in game studios. Unlike Photoshop, Figma allows you to conveniently create and maintain a system of interface components and work with dynamic layouts.

So that you understand the pain of working as a UI/UX designer in Photoshop, here’s a simple example. You can create a library of components in it (for example, buttons), but for any changes to a specific copy, from the size of an element to the text inside, you need to break its connection with the library, turning it into an independent entity. A trivial task suddenly turns into a titanic quest.

I’ll also mention my favorite “cherry” on the cake – PSD file sizes:

Let me remind you, we stored them in the cloud, which needs to be updated regularly.

Rearranging screens in Unity.

So, couple weeks months of work and, as if by magic, we have mockups of all screens in a new design and with an amazing system of components!

Then the fun part begins – transferring the layouts to the engine.

Before starting the layout, we divided all the screens into three logical groups. The first includes those that players see constantly: the main menu, inventory, preparation for battle, etc. They are an essential part of the basic gameplay loop. Until they were finished in a new style, we were not ready to release the redesign feature. This also includes screens that are in one way or another related to the monetization of the game.

The second group includes screens and windows that players do not open every time or only under special conditions. For example, the account linking window, player profile or event rules. It was decided that no one would die if the visuals of these screens were updated gradually, from release to release.

The third group of screens was essentially just a combat HUD, the gameplay part of the interface.

What does the combat HUD look like?

We decided not to touch it at all in the first iteration of the redesign.

Firstly, it is a rather isolated space with its own rules and visuals. For example, only there we used round buttons, which are more convenient for quick blind use.

Secondly, players are very sensitive to any changes in the gameplay interface. Colleagues from game studios who have already gone down this path said that players have an extremely negative attitude (even to the point of mass “boycotts”) towards any changes to the gameplay interface. Even if, according to analytics, the new version works better than the previous one. We decided to first see how the redesign of the meta part of the game goes, and only if successful, move on to the issue of changing the combat HUD.

Whether it is necessary to release all the screens at once in a redesign format or is it better to do it in parts is still an open question for me. It is clear that it would be better to release everything at once (and without bugs), but this is spherical correctness in a vacuum. At the beginning of working with the feature, I adhered to the concept of “releasing everything as a whole,” but in the end I changed my shoes and now I think that such an approach is wrong. In reality, running two different working versions of the interface in parallel is still a “pleasure”. The sooner you can stop duplicating screens, the easier, simpler and more predictable the life of the entire project will become.

As far as I know, none of those who released the interface redesign piece by piece encountered any noticeable negativity from players about this or any drops in metrics. In general, I think that this is an individual matter and depends on many factors: resources within the studio, deadlines, differences in the visuals of the old and new versions of the UI (whether the difference is very noticeable), etc.

Resource problem. Interfaces and outsourcing.

Our team is relatively small. There is only one UI/UX designer. Since, in addition to the UI redesign, it was necessary to support the existing screen system, and in addition to this, maintain a constant flow of new features, we immediately understood that it was better to delegate the work as much as possible. There were two attempts. One with the involvement of interns, the second with the help of an experienced outsourced specialist. Unfortunately, both failed, and it was a useful lesson for me.

Interns consumed a lot of time and required almost manual control, without achieving the desired quality. To be fair, we didn’t really hope for this option, but we still gave it a chance.

With outsourcing, a sad story of a different kind emerged. Despite the fact that the skill and experience of the involved specialist were not in doubt, during the month of cooperation we did not receive a single completed turnkey screen. This happened for several reasons. The main thing, in my opinion, is the fundamentally unattainable degree of integration of outsourcing into the internal structure of the project. The interface of any game is a unique thing, full of its own features and features, crutches and bicycles. And there are two options. Or a person “outside” (who can lead N projects besides yours) begins to meticulously understand everything, asks tons of questions, is in constant contact with programmers and spends a huge amount of his time and “mental fuel” on this. As a result, in this case he most likely receives an offer and joins the team on a permanent basis. The second way is when the outsourcer ignores all these problems and silently does as he is used to and as quickly as possible. In our case, this led to the fact that the simply made screens were simply not suitable for further work. It turned out to be impossible to reconnect them with little blood, because… The interior of the prefabs was radically different from the original one.

As a result, after a couple of months, we found ourselves in a situation where the deadlines had already been missed, but the conversion had not actually begun. There were no screens ready for connection.

This was, perhaps, the last moment when it was still possible to give up and abandon the idea of ​​redesign, costing relatively little blood. But by that time we were already unstoppable! I had to roll up my sleeves, squeeze in time and do everything with the forces that were available.

Connection of laid-out screens.

As I already noted, we did a redesign with a feature flag, that is, with the ability to quickly and easily turn it off. To do this, the project actually stored two (actually three – still PC) versions of screen prefabs and visual configs: for the old interface and for the new one. They were spaced in such a way that (in theory) removing all elements of the old interface would break a minimum of connections in the new one. All sprites were also duplicated: in the old interface only old textures were used, in the new interface only new ones were used, partially duplicating the old ones.

Since changing the screen visual most often entails changing the internal structure of prefabs (the number of “layers”, their grouping and position, animations, naming), after layout it is necessary to reconnect all the code to new components. Moreover, the fewer logical changes in the new screen after the redesign, the better. The ideal situation is when the screen can be launched immediately after layout and without errors. Unfortunately, in our case this did not happen often.

Not knowing even the basics of C#, I could only simply, like a zealous poor student, “copy” the structure from old prefabs. Often I simply did not understand why this or that element magically stopped working in the new design, although it functioned perfectly in the old one. This gave rise to many problems and required a lot of subsequent corrective work on the part of programmers.

The stages that we eventually arrived at and which more or less guaranteed the absence of errors on the redesigned screens looked like this:

1. The layout designer assembles the screen and connects it to the best of his ability. Usually, after this, the screen did not start “out of the box” and it is not yet possible to view it in different variations in the game.

2. The programmer connects the screen, ensuring its working condition.

3. The screen is returned to the layout designer for finishing touches. It is checked how it works inside the game, in different versions and on different devices in the simulator. Most visual bugs are caught at this stage.

4. After such an initial check, the screen is transferred to the testing department, where it is tested “like an adult.” At this stage, the layout designer and programmer only fix bugs as tickets are received from QA.

5. When the flow of bugs dries up, we consider the work with the screen to be successfully completed and move it to the folder with “ready” prefabs.

Even with so many stages, the volume of bugs that eventually leaked into the release was significant. So significant that it was reflected in basic metrics like ARPDAU during AB testing after the feature was released. The negative effect was softened by the gradual rollout of the feature, so that the crudest version was seen only by a small number of players, thanks to whom we were able to find and fix most of the problems.

For example, in the very first days we were faced with the fact that players with a paid battle pass in the new version of the interface lost the opportunity to collect rewards for quests. For such players, the feature had to be disabled until the bug was fixed. That is, people with a new UI design, after purchasing, received a “downgrade” of the interface to the previous state.

And believe me, this was far from the only problem.

In general, the entire redesign process from the starting signal to the first release took us about 10 months. Of those, the first six months were mostly moving screens to Figma with parallel rendering in a new style. This happened in the background, between current tasks and was carried out by the designer, which is why it took so much time. The active work phase took 3-4 months, during which, in addition to the designer, developers and testers were involved. After several releases with edits and bug fixes, the results of the version with the new UI finally stabilized, and it became possible to discuss and analyze the data obtained.

What about the metrics?

Frankly speaking, I did not expect any noticeable and definitely positive changes after the introduction of the new UI. Still, the feature did not affect the gameplay and did not introduce fundamental new entities. The main changes concerned the internals of the project and the visual component.

Colleagues from game studios who went through the same path said that their interface redesign actually improved the metrics “on average for a hospital,” but with many nuances. Somewhere (mostly) it became better, somewhere a little worse. In some places it is noticeably worse. The effect also varied from country to country. The same screen in the new design could show higher metrics in Germany and lower ones in Korea.

In our case, the main measurable positive effect of the UI redesign was that the retention of new users who returned to the game on day 1 noticeably increased during the redesign:

The difference for the second day was +10.4%, for the third +7.2%, for the seventh +3.2% in favor of the new UI. For old players, the difference in retention is also fixed, but in the region of only 1% in favor of the redesign.

ARPU for new users has not changed. The conversion rate among old players remained unchanged, while among new players it increased slightly. On average, it turned out to be approximately +0.5% in favor of the redesign.

The ARPDAU of the old players in the redesign decreased, but then gradually recovered. Most likely this was due to bugs in the new UI.

If you analyze the feature solely from a financial point of view, there was not much point in the redesign. Taking and comparing the numbers it was/was, we will see that the redesign will pay back the cost of its development in about two years. Yes, Warren Buffett would laugh heartily at such “investments,” but I will remind you that in addition to the (initially low) financial expectations from the redesign, it was needed to adjust the image and brand of the game and the company, as well as to solve some technical problems. I find it difficult to translate these components of the feature into a monetary equivalent.

That's all the objective data I can share with you. There is also an array of subjective feedback.

Player reviews.

People, as you know, do not like to relearn. After a certain time, any, even the most inconvenient, but familiar interface becomes… well, acceptable. And when it is changed, it most often causes dissatisfaction among users. In our case, the changes were almost entirely visual, so I was hoping that we could avoid a lot of negativity. In vain! The feedback received from the players can be called “mixed” at best. They gave us a lot of stuff and to the point, mainly for the numerous bugs on the release.

As expected, UI bugs outside the game HUD did not particularly bother the players, but any interface problems in battle were critical for them and greatly affected the ratings in the stores.

It is worth keeping in mind that reviews are just the tip of the iceberg, the opinion of an active minority. The vast majority of players will not even bother to start a debate with the developers. They will silently vote with their time and rubles. Therefore, it seems to me that changes in metrics always show a more objective picture, and live feedback from players only allows us to understand and catch their most noticeable and severe pains.

Results.

What I can ultimately advise to those who are also thinking about redesigning the interface of their game:

• If your project has been in operation for less than a year, or if it has not even gone into operation yet, do not think about a redesign. If you are unhappy with the current performance of the game, tuning the visual UI most likely will not save them, there will be no “rocket”. Focus on other, more important game mechanics. Here I will make a reservation that this advice does not apply to UX. Improve the usability of the interface whenever possible!

• The purely financial benefit from the redesign in our case was expressed exclusively in an increase in Retention. For our project, it does not have such an impact on income, but for games with more advertising monetization, this can be tantamount to increasing income.

• Do not redesign the interface if you already feel a lack of resources, time and human. Adding another one to the constant rush from above is a sure way to lower the overall quality level on all fronts.

• Devote a sufficient amount of time to those stages that are, as it were, “between” the areas of responsibility of different departments. As practice shows, they are the most problematic. Who controls quality at each stage? Who carries out the acceptance and transfer from one stage to another? Who rules the pop-up joints and when? Who can return a screen from one stage for revision to the previous one and under what conditions? Who should I contact in case of problems?

• If possible, release the redesign in separate screens, do not wait until the last minute in the desire to release everything at once.

• Be mentally prepared for drawdowns and problems in the first days of release. The interface is like the glue that holds the whole game together. There are a lot of connections and there are also chances that something will go wrong. Well, or option “B”: set aside a lot of time for testing.

• Do not outsource sensitive tasks such as reassembling the interface or creating a design system. If necessary, hire someone on staff. This way you will save yourself time, money and nerves.