Game UI redesign. Is it worth it?

Redesigning the UI in a game that has already been released is a tricky topic. When, how, and most importantly, why you’d better (not) tackle it? In this article, I will discuss how this issue was addressed in our game and share my thoughts and advice.

Who am I, and what project is this?

My name is Boris Kiselev, and for the past 12 years, I have been working as a UI/UX designer in various mobile gaming studios. I will be discussing World War Armies, a cross-platform RTS game set in a military environment, developed using the Unity engine.

At the time of writing this article, the game had been operational for about a year and a half. The UI that was released was initially conceived as “rough” and developed in a rather chaotic manner. I think many small gaming studios are familiar with this situation. Until your project generates sufficient revenue, prioritizing speed and flexibility in the development process often seems more important than investing in meticulous, pre-designed architecture. Right?

Over time, our UI system became cumbersome, slow, and unclear. The interface itself, though quite functional, became hopelessly outdated. The team started to question the quality of our UI. It fell below the industry standards, and we believed our game deserved better.

This is when the idea of a redesign was born.

Looking ahead, the entire redesign process, from the initial go-ahead to the first release, took us about 10 months. Of these, the first six months were mainly spent on finding the new UI look and transferring each interface to Figma. This was accomplished by a designer during intervals between more urgent tasks. That’s why this stage took us so long. The active work phase lasted for 3–4 months, during which developers and testers were involved.

Goals and expectations.

Besides visual changes, we set ourselves several other tasks:

• Combine the UI redesign with a rebranding of the project and the entire studio.
• Move away from the World War II aesthetic and introduce a more energetic and sporty feel.
• Convert all the mockups to Figma instead of Photoshop.
• Prepare a mobile-first interface to accommodate the upcoming PC release.
• Organize the file system related to the interface inside the project.

It was immediately apparent that until the redesigned UI launch, we would need to somehow maintain the existing old UI. This meant that all new product features introduced during this ‘transition’ period would have to be implemented in both the old and new designs. It’s like driving an old car that constantly breaks down, while simultaneously building a second, fresher, and more fashionable one. Doesn’t sound very reliable, does it?

Vividly aware of the number of unknown factors and things that could go wrong, we tried to protect ourselves from a possible fiasco in advance. A mandatory condition was set: in the unlikely event (as we thought) that the new design turned out to be noticeably worse than the old one, we wanted to be able to pull the conditional plug and roll everything back painlessly. Then, we could pretend that nothing had happened.

What were our expectations? Ambiguous. Within the studio, there was no understanding of how exactly the redesign would affect our game. Colleagues from other studios shared that it worked out for them and actually had a positive and measurable impact. But this is not a guaranteed outcome. Also, we couldn’t rule out the possibility that the changes would lead to a significant drop in metrics. It may sound risky (taking on a big feature with this amount of risks and unpredictable results), but it’s a fairly common situation for visual tweaks. Subjectively, as developers, we might believe that the innovations are beneficial to the project. However, they either have imperceptible effects on metrics, or it’s not clear how to measure their impact. We agreed to be ready to accept the risks and just dived into it headfirst.

In the next sections, I will talk about the technical aspects of the process, the problems we encountered along the way, and reveal the final results of the whole adventure.

The Plan.

In broad strokes, our plan for the redesign feature included six steps:

1. Find a suitable new visual style for the UI. First, we would create several key benchmark screens to serve as references for all others.
2. Redraw mockups for all screens and windows in the new design — in Figma. We had about 90 screens and windows in the game at that time. The mockups were entirely created in Photoshop and stored on Google Drive.
3. Once we have redrawn all the screens, we gradually transferred them into the game engine, laying them out, but not connecting them to code yet.
4. Once a critical mass of reworked screens is reached and the system of UI elements and components inside Unity is formed, we begin by reconnecting the screens in the engine. Simultaneously, we designed the missing mockups.
5. Roll out the new interface through QA, screen by screen, fix any bugs found, and then release.
6. Document and analyze the outcome.

The entire plan seemed quite clear and feasible. With a list of screens awaiting redesign, we could easily monitor and forecast each stage. In theory.

Initially, there was no deadline, but it appeared much later as the release dates for the PC version approached.

Step 1. Searching for a new visual style for the UI.

Given that our game is set in World War II, the typical approach involves employing a skeuomorphic interface. In this design style, buttons, panels, and widgets mimic authentic materials and textures, with a subdued palette dominated by grey, brown, and green

