My latest project as Lead UX Designer
This presentation will cover:
• How we worked
A quick description of my role as the Lead UX Designer at Yager
• Some work samples
An introduction to some of the many deliverables I provided
• A short case study
A demonstration of how we redesigned the top navigation bar
• What I learnt
A roundup of what I learned working on a video game
The Context
About the product
Dreadnought is a space combat simulator, in which players embody commanders of capital battleships. There are five unique ship classes from three distinct manufacturers, each with their unique manoeuvrability and fire power, drawbacks or advantages. As a result, gameplay involves careful positioning and ship management. 
Besides the core gameplay, Dreadnought is several softwares in one. It features a combat HUD, vehicle cosmetics and equipment customisation, an in-game shop, an in-game currency and resources management, a dashboard featuring elements of quantified self through player statistics, in-game friends connection, group forming (called "squads") and a chat system.
The game has been in development three long years before I was hired. Built with the Unreal Engine, supported by a brilliant art direction, it landed among the most gorgeous games in the industry. It amassed a solid fan base right from announcement despite many competitors.
Unfortunately very little care was given to Dreadnought's UI/UX. Basically, the game designers acted as the interaction design team. While skilled at building game mechanics, their limited knowledge in UX translated in many frictions.
How we worked
Direct collaborators
I reported directly to the game director and the head of design, collaborating closely with the lead game designer and the lead UI engineer.
As the lead UX designer for both the PC and the Playstation versions - spanning across the studios of Yager, SixFoot (USA) and Iron Galaxy (USA) - my role involved:
• Support and sign-off the interaction design from the game design and UI/UX teams
• Provide UX expertise and design propositions for new features
• Initiate user research and business intelligence enquiries
• Review and support UI artists on usability and art direction
• Support UI engineers on UI implementation involving IxD and IA specifications
user-centered approach
We designed with players in mind. On top of quantitative business intelligence data and feedback from our countless social media platforms, Dreadnought was playtested on a daily basis for qualitative insights. We also conducted frequent one-to-one user interviews (e.g. when testing a specific feature).

The following documents are a few of the many deliverables I created to share concepts and systems ideas. They are the output of an iterative observation/design/test/execution process similar to the one introduced through the case study further down this page. 
interface hierarchy
Video games like Dreadnought are software. Unlike many apps or websites, which are essentially non-linear interactive slideshows, the complexity here requires several content windows to simultaneously live on screen. Without a clear information architecture strategy, this potentially translates into chaos. I suggested to use a layer system similar to the one in Photoshop. We defined a hierarchy of UI visibility sorted by monetisation and gameplay relevance. 

For instance, the only UI that could overlap the draggable chat window (Lv3) is the top navigation bar (Lv2) and the settings overlay (Lv1). This allows players to continue chatting while browsing the market (Lv6) or customising his ship (Lv7).

The HUD is the pivotal feature of a combat simulator. However, Dreadnought's closed-beta version missed to clearly translate some information. For instance, to not clutter the screen, hull and energy states are not displayed on the target trackers of distant ships. This came with the downside that players in support ships had to travel within range and roll their crosshair on every single friendly to find out who required help first. Below is a succinct presentation of the new version following my lead:
• Ship indicators
The indicators of Enemy and friendly ships were differentiated by their colours only. The new version has a distinctive visual design so players recognise easily a ship indicator among other icons on screen. At the same time, they get a slight visual difference between each other. Thus, players, and in particular colour blind ones, can rely on shape alone to know which side a ship is.
• Crosshair
Just like the ship indicators, the crosshair relied on colour changes to show that targeted ships are within one's weapon low (yellow), medium (orange) or optimal (red) effectiveness range. This was not only to subtle for colourblind players, it was also inconsistent with the rest of the UI where red is associated with errors and danger. The new crosshair varies in degree of detail to translate the evolution of a weapon's effectiveness.
• Weapon effectiveness on ship indicators
This second indicator appears on top of an enemy ship as soon as it enters the player’s firing range. It mirrors the crosshair visual evolution. Thus players know at one glance which ships are within which weapon effectiveness before even moving their crosshair.

The effectiveness indicators are essentially icon versions of the crosshair states

• Support ships in the HUD
Friendly support ships are indicated with a cross icon, whereas when flying a support ship, the HUD indicates all damaged friendlies in need of help.
Other details of the HUD redesign
• Attention distribution balance
Our test using EyeQuant showed that the new HUD architecture (including font weight, iconography, etc) improved the distribution of player attention. Very importantly, it increased the visibility of both the ability icons and the surrounding ships indicators, while maintaining the absolute requirement of the ship's eminence.

Hotkeys are very important in the culture of video games interaction. When in the hangar (the first screen of the user journey), the Escape key acts as the shortcut for accessing the settings menu. Beyond that screen, depending on context, it acts as a shortcut for “Back”, “Close” or “Cancel”. The challenge was to define, which action to perform for an intuitive experience, particularly when all three buttons are featured on screen. I defined and mapped the Escape key behaviour by screens and by steps in the user flow.

Players' expectations
I analysed Dreadnought’s market position based on the games our target audience personae play. The goal was to understand, which level of UI complexity and how much of in-game information they were used to and expecting. 

As a capital spaceship combat simulator, Dreadnought sits between Star Citizen, Eve Online and World Of Warships. All of these games present highly detailed in-game data, e.g. weapon accuracy range and explosion blast radius, player performances, etc.

