top of page

Case Study

The Task:

Designing the Inventory screen for the mobile version of an existing FPS on PC

Step 1

Context Gathering

Starting with Goals

I defined the experiential goals informed by our UX Pillars to help guide and prioritize my design decisions.

These help ensure I’m delivering the desired emotional experience, NOT just functional flows.

Knowing what it is:

“I feel a sense of accomplishment or prestige when I look at my equipped set, and want to show it off to other players”

“I feel like I can easily understand my collection and customize my appearance”

“It's easy to know if something I like (but don't own) is available and where / how to get it”

Knowing what it's not:

“I have a clear sense of how much I've collected and that feels like an accomplishment, as well as a goal for me”

An early goal I debunked. Why?

  • The content in the game is all limited time. Focusing on “collect-it-all” didn’t align with players’ motivations.

  • Self expression and flexing based on what you have equipped are the motivators, not “amount collected”.

  • Risks discouraging players - they cannot actually complete the collection.

Challenges and Constraints

A few things I knew I needed to keep in mind while designing

Overload

This area of the game had to house a LOT of systems, content, and functionality.

How was I going to make everything fit together?

Extensibility

More content types and systems would be coming in the future.

How do I make my designs forward thinking?

Competing Goals

Big visuals to make cosmetics more rewarding and space for key functionality competed for limited screen real estate.

How do I find the right balance?

Step 2

Navigation

Blocking Out Navigation

I needed to figure out the flow, information architecture, and navigation patterns to have a solid model to fit my designs within.

Parity

First, I tried something close to PC. Parity to optimize dev costs was a key stakeholder goal.

PC

PC had the luxury of fitting all the content and categories in one view.

First Mobile 1-to-1 Attempt
parity_mobile.png

But, I quickly realized that was not a viable option on such a small screen.

Persistent Navigation Options

With parity not viable, I explored new models to access the content.

Tabs Approach
BUT...
Pros:

Gave us a focused view and more room for content

Made navigation really quick and easy

Cons:

Not very extensible for more content categories

Having navigation always accessible limited screen real estate too much at deeper layers

Dive In Dive Out

I realized quicker “dive in dive out” approach was going to be the best option.

My first approach
dive in dive out.png
  • Prioritized instant access to weapons, the highest traffic items

  • Utilized native scrolling pattern

  • Improved extensibility concerns and made room for content

  • ️Pushed lower priority items off the top level screen completely

  • Future content would get further and further away from top level access

I was close but still not quite there...

Final Navigation Solution

Ultimately collapsing all the categories at the top level was the best balance between our goals and constraints.

Click to view prototype

  • Navigation wasn’t AS quick

  • Treated all content areas as equal, which was more in line with stakeholders goals

  • Was more extensible for future additions

  • Resulting usability and experience at lower layers was MUCH better

Now it was time to get into the actual design.

Step 3

Weapon Screen

Considerations

The weapon screen was by far the most important and most challenging part of the design.

The game monetized primarily based on weapon skins, and accessing their collection was a common use case for players.

Overload

A LOT of functionality competing with the need to maximize a compelling visual of the cosmetic itself.

How am I going to get all this on the screen?

Blocking Out Weapon Screen Navigation

Top Level

First, I needed to figure out the high level weapon view.

PC could fit every weapon on the single screen

Top level mobile.png

I tried that on mobile and at first it seemed like it might work

But I realized that in order to judge these designs accurately I needed high fidelity weapon skins in my wireframes.

Without real art, I couldn’t tell if the detail of the skins came through at this size

The details of the skins got totally lost and they weren't very rewarding to look at, which went against goal

“I feel a sense of accomplishment or prestige when I look at my equipped set, and want to show it off to other players”

I needed to figure out the right size for skins that correctly balanced our goals.

Option 1
option1.png

Large detailed weapon visuals = super compelling

+

Option 2
BUT...
mobile with art.png

Accessing and editing weapons super quick and easy

+

Loses the sense of a “collection” with so little visible

-

Accessing, editing, etc... is more cumbersome

-

Weapon size isn’t a very rewarding view

-

“I feel like I can easily understand my collection and customize my appearance”

Middle Ground

Both ends of the spectrum were too far, but the middle ground satisfied all the goals best.

middleground.png
  • Weapons are large enough to be compelling and rewarding on a small screen

  • Player sees enough that they still get that sense of “my COLLECTION”

  • Accessing and editing isn’t as fast as possible, but is still really quick and easy.

Blocking Out Weapon Screen View

Roughly mapping out all the functionality and information I’d need to include.

Parity

Once again, I started with a version similar to PC.

Parity with PC
weapon pc parity.png
  • Close to PC, minimizing developer costs

  • Visually overwhelming, lack of focus and hierarchy, usability issues, non mobile friendly patterns

  • Not viable to support customization / second levels of functionality, extensibility issues.

  • Minimized weapon preview, decreasing visual impact and sense of reward in your cool stuff

Priorities

I needed to make some choices about what to prioritize on the screen.
Everything couldn’t be number a number 1.

Mobile Layout

Prioritizing use cases:

  1. Choosing between the smaller subset of skins I own

  2. Upgrading and editing a skin

  3. Needing to browse lots of unowned skins quickly

weapons_mobile layout.png
  • Small vertical list saves a lot of room

  • Prioritizes preview to focus on weapon detail + visual reward

  • Native scroll motion makes selecting easy w/out overwhelming view with more options than needed at once

  • All controls in easy to reach areas.

Decluttering

The design was better, but it was still pretty cluttered. All of the functionality was still at the top level.

Mobile Layout
weapons_mobile layout.png
  • Doesn’t accurately prioritize functionality to match user goals

  • I needed to figure out the Flow, IA, and Navigation pattern to have a solid model to fit my designs within

  • Little room to make it clear how mechanics like colorways work

  • No room to add future content

Organizing

I used drawers and modals to organize information

Mobile Layout
weapons_final.png

Allows the weapon skin to take center stage

Keeps everything within easy reach

Highly contextual - prioritizing only what the user NEEDS, and letting them opt in to less core functionality

Open Drawer
weapons_drawer.png

Potentially confusing mechanics like colorways are easier to digest when they have their own section

Space for user feedback to improve understanding of when and how to acquire colorways

After that, I worked to design the remaining areas of the feature.

Final Prototype

In the end, I had a design that effectively delivered on our goals

Weapon 1.png

Click to view prototype

I was able to champion user goals and needs and create a design that served them and stakeholders

I worked from beginning to end on a key feature and delivered a thorough prototype

But no design is complete until it’s in game

Handing off the Design

The last step in my process is to create a document that helps the hand off go smoothly.

Great documentation helps everyone save time later in the project, including me.

My document for this project contained information that helped engineers implement the feature correctly the first time.

Every detail and edge case of the feature gets covered in order to minimize gaps in knowledge or any area for confusion.

I iterated on the document with engineers and got feedback on how to explain my designs clearly.

 

bottom of page