Satisfactory

1. Documentation of screens, ALL the screens.

First step was to quite literally gather every screen that exists, as there were no existing documentation of every screen or feature available. We also documented which screen led to where, or which screen could be accessed from another screen.Many days were spent for this given how indepth Satisfactory is, but we managed to document everything (except maybe one! there's always one) which led to a much clearer vision for the workload ahead of us, but also to serve as a framework for actual documentation now.

2. Navigation, and menus within menus.

Satisfactory was clearly a game built for PC. Even its player demographic acknowledges the huge amount of hotkeys, mouse-hovering and jumping between menus. A controller has no cursor, so every screen needed a clear way to move focus around.

The challenges: knowing where your 'mouse' is on, eliminating player confusion, making features feel seamless.
So we decided on a few things.

Highlighting areas of focus, not just where your 'imaginary mouse' is.

On PC, navigating is very straightforward. You click, or you press a button on your keyboard- you get there. But on controller it's not quite the same. In addition, Satisfactory has a lot of information displayed on the screen. How does this work when the intended audience would now possibly be playing from their sofas?

As seen on the right, we implemented a 'highlight area' function shown as a strong orange outline, basically splitting up each screen to segments that would be acting as a visual cue to help aid the player's sense of navigation. You choose a segment with (RightStick), you then navigate within the segment (LeftStick/Dpad).

This also helps players sitting from further away a screen, or even those on smaller screen than a monitor (which will be covered in Steam Deck verification).

Nesting interactions within an interaction

Other than the fact we had limited space for button prompts, especially when considering all the languages that were localised, we also didn't want to overwhelm the player with all obvious interactions on the screen. So we nested certain interactions (which are less likely to need to be used fast) to be kept behind the [Left Trigger]. To access these, simply keep holding [LeftTrigger] while pressing another button of choice. This allowed us to keep the most core and popular interactions on the immediate face buttons, while still being able to access the others easily.

Button prompts and interactions

We ensured each action felt intuitive. Anything destructive? Always some time for players to back off, so we ensure a button hold is needed. Each interaction in the game has been carefully planned out on the controller pad and each button to reflect what is most used and intuitive, while also being ergonomic as to not strain the player (especially when the average Satisfactory player is pretty hardcore in hours!)

3. Design Patterns - grouping them up by families and reworking screens

The great thing about full visual documentation? You get everything in a quick birds eye view, and are now able to sort all the screens existing in the game. Since our situation is pretty unique where we can't control the interface design of a screen, but only how you interact with it, time was spent assessing each screen. Each screen was grouped into categories on how much similarities they share (inventory screens, customisations, or grid-heavy, etc) and those that share similar components with one another like having a map or list (which we can then ensure the same interactions remain).

As several screens either had a complete revamp for PC or are completely new additions to 1.1 and beyond, we accomodated everything and made sure we stuck to the same 'language'.

4. Playtesting and Feedback Rounds

Perhaps my favorite part of everything. Getting to know what players think. We hold frequent playtests amongst the internal team, and also occasional ones vetted by Coffee Stain themselves. The best part was when the Experimental builds were released prior to 1.1 (official Console and Controller Support release), and players had a first look at what we cooked up with the controls. So much valuable insight into how the player base felt, and what could have been improved. We knew we were on the right track when some grievances voiced we already things we were aware of and intended to fix soon enough. From bug tickets to implementing fixes, we addressed many issues that could be improved or needed to be fixed.

5. Readability and Accessibility

On a console, players sit across the room from a TV, or hold a Steam Deck centimeters from their face. UI built for someone leaning over a desk monitor doesn’t always survive that, and Satisfactory has a lot of packed, dense information: item names, recipe lists, production numbers, tiny icons. We ensured things like having proper contrast on the background for text, clear focus states with orange highlights as the player's visual anchor, options to enable toggle for actions rather than a hold and then general resizing of text. More on this in the Steam Deck verification section as well.

6. Steam Deck Verification

If people thought getting the game certified on console was difficult enough, Steam Deck verification was another adventure. I was incharge of getting the game Steam Deck verified. Adjusting everything we had for a MUCH smaller screen was a feat itself, but with all the testing and teamwork with our great programmers, we successfully got that green tick - Satisfactory Steam Deck verified!

I spent a lot of hands-on experience with the Steam Deck to get real feedback, coined up a "Finger for Comparison" term for fun (mainly so that remote colleagues could understand what I mean), and documented all the changes that would need to take place. It involved a first pass of various changes including enabling a handheld mode by default if the Deck was detected, larger text and icons, and ensuring the FTUE (particularly important as the Deck verification playthroughs seem to target first time experiences) was as smooth as possible.