Previous version
• The menu bar
One of the first candidates for a redesign was the main navigation bar. It is the backbone of Dreadnought's pre-battle experience. The previous version missed to provide access points to crucial monetisation and social interaction features (Squads, Friends and Chat). Overall, the entire structure lacked a clear information hierarchy.

The Play button turns to a matchmaking countdown notifier

• The Battle editor
Furthermore, the Play button was in fact the access point to the game mode and fleet selection pop-up. Thus, after clicking the first Play button, players still had to click a second Play button to actually join a battle. Also, when in the fleet selection step, players had no other choice than cancelling and restarting the journey if they changed their mind and wanted another game mode.

THE Redesign
• Early ideation
Following the F reading pattern best practice, I knew I would have to keep the left side of the bar for the core gameplay access points (e.g. Tech Tree, Market, etc). However, I wasn't sure about the best location for the Elite Status button. As a core monetisation feature, one click on it led to the Elite scheme purchase screen. It had to be easily spotted and accessed. I tested four versions (see two of the paper prototypes below).
I also explored moving the Play button on top of the fleets tab. The goal was to reduce the top menu information noise and its function correlated well with the fleets.
Additionally, I envisioned to make the resource scores clickable and turn them into access points. A click on the GP score lump would take directly to the GP store where players can purchase GP packs with real money. In the same manner, a click on the Free XP lump takes to the XP-to-credits convertor screen and a click on the Credit score takes to the credit packs purchase store. Converting XP and purchasing credit both requires GPs.
Last but not least, I brought the social features (Squads, Friends and Chat) right below the bar. We wanted to encourage social interaction but at this point analytics showed only a few players used them. They were lost in the central-right side of the screen, in the so called Z pattern dead zone.

These two versions got the most positive feedbacks

In parallel to moving the Play button on top of the fleet tabs, I explored ways to present the entire choice of modes and fleets in one single window. The idea was to save players unnecessary clicks and of course to allow them to freely change their selection, on the go, in no particular order. The once Play button would become Battle Plan. It would expand on click to reveal the game modes and PVE events. The whole would be punctuated by a single Play button that takes to battle for good. 
• Initial wireframing and testing
After the first scamps seemed to work, it was time to wireframe and trial further the new navigation and access to battle system. We presented an interactive mockup of the hangar to testers and asked them to click on the relevant button upon questions like: “where would you click if you wanted to edit your avatar?” 
We found out that most of the top bar was a success but we didn’t really solve the Battle Editor journey issue. The Play button was still buried behind a second click, and wasn’t convenient in case a player would only like to replay the same game mode with the same fleet. Not to mention, “Battle Plan” as a label wasn’t obvious enough to let testers guess that this was the access point towards battles . 
When asked to join a match, four testers clicked on the ship. One even thought clicking the hangar entrance took “outside to the battlefield"...
• Post-feedback wireframing
After a bit more feedback rounds and iterations, I finally came to the version below: I streamlined the labels of the resources buttons (e.g. Get Credits) to a "Plus" icon next to the score. This maintained the visibility of the stores access points and better balanced this group of buttons. Most importantly, I brought the Play button back in, as feedback expressed moving it didn’t work well. 
I also came back to a two screen Battle Editor system for scalability. Although the PVE events were delayed for later releases, more game modes were in the making and I didn't want to end with an overwhelming wall of fleets and modes. However, the new Battle Editor I envisioned was very positively perceived. It was regarded as a considerable UX improvement as it allows players to switch at will between the Game Mode board and the Fleet board. Plus a simple click on Play would take straight to battle if players were happy to take the same fleet to the same game mode forever.
• Validation
Some testers felt that the access point to the captain profile screen was not clear; some felt that "Dashboard" should come before "Hangar" in the menu. The need for a single Battle Editor board was expressed, hence it received the lowest score. However, because of scalability this wasn't an option. But overall, since this last version received quite positive feedback it was signed off. 

The need for a single Battle Editor board was expressed hence it received the lowest score (but it wasn't an option because of scalability)

tHE NEW Top navigation bar
At this stage I supported the UI art with my usability and accessibility expertise. This meant improving the affordance of the access points and introducing visual articulation following the Gestalt principles. Most notably, I used my Art Director background to capture the essence of the game's lore and lead the art style towards a more appealing and immersive appearance. Here is the new UI concept for the top navigation bar:

This UI style mirrors the flamboyance of figureheads such as the Trident and the Morningstar 


While seeking insights on our users to strengthen engagement and retention, I came across two key researches on the psychology of gamers:
Gamer Motivation 
Gamers are not a monolithic group, their gaming preferences vary in important ways. Using survey data from over 200,000 gamers between the ages of 13 and 64 worldwide, researchers Nick Yee and Nicolas Ducheneaut identified six clusters of motivations:
• Action: excitement and destruction  
• Social: collaboration and competition
• Mastery: strategy and challenge
• Achievement: power and completion
• Creativity: design and discovery
• Immersion: story and fantasy
This model helps define which features to improve or advertise in order to attract and retain the relevant audience.

This model for player motivation and engagement applies Self Determination Theory (SDT) to video games. Based on decades of behavioural science research, by gaming psychology experts Scott Rigby and Richard Ryan, it theorises that sustained player engagement is fostered by a game's ability to deliver on three central axes:
• Competence: feeling of growing, learning and progressing towards mastery 
• Autonomy: feeling empowered and in control of drawing one's own path
• Relatedness: the sense of purpose and social relevance, "I matter to you, you matter to me”
Although the PENS theory is mainly of gamification and game design matter, I believe it is a valuable asset to UX designers on subjects such as user-onboarding and of course retention.
Thanks for reading!
Back to Top