Here are some examples of skeuomorphic interfaces from similar games with a comparable setting:

KARDS

World Conqueror 3

Warpath: Ace Shooter

In the redesign, our goal was to step away from this concept and aim for a lighter, simpler, and more energetic visual, evoking associations with sports competitions instead of war. Additionally, we aimed to develop a set of memorable visual elements that would make our game stand out from its competitors.

After several weeks of brainstorming, the art department identified images that received a positive reaction within the studio, and they became the foundation for the redesign:

Old UI vs Concepts vs New UI (click to see in full size).

Step 2. Designing mockups. Figma instead of Photoshop.

I’ll start with a brief explanation for those unfamiliar with why Photoshop is mentioned here at all. What does it have to do with interface development?! Well… No sane web designer would assemble interfaces in this software, that’s for sure. But in game studios, it’s common practice. Why? Games generally have a higher amount of “artistic” UI elements per square pixel. Some game interfaces are truly beautiful pieces of art, featuring complex effects, styles, masks, textured fills, and a multitude of layers with various blending modes. Players are accustomed to exceptionally high artistic standards in this area. Standard web designer toolkits often fall short, and Photoshop comes to the rescue. However, in recent years, Figma has been slowly but surely pushing the old-timer aside, even in game studios. This is primarily because, unlike Photoshop, Figma allows the creation and maintenance of a system of interface components and offers a dynamic layout

To give you an idea of the depths of suffering of a UI/UX designer working in Photoshop, here’s a simple example. You can create a library of components (for example, buttons), but any changes to a specific instance, whether resizing the element or adjusting the text, require breaking its link to the library component. A trivial task of changing all buttons’ text size from 30pt to 32pt, suddenly turns into a titanic quest.

I can’t help but mention the icing on the cake — the size of PSD files:

Note that we had to store them in the cloud, which needed to be regularly updated. It’s painful.

Step 3. Layouting screens in Unity.

So, after a couple of months of meticulous work in Figma, as if by magic, we have layouts for all screens with the new visuals and an amazing system of components:

Just beautiful!

Now the most interesting part begins — transferring the layouts into Unity Engine.

Before the work started, we divided all screens into three logical groups. The first group included those screens that players see constantly: the main menu, the collection, the battle management screen, etc. These are an integral part of the players’ basic game cycle. We weren’t ready to release the feature until the redesign of these parts was finished. This group also included screens related to the game’s monetization, like Battle Pass.

The second group consisted of screens and windows that players see rarely 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 essentially consisted only of the battleHUD, the gameplay part of the interface:

In-battle HUD

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

Why? First of all, it is a fairly isolated space with its own rules and design. For example, it’s the only place where we use round buttons, which are more convenient for quick, blind use.

Secondly, players are very sensitive to any changes in the gameplay interface. Colleagues from other studios who have already gone through the redesign process told me that players react extremely negatively (up to mass “boycotts”) to any changes in the gameplay interface. Even though the new version may (according to analytics) work better than the previous one. We decided to assess how the redesign of the game’s meta part goes. If it met our goals, then we would move on to the battle HUD.

Whether to release all screens at once in the redesigned format or to do it gradually is still a question for me. Clearly, it would be better to release everything at once (and without bugs), but this is idealistic thinking. At the beginning of redesigning the game, I had adhered to the concept of “release everything at once”, but towards the end, I changed my mind. Now, I believe that such an approach is erroneous. In reality, maintaining two different working versions of the interface simultaneously is quite a challenge. The sooner we get rid of the duplication, the easier and more predictable the project’s life will become.

As far as I know, none of those who released interface redesigns piece by piece encountered noticeable negativity from players on this matter or metrics drops. Overall, I think that the decision whether to release the redesign in chunks or not depends on many factors: the studio’s internal resources, set deadlines, differences in the visual style of the old and new UI versions (how noticeable the difference is), etc.

Resource issue. Interfaces and outsourcing.

Our Hypemasters team is relatively small. We only have one UI/UX designer. Given the need to redesign the UI while maintaining the existing screen system and managing a constant stream of new features, we recognized early on that it was essential to delegate as much work as possible. We made two attempts, one involving interns and the other hiring an experienced specialist from an outsourcing company. Unfortunately, both attempts failed, and it was a valuable lesson learned.

The interns consumed a significant amount of time and required almost constant supervision. In the end, they were unable to deliver the desired quality level. While we didn’t have high expectations for this option, we still gave it a chance.

