Former founder of the Ukrainian studio GSC Game World, Sergiy Grygorovych, is working on a new science-fiction project titled S.T.R.A.N.G.E.R., he told a correspondent of the Interfax-Ukraine news agency, claiming:

First person shooters require to communicate player state information clearly, but often games rely on permanent HUD elements instead of integrating the information into the game world through diegetic UI systems.

The concept for a user interface system is to use close to reality tactical optical technologies, HUD projection on player’s mono glass or visor. The interface will be decided to multiple modes that reveal relevant information only when activated by player.

The critical conditions will be supported by other external in-world feedback, such as signals, light, or sound.

In such approach letting player actively access information manually, increasing immersion and keeping essential feedback available.

First initial concept sketches were created to visualize the potentially expected outcome of the deliverables:

Unfortunately, studies on military technologies interface designs are quite classified.

The most suitable device to my concept was: “BAE Oasys RED-I” (Remote Eye Display – Imager). A monocle HUD for remote viewing thermal images. This is almost exactly what I was looking for, in this case, this device is used to project the whole camera view of the drone or other devices, which makes it quite realistic to minimize the projected information on such HUD to the project needs.

Firstly, possible gameplay information were collected and categorized, creating somehow a base inventory for what interface system needs to communicate.

Next, defining how the player would aces information, it was devide into different access modes.

The information was assigned to specific interface “containers” to make information access digest using only in world things.

Next 3 Personas of player/user were created based on relevant archetypes, behaviors or experience level:

• franchise-returning player
• semi-new player
• new player

And after analyzing and setting the profiles of each player, scenario began to shape.

I tried to set the basic scenario for the conceptual imagining of the game, which was something like:

“A point of interest is located 5 km from the current location and the player is heading on the journey to the next point of interest. The open area outside the safe zone contains different dangers, requiring the player to be prepared before heading out.”

First step of building a prototype began with creating a layout of the HUD. There are 3 split information, first one for detailed health condition, second one for overall body condition and third one for equipment. Based on these 3 containers the whole composition was divided by 3 and filled by hierarchy of information importance. Space at the top was filled with quick overall condition for each of the section to understand the status of each condition.

After filling the space with shapes for all 3 sections details were added. Second line of the scheme below shows how layout’s sections expanded into required details. Basically, I worked with available space that leaded me to defined potion for each information that were requested. At the end I ended up with quite defined layout that can be used for testing on users.

The visuals were artificially generated to support the design clearance for user testing: Background, Display Device, Hands Action.

After developing an HTA and user flow next step was to develop the scenario of low-fi prototype:

After a dangerous situation, your character may have taken damage. You are using the interface to understand what happened, decide what action is required, and check whether the condition changes after treatment.

A low-fi prototype works as a slideshow, showing each stage of the action that would be made by user.

After what, qualitative usability test was made with 2 participants, using a guided click-through prototype of the HUD injury-treatment flow. The prototype was split into 2 stages, stage 1 - when user firstly sees the HUD with issue, stage 2 - HUD after action. So, basically, there were 3 question parts, after each stage and the last conclusion. The question were next:

Stage 1:

1. “What do you think happened here?”
2. “What is the most important information on this screen?”
3. “Where is the problem located?”
4. “How serious does the condition look?”
5. “What action do you think the game expects you to take next?”
6. “Is anything unclear or difficult to read?”

Stage 2:

1. “What changed after the treatment?”
2. “Do you think the problem is solved, reduced, or still active?”
3. “Would you continue gameplay now, or check something else?”
4. “Was the required action clear enough?”

Conclusion:

1. “What information did you notice first?”
2. “Was there too much information, too little, or enough?”
3. “Which part was confusing?”
4. “What would you change to make the HUD clearer?”
5. “Rate clarity from 1 to 5.”

After discussing each question with 3 users, data was collected to analyze. The results were next:

• Testing focus:
  To check whether users understood the injury, its location, required action, and post-treatment state.
• Injury recognition: successful
  Both participants understood that the character had taken damage and identified the problem as located in the right hand / right arm.
• Information hierarchy: successful
  Both participants noticed the body condition display first or treated it as the most important part of the HUD. This shows that the body diagram works as the main diagnostic focus.
• Required action clarity: successful
  Both participants understood that the character needed to heal / apply treatment / bandage the injury.
• Post-treatment feedback: partially successful
  Both participants understood that the treatment improved the condition, but they questioned why the character was still not fully recovered, for example why the condition stayed below 100%.
• Text density: needs refinement
  One participant said the interface would work better with less textual information and more visual body-based feedback.
• Secondary information clarity: needs refinement
  Some secondary indicators were unclear or less important to users. This suggests that pulse, percentage, battery/device status, or other secondary data need clearer hierarchy or labeling.
• Body part highlighting: needs refinement
  Participants suggested making the injured or recovering body part more visually obvious, instead of relying mainly on text.

• Overall clarity: strong
• Participant ratings: 4.5 / 5 and 4.87 / 5.
• Average clarity rating: 4.69 / 5.

The prototype successfully communicated the main injury-treatment flow: users understood what happened, where the damage was, and what action was required. The next iteration should reduce text density, improve body-part highlighting, and clarify partial recovery after treatment.