Tweaking a Mobile Gaming Feature for Star Trek Fleet Command

What I would do differently….

A while back, I was transitioning from Sketch to Figma. The last time I used Figma was in 2017 and honestly, I wasn’t completely sold on the tool. Fast forward to now, I find that the application itself has improved quite a bit. And to get myself further acquainted with the application, one of my friends gave me an idea to tweak a game feature as an exercise with Figma.

Needless to say, I accepted the challenge and the first exercise I picked up was a game called Star Trek Fleet Command. In general, the game is based on the Star Trek IP where you control various starships and you fly around space fighting other players. Overall my first impression of the game, the visual graphics looked great.

I was impressed by the artwork of the famous characters and ships. What I wasn’t a fan of was the user experience. I can get into the weeds just nitpicking the entire game, but one of the lacking feature that I came across was the ability to crew your ship with a pre-configured setup so you can fly around space and blow things up faster. The game itself has a lot of officers for you to unlock and depending on how many officers and ships you have; finding, sorting, and loading these officers can be a chore.

Officer selection interface.

To validate this idea of saving a crew setup, I began looking through Reddit where I saw players were asking for this very feature. This made a lot of sense, since it is a time saver to do in seconds versus minutes. Since the game developers did not implement it, how would I do it?

First thing I need to consider is the real estate of the application. From that screenshot, taken on a mobile device, the screen packs a lot of information and details.

1. This is the area where you crew your officers for the selected ship.
2. This is the ship strength details panel where the power of the ship and its abilities will vary by the type and level of the selected officers.
3. Call to Action buttons where the user can sort the officer carousel (4) by various attributes through a dropup option. Once all the officers are selected, the user taps “confirm” to set the officers and leave the screen.
4. Officer Carousel for the user to swipe through. To select, you tap the officers and then go to the crew panel (1) and place them where you want them to be.

Because of the real estate, do I use a modal or have the user to drill down to another screen to create pre-configured crews? I’ve always been a proponent of not using modals or forcing users to leave an “interaction” screen for another “interaction” screen. I opted to keep the user on the same screen to keep the experience seamless.

I noted that the original UI uses a dropdown (or dropup) for selection options. So if I were to follow that pattern, how would that look?

Modifying the interface to use a 2nd dropup.

As I began working this solution, I immediately saw right away that this option was going to be a problem. There were a few unknowns that I wasn’t sure about. First being how many pre-configured crew can a user have? Do we want to set a limit? Or let it be infinite? If it were to be infinite, then using a dropup would not be a viable solution. Furthermore, I was running into the issue of “how do I save a loadout?”. And then my real estate issue became a nightmare.

Taking a step back, I decided to really optimize the layout and move some elements around. In this revised solution, I still managed to keep the real estate within the mobile device screen while adding more information to the user. The big change was shortening the officer carousel and moving the CTA towards the bottom. Then making the center piece of the interface for the user to select and save crew loadouts.

1. In the crew selection panel, I’ve added a label to denote which pre-configured team was actively selected.
2. The SAVE button would highlight if there was a crew change.
3. After looking through some of the comments on the Reddit post, having four pre-configured teams seems to be the reasonable choice people were asking.
4. This one was interesting since I shorten the CTA and stacked them on top of each other. When I checked this new size through my mobile device, the button size was tolerable enough to avoid fat fingering.

Toggling between the teams was as easy as just tapping on/off the button. If none of the buttons were selected, the user would view this as a general loadout with no option to save.

If the user wanted to toggle Team A…

Tapping Team A button will load the configured team. But the user can still modify the loadout with any crew they want. Hitting the Save button will save the new update. Or if they just hit the Confirm button, the system will use whatever configuration the user setup without saving.

This can be done for any team.

I’m sure there are other interactions that I didn’t address. But I only wanted to keep this at a high level to illustrate of what I would do differently. Of course, at the end of the day, the game developers will have more information and metrics to make a better decision on how they might implement this feature in the future. Or not.

Anyway, it was a good exercise to for me to do in Figma. Creating the wireframes and understanding auto-layout was definitely fun learning.

Maybe in the future I might look at another application and see what I would do differently.