Author: Oliver Storeide Olovsson

As a Quality Assurance (QA) intern with a growing interest in User Experience (UX), I wanted to help make Iterum as frictionless to play as possible. In strategy games especially, a large part of the player experience is shaped by how information is presented. It needs to be compact, easily accessible, and easy to understand at a glance. At the same time, the interface should feel visually cohesive and pleasant to use over long play sessions. Thus, by work began on Iterum’s Settlement UI.

During my internship, I gradually shifted from purely testing usability issues to actively redesigning parts of the UI. I focused primarily on the HUD and Settlement View. This post walks through that process, the problems I identified, and what I learned along the way.

Issues

One of the first things I noticed was that much of the existing UI felt hastily assembled. Similar elements were not aligned, spacing was inconsistent, and many components didn’t align within their containers. While none of these issues were game-breaking on their own, together they created unnecessary friction and visual noise.

Beyond visual inconsistency, there was also missed functional potential. A clear example was the Settlement list. When entering a scenario, this list is visible and useful for getting an overview of all player Settlements. However, once the Settlement View is opened, the list is partially hidden. This removes one of its most valuable use cases: quickly comparing the status of multiple Settlements and switching between them without extra clicks.

There were also smaller usability issues, such as resources in the Settlement View being displayed primarily as percentages. While technically correct, this makes it harder for players to understand relative changes and trends at a glance. Especially when values fluctuate frequently.

Goal

The main goal of this work was to reduce friction and cognitive load in Iterum’s Settlement UI by:

• Making important information visible at the right time, without covering other useful UI.
• Consolidating related systems into fewer, clearer views.
• Improving alignment, spacing, and consistency so the UI feels intentional and readable.
• Preserving as much existing functionality as possible while making it easier to understand.

A concrete sub-goal was to move key elements from the right panel of the Settlement View into the left panel. This would allow the Settlement list to remain visible and expandable instead of being obscured.

Approach

I started small by redesigning the Unit Inspector. This allowed me to learn the UI tools, test whether I could work at the required level of precision, and experiment without touching more complex systems. Carefully measuring spacing and aligning elements pixel-perfectly was surprisingly satisfying, and it also made the designs much easier to reason about from an implementation perspective.

This first pass went well, and I produced several variants that were presented to the team for voting. Two of them were very close in preference, so we ended up combining their strengths into a final version.

Original(left) and Final Concept(right)

Encouraged by this, I began planning broader UI changes. I created a master ticket (epic) covering all UI areas that could potentially be improved, with short notes describing what might change in each. From this, child tickets were created as user stories outlining specific problems, proposed changes, and intended outcomes. This made it easier to track progress and keep the work aligned with development priorities.

Settlement view: First draft

When moving on to the Settlement View, I applied what I had learned from the Unit Inspector: instead of starting from scratch, I worked directly on top of the existing UI. I matched the original size and layout first, then gradually refined it using clean, rounded measurements and consistent spacing.

Information density

For the rest of the view, the focus was on making information denser without making it harder to read. Resources were still grouped into Management, Basic, and Complex resources, but optimized to take up only half the width. This freed up space while maintaining familiar structure. For Happiness and Food, text was added to show Equilibrium and maximum values, giving players more actionable information at a glance. Food tiles selection was expanded to show how much of the population are assigned to food production.

Large numbers were another readability issue. Showing full values can be both visually noisy and harder to parse quickly, so I limited displayed numbers to three digits with suffixes (for example, 1 500 becoming 1.5k or 3 654 987 becoming 3.65M). When managing large resource pools, the exact smaller digits are rarely meaningful, and removing them improves clarity.

With the extra space gained, I began integrating elements from the right panel into the left panel: the Improvements list, Construction queue, and Recruitment queue. The queues were placed at the bottom, as they don’t require constant attention.

Improvements were placed above the Construction queue to reinforce their relationship, while the Garrison was positioned to the right of Improvements, since it otherwise required opening a separate window.

This version worked functionally but felt somewhat cramped at the bottom. To reduce visual density, I explored removing the Garrison from the main view and instead presenting it as a pop-out panel, similar to how embarked units are shown in transport ships. This would keep it accessible without overcrowding the main panel.

Settlement view: Final Concept

When gathering feedback on Iterum’s Settlement UI, one issue was raised: if too many Objectives were active, they could be covered by the Settlement View. To solve this, the Settlement View was extended upward to sit directly beneath the system buttons, allowing Objectives to move to the right side under the top bar when the view is open. This required aligning the Settlement View with the system buttons themselves.

This also opened up the opportunity to integrate the Encyclopaedia into the system buttons. Different sizes, orders, and inclusion options were voted on by the team.

A new button width was chosen that fit all system buttons while keeping the original height. The Settlement View was scaled to match the width of these buttons and align directly beneath them. This allowed the top illustration window to be larger and the text within it to scale up slightly.

At this stage, we also received updated UI assets with reduced corner indenting. This made more efficient use of space possible. Resource buttons could be shorter in height, queues could show four items instead of three, and text across the Settlement View could be increased from size 10 to size 16 for improved readability.

Instead of placing Improvements and Garrison side by side as in the first draft, Improvements were expanded to fill the full width between the resources and queues. This created a clearer hierarchy and reduced visual clutter.

Several variants with different resource orders and layouts were created and voted on. In the end, the team chose to keep the original resource order for familiarity, with Management at the top and resources at the bottom. Food tiles were moved into the Management section instead of being split across categories.

ORIGINAL(LEFT) AND FINAL CONCEPT(RIGHT)

End

This project was a rewarding way to combine my QA background with UX design work. It reinforced how closely usability testing, information design, and visual clarity are connected, especially in complex strategy games.

While most ideas for Iterum’s Settlement UI have not been implemented yet, the process helped create a clearer foundation for future work, and I hope it improves the overall experience for players when implemented. I’m grateful for the opportunity to explore this space during my internship and hope others can continue refining and building on these ideas going forward.