Collaboration with the outsourcing company turned into a different kind of disappointment. Despite the skill and experience of the hired specialist, we did not receive a single completed screen. This happened for several reasons. From my perspective, the main issue was the fundamentally unattainable level of integration of the outsourcing specialist into the project. The interface of any game is a unique thing, full of its own features, quirks, crutches, and workarounds. Essentially, there are only two options for the outsourcing specialist: they can meticulously delve into every aspect, ask numerous questions, maintain constant communication with the developers, and invest a significant amount of time and mental effort, increasing their chances of receiving an offer to join the team permanently. Alternatively, they can ignore these intricacies and proceed with their usual methods, avoiding “redundant” questions. This approach may be energy-efficient, but unfortunately, in our case, it resulted in “final” screens that were not suitable for further work. Reconnecting them to the engine required significant effort due to the drastically different internal structure of the prefabs compared to the originals.

As a result, a couple of months later, we found ourselves in a situation where the deadlines had already been missed, but no screens were ready for integration. This was a critical moment where we could have opted to abandon the entire redesign idea relatively painlessly. But, we were already unstoppable! Therefore, we had to roll up our sleeves, endure some crunch time, and accomplish everything with the hands we had available on the team.

Step 4. Screens integration.

As I mentioned earlier, we implemented the redesign with a feature flag, which allowed us to quickly and easily turn the whole feature off. For this purpose, the project stored two (actually three — included in the PC release) versions of screen prefabs and visual configs. One version was for the old interface and the other for the new one. They were structured so that (in theory) removing all elements of the old interface would break as few links as possible in the new one. All UI sprites were also duplicated: the old textures were used only in the old interface, and the new ones were used only in the new interface. Of course, some overlapped.

Since changes to the visual appearance of a screen often entail modifications to the internal structure of the prefab (the number of “layers”, their grouping and position, animations, and naming), after the layout was implemented, all code snippets needed to be reconnected to the new components. The fewer logical changes in the new screen after the redesign, the better. Ideally, the screen add would run smoothly and without errors immediately after the layout was completed. Unfortunately, this happens rarely.

I am not a coder. Without knowing even the basics of C#, all I could do was copy the structure from the old prefabs, paste it into the new ones, and pray that nothing broke in the process. Like a diligent student attempting to cheat on an assignment without understanding it, I often couldn’t grasp why a specific element would magically stop working in the new design, even though it worked perfectly in the old one. This led to numerous issues and required a lot of subsequent corrective work from the developers.

The phased approach we eventually settled on, which aimed to more or less guarantee the absence of bugs in the final screens, looked like this:

1. The markup designer assembles the screen and connects code snippets to the best of their abilities. Usually, after assembling, the screen does not function properly, preventing it from being tested in the game.
2. The developer refines the screen code, ensuring its functionality.
3. The screen is then returned to the markup designer for visual cleanup and testing to ensure it functions properly within the game. This includes testing across different variations and on various devices in the simulator. Most visual bugs are identified and addressed at this stage.
4. After this initial check, the screen is passed to the QA department, where it is tested more thoroughly. Here, both the markup designer and the programmer collaborate to address and fix any bugs identified during QA testing.
5. When the flow of bugs dries up, we consider the work on the screen to be completed and move it to the folder with “ready” prefabs.

Step 5. Feature release.

Even with such a pipeline, a significant number of bugs that made their way into the release build. These bugs impacted basic metrics like ARPDAU during the AB testing that started after the initial, cautious feature release. This negative impact was mitigated by the gradual rollout of the feature, ensuring that only a small number of players saw the rawest version. Thanks to them, we were able to find and fix most of the problems.

For example, we encountered a bug where players who purchased a battle pass were unable to collect quest rewards. For such players, we had to disable the feature until the bug was fixed. In essence, users with the new UI experienced a “downgrade” to the previous interface state after making a purchase.

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

After several releases with fixes and bug fixes, the results of the version with the new UI finally stabilized, allowing us to discuss and analyze the obtained data.

Step 5. Evaluation of the results. What about metrics?

Frankly speaking, I didn’t expect any significant and unequivocally positive changes after introducing the new UI. After all, the feature did not impact gameplay or introduce any new functionality. The main changes were related to the project’s internals and the visual component.

Colleagues from game studios who had gone through the same process shared that UI redesign improved projects’ metrics “on average,” but with many nuances.In most cases, some projects saw slight improvements, while others experienced declines. In certain cases, the impact was notably negative. Moreover, the effect varied across different countries, with the same redesigned screen showing higher results in Germany and lower in South Korea.

