UX Design

Problem: Quasar League's post-game experience was too abrupt and ignored by many players.

Method: Through competitive research and menu prototyping, I came to the conclusion that improving how data is displayed to the player would be the best approach. Then I designed and implemented a "Graphs tab" along with our scoreboard tab, to engage players better during the post-game.

 

Outcome: Players would spend significantly more time on this screen, comparing their stats and talking about how they performed.

Problem: Learning a new game can be challenging for some players, especially when they do not know what they may need to learn.

 

Method: I first determined what aspects of the game where players struggling learning and a very large factor were their ignorance of positioning and movement. Therefore to enhance the players' ability to improve their gameplay I designed this "heatmap dashboard." This was the final mockup of a long process of changing visual styles, interaction design, and layout until I found a strong balance of player control, simplicity, and clarity.

 

Outcome: This mockup was accompanied by a comprehensive spec sheet so UI Artists, Designers, and Programmers would have a cohesive understanding of what and why certain features should be implemented.

PostGame_Dashboard_V4.PNG

This image is a unity Prototype of a pop-up for Quasar League's single-player menu.

Problem: We needed to give players enough information to make reasonable decisions and prepare for the next match, but also not overwhelm them with information.

Method: I determined what information was most important to the player through interviewing and playtesting. Then I prototyped the pop-up menu with the desired information.

Outcome: I gave players a "Pilot summary" that shows each enemy character's strengths and weaknesses and minimal information on their abilities. 

Problem: For the entire production phase of Quasar League, we were using HUD elements and other "in-world" UI that was either drawing the players' eye away from gameplay or went completely un-noticed by players.

 

Method: My goal was to keep the player's attention near the center of the screen. I considered bringing UI elements to the center of the screen but decided against it because it did not fit the style of the game and would distract the player. I would land on a more elegant solution and prototyped diegetic UI in the environment (the shield health bar to the left) that keeps player attention on the gameplay while simultaneously increasing engagement. 

 

Outcome: Since our feedback for gameplay was one of our most polished areas, ensuring that the player sees that satisfying feedback.   

Problem: During the early playtesting of Quasar League, we had an issue of players only fighting in big open areas and not utilizing the full range of the map or getting side objects like buffs.

 

Method: To mitigate this issue, I looked at similar design solutions from previous projects and how I could tweak those solutions for this game. This resulted in lane "trails" in the environment (right images) that are non-distracting but guide players around the map. 

Outcome: Players were now using these side lanes more often and would fight around side objectives.

Problem: During the early stages of Quasar League, we wanted to understand what player archetypes the game would attract and we wanted to attract.

 

Method: These archetypes were developed using the Quantic Foundry Gamer Motivation Model and having team members and players take a survey that gives us their profile.

 

Outcome: This allowed our character design team to create characters that would appeal to our player base by using this document during pre-production and production.

Problem: For Quasar's character select screen, there was a problem that players barely understood what character they were even choosing.

Method: I asked the players what do they look for when choosing a character and then worked along with the design lead to ensure that players could get a solid understanding of how and why they should play a character just from this scene.

Outcome: This evolved the menu into an informational and engaging screen.

UI_Bayeeb_horizontal.png

Problem: In the pre-production phase of Project Janus, a problem we were having was how to communicate to players our complicated "Time manipulation" mechanic.

Method: First, I designed 3 different types of HUD elements that would help communicate to the player what time they were in, and what time frames they could manipulate. Next, I tested these three designs with new users to come to a conclusion of what design would be the best to implement in the game.

To improve this further I then looked at effects and level design to help players make the connections on their own. This included: color-coded levels that matched the HUD, an effect on the HUD that showed the current frame changing other frames whenever a player change was made, and in-game effects that did the same.

Outcome: Players were able to make connections between their actions and changes in the level quicker. This sped up player learning so that they could start engaging with our more complicated puzzles faster and more confidently.

©2020 by James Dircks. Proudly created with Wix.com