The storage menu holds hundreds of cool items, giving lots of freedom for players to save interesting weapons...though many wished there were more ways to sort and choose specific ones.

So: Focusing on structure and functionality, what can I do to help players more easily find specific items, and be the best Vault Hunter? 

After a few play-throughs, I hopped onto Reddit and Gearbox's forums, then fell into a rabbit hole that brought me to players talking about the storage menu. For example: 

In going back and examining the process of searching for a unique weapon, I noted: 

I had a bunch of grand plans for the research phase, like in-person studies and testing for console players.

But what really happened was...maybe 98% of my plans didn't happen (health and technical reasons), which also meant the recruitment didn't really work out for finding Borderlands 3 console players, or doing any in-person things like play-testing.

Great.

So the alternatives were: 

With the watered-down quality of research findings listed in the chart above, I made more assumptions than I felt comfortable with at first, so it was key to make sure these were carefully observed during the testing phases:

On starting solutions, I began to ask more questions than having solid answers, centering around control mapping, alphanumerical ordering, screen space, sizing, dynamic information displays...

...these questions and some confusion are clearly seen in these sketches:

Thinking on those questions, before making wireframes and prototypes, I set up a task scenario where a player is searching for a certain gun that has specific qualities.

So let's say the player is capped at the current highest level and has a multitude of collected weapons. They are going to fast-travel to an area that they know has fire-prone enemies, and the player knows just the gun they need for that area...

Similar to the early sketches, Version 1 keeps the sort and filter more minimal, first by categorizing main item types into tabs, then  letting the player view items by certain traits (manufacturer, elemental, etc.): 

This added another "layer" of sorting options with an additional default bar beneath the tabs, automatically grouping the category by type.

With a sub-category, this narrows the search process by another step: 

Overall, Version 1 had the best performance for its clearer layout and less confusing visual feedback compared to Version 2.

Every participant didn't find the Search Bar useful, even for PC players.
‍
For Borderlands 3 players, the Level Display was an unwelcome change, since at maxed-out levels, players focused on item score first.

I was hesitant to change controls, because I had initially set a goal of staying as close to the current design as possible.
‍
But with the solutions I was trying, the right stick (RS) was the only "free" option, limiting players' freer movement to sort and group, which was the primary issue in Version 2.

So, I chose to modify controls, deciding that it was necessary for a smoother flow.

Because I was also worried about how much "stuff" was being shown, I tried a new method of minimizing the options into horizontal accordion menus. Each menu used left and right triggers for toggling through each option, with the Y button handling enter and exit states for the sorting interactions.

This version returned new problems, with confusion over sort vs. filter, and navigating the fold-out menus, especially with the Y button option to exit the menus.

Though participants wanted to see all sorts and filters at once, I was still worried about the spacing and text amount.

Again I compromised, reverting the Y button to its original function - cycling through the sorting options.

Version 4 was similar to Version 2, but with clearer distinction between the sort by type default and additional sort options, paired with a control prompt to avoid conflicting feedback.

Since the control remapping began to spread thin, I made the decision to specify which buttons move the other elements on the screen.

Though I was starting to feel I had tried enough, I made one more push by examining the other game menus.

Because the main issue was balancing amount of information, I wondered if borrowing from the Skill Tree menu could help:

On completing the wireframes and eyeballing them, I was instantly worried about...well, the whole thing.

Though this format freed up a way for players to sort their items by rarity, score, and level in a separate space (inside the item grid), the main concerns were spacing, sizing, and directing players' eyes, where many things crowded the screen.

And the award goes to...

Version 5 for the worst performance:

Showing everything is not necessarily a good thing, even when people say that's what they want.

As seen below, this only created more confusion over a cluttered screen, multiple elements, and a confusing layout:

Let's say my deadline is up (I was actually three weeks past the "Let's make this a 4-week-long project!") and I need to wrap up...

I reread the test feedback and decided that Version 1 and 4 did the best, and with them in mind I put together a new (but untested) Version 6:

I hadn't been satisfied with the research phase, because of less actionable data and therefore, less fully informed decisions.
‍
At one point, I scrapped flows entirely, because too much of it felt like conjecture and imagination.

I wonder if things could have gone more smoothly (and on time), if there were more insights about players' search, categorizing, navigation, and in-game behavior - why are they going to the storage menu in the first place?