Destiny Loadout UI

Figma

Academic

Solo

2 Weeks

Core Tasks:

Redesign a UI to solve a specific problem
Conduct research to inform design decisions
Create a well defined Problem Statement
Create a solution spec and proposal presentation to pitch the new design
Follow up with users to evaluate changes

Shipped: 10/29/24

Written: 11/15/24

Overview

In this project, I worked to increase the recognizability of player's loadouts within Destiny 2. I conducted and coded research, and developed a set of problem statements and solutions. I also created and delivered a presentation, and wrote up a spec to propose my solution, both complete with mockups. This project gave me solid practice running through a more formalized UX design process, and taught me the value of clear, well defined goals.

Pain Points

Starting out with the project, I looked to find the main pain points I wanted to center my research around. I had picked what I wanted to do this project on long before it was assigned, focusing on Destiny 2's Loadout system. When the project actually rolled around, I identified the more specific pain points I wanted to start with using a mix of sentiment I've heard from other players and personal experience. I took these into the research stage to give me an idea of what to look for.

Research

Going into research, I wanted to try and evaluate player perspectives towards the pain points I had identified, while still leaving as much room as possible for emergent data. To do this, I chose to conduct six unstructured interviews to gather a large amount of unfiltered player feedback.

In each test, I presented the player with Destiny's Loadout menu, and asked them to tell me about their experience with it. I took notes while running more exhaustive sessions, trying to get into the 'why's of each problem that came up, as well as gathering data on where the feature missed players' expectations. After six interviews, I had a large list of comments to sort through.

In post, I coded my notes to look for trends and group similar topics. I decided to stick purely to emergent codes to go along with the exploratory nature of the rest of the research. I left this stage of the project with a strong idea of players' needs and issues surrounding the loadout screen.

Identifying The Problem

From the research, I created a set of three problem statements to try and explore different issues. My coded notes made it relatively easy to pinpoint recurring points, the largest of which I turned into full problem statements. After writing each of these out, I analyzed the severity of each issue, and a clear final option emerged.

When reassessing the research, two of the six players stated that they completely disengaged with the loadouts system for the same reason. They both had trouble recognizing their loadouts after they were created. Looking back over my data, there were a ton of points about issues surrounding build readability, and I decided that would be the highest priority issue to tackle. This was especially relevant at the time in light of newly announced changes to Destiny 2's live service model, issuing content in six week intervals instead of on a week-by-week basis.

Solutions

When looking for solutions, I again went back to the research. Now that I knew what specific problem I was addressing, I could evaluate player's grievances and suggestions with a more refined lens. While there were a large number of smaller tweaks that could have been made, I ultimately chose to redesign the current on-hover popup since it was both the most verbose solution to this problem, and would let me address the most extraneous feedback gathered while researching. I got a ton of data while testing about what information was most and least relevant to a build's recognizability, and felt the best equipped to tackle this problem in this way. I decided to reformat this menu, pulling more build relevant elements up in visual hierarchy, and replacing less relevant elements with information users said was missing.

Solution Mockup

After deciding on a solution, I took to Figma to create a mockup. Immediately, I started with adding the loadout's equipped Aspects to the subclass bar at the top. Almost every user said that this was either missing from the menu, or one of the largest driving factors in a build. I then reordered the weapon perks, moving the trait perks to the front, and boxing them to pull them up in visual hierarchy. Many players heavily questioned the inclusion of the other elements in the weapon section, so I wanted to pull out the information users said was most relevant. I also removed the weapon's Intrinsic, something testers called redundant, and replaced it with it's Origin Trait.

For armor, I removed the armor's Intrinsic, and replaced it with the armor set bonuses that were announced while I was developing this project. I also removed each piece's armor stat mods to make room for the armor set's stat totals, which was the second most frequently requested piece of build information. For a visual step-by-step, including variations of the design, see slides 10-18 to the right.

See slides 10-18 for step-by-step changes and variants

Pivot

For the second part of this assignment, we were required to make a pivot on our design. I chose to focus on a hypothetical new buildcrafting system proposed by the sandbox team. This would aim to test my original design's scalability, and throw the design as a whole for a small loop, while keeping the scope of the project relatively small.

Pivot Mockup

When starting to update the solution with the pivot, I knew I wanted to keep the core of the design the same. Since players responded pretty well to the first iteration, I tried to keep to the same format, only restructuring the weapons section. This did mean I would need to make some decisions about what information to cut here. Yet again, my research presented a pretty clear solution.

Since weapon barrels and magazines were on a few tester's lists of items that were questionable to include in the menu, these were pretty clear answers for what to cut. I restructured the menu to remove those icons, along with the old weapon mod slot, and added the two new slots. I then put these higher in visual hierarchy, and pulled down the weapon perks. I presumed that these weapon mods would be more build-relevant than subclass perks, since these have explicit subclass synergy, which was commonly identified as one of the most important build elements, though in a real environment this would be something I'd have to ask the team.

Lessons

By far the biggest lesson from this project was the usefulness of well defined problem statements. This project really emphasized how much easier it is to make decisions when you have super clear goals. Following a more formalized UX process gave this project a lot of clarity that really helped me come to a solid product with a lot less strain. This is something I've since applied to many of my other projects, especially my work leading the large team behind Tea Time's Over. Being able to take a step back as a team in a meeting to clearly define the problem we're trying to solve has saved us a tremendous amount of time and effort.

This project also showed me how much easier pivots can be than I thought. While the pivot in this project wasn't the largest, the amount of research and design work I had already done that I could pull from made creating the new solution incredibly simple and fast.

Reflection

Overall, I'm quite happy with how this project turned out, especially given the short turn around. Though it wasn't perfect, the redesign tested quite well in quick follow up interviews with the original participants, and I feel pretty good about how this would have turned out given a few more iterations.

Looking back on the project, I think one of my biggest limitations was my use of convenience sampling in my research. Though I tried to pull a large variety of testers, there is still an innate bias given the combination of this sampling method, and a lower sample size. This sampling method was chosen due to time constraints on the project, and were I to go back and change anything about my process, this is definitely near the top of the list.

Given more time, I also would have liked to explore more solution options. Though I was able to explore some variations on my design for this specific solution, I likely would have found a better result spending more time evaluating and comparing separate solutions. Ideas are relatively cheap, and it would have been nice to create more low fidelity mockups or sketches of different solutions and go through a more in depth brainstorming and evaluation process.