In our case, the main measurable positive effect of the UI redesign was on retention. For new users, the rate of returning to the game on the 1st day was noticeably higher:

The difference for the second day was +10.4%, for the third +7.2%, and for the seventh +3.2% in favor of the new UI. For old players, a smaller difference in retention was recorded, around only 1% in favor of the redesign.

ARPU for new users did not change. Conversion to paying users among old players remained unchanged. However, among new players, it slightly increased. On average, it was about +0.5% in favor of the redesigned UI.

ARPDAU for old players initially decreased in the redesign, but gradually corrected. Most likely, this was due to bugs in the initial releases.

If we analyze the feature solely from a financial point of view, the redesign may not seem to make much sense. Comparing the numbers before and after, we see that the redesign will recoup its development cost in about two years. Yes, Warren Buffett would have laughed heartily at such “investments”. However, I would like to remind you that in addition to (initially low) financial expectations, it was necessary, as we needed to adjust the game’s image, the company’s image and brand, and resolve some technical issues. I find it difficult to convert these aspects into a monetary equivalent.

That’s all regarding the objective data I can share with you. Additionally, there was an array of subjective feedback.

Players’ feedback.

It is well-known that users don’t like relearning. After a certain amount of repetitions, even the most inconvenient but familiar interface becomes… well, acceptable. And when it’s changed, it often causes dissatisfaction and frustration among users.

The interface changes in our case were almost exclusively visual, so I hoped that we would be able to avoid major negativity. In vain! I would describe the feedback we received as “mixed” at best. Our players pointed out a lot of issues, mostly related to the numerous bugs in the release.

All in all, UI bugs outside of the gameplay HUD didn’t bother players much, but any interface-related problems during battles were critical and significantly affected the application’s ratings in stores.

It is also worth mentioning that feedback is only the tip of the iceberg, representing the opinion of an active minority. The vast majority of players will not bother to engage in debates with developers; they will silently vote with their time and money. Therefore, in my opinion, changes in metrics always provide a more objective picture, while live feedback from players allows us to understand and catch the most noticeable bugs and problems.

Here are some examples of the feedback we received:

“I really like it, a lot smother than the old one”

“It’s good! Feels like a new game.”

“Old was better.”

“It’s good, but it’s more laggy than the past version.”

“Beat and tidy, good improvement.”

“I like the clean new look. It’s a nice refresh from the dull generic animation it used to be.”

“Looks very clean and polished.”

“It’s good, but I prefer the older version.”

Conclusions:

To those who are also considering redesigning their game’s interface, I can advise the following:

• If your game was launched less than a year ago or hasn’t been released yet, don’t bother with redesigning the UI. If you’re not satisfied with the current performance of the game, tuning the UI visuals is unlikely to improve it. Focus on other, more critical (and probably missing) game aspects and mechanics. It’s important to note that this advice doesn’t apply to UX! Improving the interface’s usability whenever possible is always worth it!
• The measurable financial outcome of the redesign, in our case, was primarily reflected in the increase in retention. While this may not have a significant direct impact on revenue for our game, for games with more ad-driven monetization, it could increase revenues.
• Don’t redesign the interface if you’re already feeling a lack of resources, both in terms of time and manpower. Adding another layer of chaos on top of the constant bustle is a surefire way to lower the overall quality across all fronts.
• Allocate a sufficient amount of time to the stages that fall “between” the responsibilities of different departments. As practice shows, these are the most problematic. Establish clear guidelines for quality control at each stage. Who controls the quality at each stage? Who accepts and transfers screens from one stage to another? Who fixes emerging issues, and when? Who can revise a screen and send it back to the previous stage, and under what conditions? Who’s responsible in case of problems?
• Consider releasing the redesign in stages, screen by screen. Don’t wait until the very last moment in an attempt to release everything at once.
• Be mentally prepared for setbacks and problems in the first days after the feature release. The Interface acts like glue, it binds the entire game together. There are many connections, and there’s a good chance that something may go wrong. Well, or option “B”: allocate a lot of time for testing.
• Don’t hire outsourcing for sensitive and complicated tasks. If necessary, hire someone in-house. This way, you’ll save time, money, and nerves and gain more control over the results.

For those of you who want to evaluate the results of our work and the decisions we made, look for World War Armies on Google Play, Apple App Store, and Steam.

If you have any questions or want to keep in touch, contact me on LinkedIn.

That’s all from me, thanks for your attention!

Yours, Boris Kiselev.