Dreadnought is a AAA spaceship combat simulator. The players embody captains of capital spaceships. There are several ship classes. Each with their manoeuvrability and fire power drawbacks or advantages. As a result, gameplay involves careful positioning and ship management.
The Context
PRODUCT QUALITY 
Dreadnought have 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 industrie. It is also an incredible game concept and amassed a solid fan base right from announcement.
UX CHALLENGES
Unfortunately very little care was given to Dreadnought's UI/UX. Basicaly, the game designers acted as the IxD team. While skilled at building game mechanics, their limited knowledge in UX translated in many frictions: there were unidirectional selection paths with no way back unless canceling and starting over again, some critical actions had no confirmation step, and navigation buttons could change location from screen to screen, etc…

what i delivered
MY ROLE
As the Lead UX Designer across three studios and two platforms my role involved:
• Review and validate IxD made by Yager’s Game Designers
• Review and validate designs from Iron Galaxy’s UI/UX team (Playstation version)
• Review and validate proposals from Six Foot's UX team (Publisher’s studio) 
• Initiate User Research tasks and Business Intelligence enquiries.
• Review and support Yager’s UI artists on usability and art direction
• Support UI Engineers on UI implementation involving IxD and IA.
Direct collaborators
I was reporting directly to the Game Director and the Head of Design, collaborating closely with the Lead Game Designer and the Lead UI Engineer.
Work sample
The top navigation bar redesign

Read below and discover how I led the top navigation bar UX and UI design to this

Before
• The menu bar
One of the first candidate for a redesign was the old bar bar. It's the back bone 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 usability lacked a clear hierarchy as most buttons were rectangles in various shades of greyish Blue and Orange.
• The Battle editor
Furthermore, unlike what would be expected 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 another "Play" button to actually get in battle. To not help, when at the fleet selection step, players had no other choice then canceling and restarting the process if they changed their mind for another game mode.

THE Redesign
• Early ideation
Following the F reading pattern best practices, I knew I had to keep the left side of the bar for the core gameplay access points (e.g. Tech Tree, Market, etc). But I wasn't sure where was the best location for the Elite Status button. It was a core monetisation feature, a click on it took to the scheme purchase screen. It had to be easily spottable and accessed. I tested two versions (sketch versions below).
I removed the Play button to put it on top of the fleets tab. The goal was to reduce the top menu button noise and it's function correlated well with the fleets.
Other then that, 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 score lump takes to the XP-to-credits convertor screen and a click on the Credit score lump takes to the credit packs purchase store. Converting XP and purchasing credit packs required GPs.
Last but not least, I brought the social features (Squads, Friends and Chat) to this bar as well. We wanted to encourage players social interaction. At this point analytics showed few players used them as they were lost in the central right-side of the screen, in the so called Z pattern dead zone.

Paper prototype tests showed these two versions were the most effective

In parallel, I explored ways to present the whole choice of modes and fleets in one single window. The idea was to save players unnecessary clicks and of course to allow them to 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 the Play button that will then actually take to battle. 
• Post-feedback wireframing
After a few feedbacks and iterations, I finally came to the version below: I added a "Plus" icon next to the resource score to strengthen the stores access points visibility. I brought the Play button back in since feedbacks expressed moving it didn’t work well. I came back to a two screen Battle Editor system for scalability. More game modes were in the making and I didn't want to end with an overwhelming wall of fleet and modes. However, the new Battle Editor considerably improved the UX by allowing players to switch at will between Game Modes board and Fleets board.

Visual Execution
I supported UI artists with my usability and accessibility expertise. This meant improving button affordance or introducing visual articulation following the Gestalt principles. Most notably, I used my Art Director background to capture the essence of the game's world and lead the UI Art towards a more appealing and immersive style.

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


Work sample • 02
The combat HUD rework
The combat HUD also suffered from the lack of usability and interaction expertise of the previous three years. 

• Confusing information architecture
Many players didn't understand the icons popping on top of enemy ships were in fact their own ship's activated abilities. The legitimate confusion came from the fact most informations in that lump belonged to the other ship.

Blue and Green were used in both players HUD and enemy ships tracker

• Confusing colour code
Friendlies were in Blue. Enemies and negative informations in Red. Positive informations and activated modules in Green. Each ship manufacturers has their distinctive exhaust colour as well. But these colours were pretty much the same tone of... Blue, Red and Green. The usual pattern of "Blue/Green friends/allies versus Red enemies was broken.

Left, a friendly with Red exhaust. Right, an enemy with Blue exhaust

• Poor contrast 
The Red tone in use for enemy indicators doesn't contrast enough in some environments. The crosshair disappears in the VFX and bright backgrounds.  

Landscape with lava. The Red used with the intention to alert and indicate enemy ships is instead camouflaging them

Same landscape as above with highlighted enemy ships

• Low accessibility
The whole HUD accessibility for colour blind players is low. Negative, positive, enemies and friendlies all look the same.

Deuteranopia and Protanopia colour blindness simulations show how the tones of Red, Blue and Green in use are hardly distinctive

proposed solutions
I proposed to use the indicators shape as visual distinction instead of solely colour. In essence, the pointers and icons shape would tell by their geometric aspect alone who is a friend or foo. What is negative or positive, activated or disabled.
• HUD radial pointers

WHAT I LEARNT

While seeking solutions to improve paying users retention, I learnt about two key researches on the psychology of gaming and VR worlds:
Gamer Motivation
This is a research on what motivates people to play games. It demonstrates how these motivations are grouped in three high-level clusters, how they vary by gender and age, and how they correlate with personality traits (OCEAN). It is based on findings from a survey conducted on gamers worldwide. 
This is obviously valuable knowledge for Game Designers but I think it is mostly of interest for UX and Product Designers.
Here is talk given by Nick Yee (co-researcher on the topic) at GamesUR Conference 2017:
Player Experience of need Satisfaction (P.E.N.S.) 
This model applies Self Determination Theory to video games. It demonstrates how games are satisfying basic human psychological needs that are:
Competence: the sense of progress towards mastery, the feel of abilities to solve problems, etc 
Autonomy: the feel of control, that one drives his own path or writes his own history, etc
• Relatedness: the sense of purpose and social interactions, the feeling that one matters to his peer, etc
This other model is mainly of Game Design matter but I believe it is relevant for IxD on subjects such as user onboarding, cognitive load management and of course gamification. You can as well watch this talk by Scott Rigby (the creator of the model) at Games For Change 2012:
Thanks for reading!
Back to Top