Abstract: Advocated for and owned an upgrade to an existing reward delivery system that had overburdened outdated tech, and was delivering a frustrating player experience.

As Lead UX designer, I instigated UX involvement in what was originally a tech-only effort. I used data on player engagement, mapped player behaviors, proposed and evaluated many solutions, guided the dev team, and formed a communication & release plan.

Impact: This was received with overwhelmingly positive player sentiment as part of a series of updates that lead to increases across all core KPI's. Demonstrated to the team how user-centered design can be impactfully incorporated into our strategies.

Marvel Strike Force: Updated Gacha Experience

Marvel Strike Force (MSF) is a live-operated hero collector game for mobile devices. Like most games in this category, it uses a gacha system, where players earn orbs from gameplay and purchases, and then redeem those orbs for rewards generated randomly from a pool. This system is the heart of reward delivery, and is central to all meta loops of the game, as well as monetization strategies such as character releases.

As we started using this system more extensively, we added an "open all" functionality that would open all the orbs a player owns of that particular type all at once. This feature was greatly appreciated by the player base, but it still had quite a few problems:

The experience was still quite slow when dealing with cases of hundreds or even thousands of orbs.
The flow was not flexible enough to deal with different use cases - there was only one path through the system.
The system was not very responsive.
The backend was susceptible to strain if players were opening too many orbs at once.
The UI was unattractive and not matched to the visual style and quality of the game.
We received frequent feedback that opening orbs was significant low quality time in the game.

And then, horror of horrors, one day the system broke!
Over time, due to inflation of the economy, and increased reliance on orbs for live operated events, the strain on the system steadily increased. Finally, one particular event that rewarded an unprecedented number of orbs to all players caused enough strain to overload the servers. The engineers told us we had to turn the system off while we came up with a fix.

So off it was turned across the whole game, and players were upset.

Though a small part of the overall game, the removal of this system had a large impact on sentiment of the player base, as an aspect of the game that was already considered a chore became almost unusable. Leadership hypothesized that the loss of this feature was contributing to declines in active users and determined this to be a top priority issue to resolve.

However, the solutions being discussed by leadership, and across the team, were all technology-only fixes; no one was considering the player experience point of view. I saw this as an opportunity for UX to make an impact and immediately rolled up my sleeves and got to work.

I first collected data about the extent of the problem. We were pushing so many orbs at players, that a tech-only fix would still leave a significant burden on players for opening the huge number of orbs they received. This burden increased with higher level player segments, and peak events could more than double the burden at any time.

I also studied the different player use cases, each of which implied its own ideal flow.

I then worked toward a set of potential solutions that would solve the problem at different levels, with different strengths, and different trade-offs:

• Auto-Open

I had actually thought about this problem before, and had come up with the dream of a time when players wouldn't have to spend time opening the majority of their orbs at all. Instead, the system would open them behind the scenes and deliver the contents with no user interaction required at all. Players would only need to open the most high value (read: exciting!) orbs according to their current progress, or orbs where they wanted to opt for partial or iterative opening.

This was my favorite solution, as it would cut the problem out at the root and have a major impact on the player experience.
However, it was also fairly expensive to build, and the most experimental, so it would be difficult to build consensus around.

• Deferred-Open

The little cousin of auto-open, deferred open would be an opt-in system. If faced with a huge pile of orbs a player didn't want to wait for the system to open, they could set it to deferred open, which would send it to a side process on the server which would then return the results within a few hours.

This had the advantage of allowing us to spread the server load out to when it was convenient for the machines to run the process, while also allowing players some agency over the process, depending on how urgent was their desire to open a particular stack of orbs.
The engineers told me this would create extra work to create processes needed, and they also felt they could improve the back end enough that the aspect of spreading the server load might not be needed.

• Improved Loop

My director contributed this solution, which would use the already existing fallback of a single button press that allows opening stacks of 10 at once. By adding an interaction to the results screen that allows the player to open 10 more, they can then repeatedly open 10 at a time with significantly fewer presses, thereby streamlining the process.

By falling back on existing systems, this would be the cheapest and most reliable to implement by far. It also would facilitate certain of the use cases (described above) related to opening small stacks repeatedly, so players could see what they got and then decide to open more.
The main drawback to this is that it would make the least impact on the problem of getting through very large stacks of orbs.

• Added Slider UI

This would add a UI that allowed players to select the number of orbs they want to open, and then the system, using improved back end technology, would process exactly that number.

This would facilitate several of the use cases described above, in particular purchase flows, where players rarely want to spend all their available currency at once. At the same time, the main forward path would have the least amount of friction possible, with the default interaction opening a player's entire inventory with a single tap.
Sliders had been discussed in the past, but no one know how to build a slider that could handle the vast range of values that would be required to handle all cases, so this had some design unknowns associated with it.

Because of the somewhat experimental nature of the auto-open and deferred-open options, I got a few questions put on one of our regular player surveys to see if players saw those solutions as actually addressing their pain points in an acceptable manner.

The results were pretty indifferent, meaning there wasn't a clear mandate for those solutions.

Armed with the breakdowns and proposals above, I presented my case to leadership.

Success! By plainly presenting the use cases, and the carefully researched pros and cons of different solutions, I was able to communicate the value of the user-centered approach, and I was put in charge of development of the feature.

Based on the analysis of the solutions presented, the slider UI was chosen to move forward, with the improved loop as a potential stretch goal add-on.

Remember when I said the unknown quantity with the slider UI solution was developing a slider to handle the vast ranges required? Well, now I was on the hook for delivering just that! Coming up with brand new patterns can be nervous-making, but as a designer, it's the type of challenge we live for!
I studied the problem space and came up with three proposals for the design of this slider. I defined several requirements that any design had to meet:

The slider has to be able to handle large numbers, up to 10's of thousands.
At the same time, it has to be adaptive to any size of range within that upper bound.
And of course it must be super easy to use, so it doesn't cause more friction than it solves.

• Normal Slider

The first possible solution was to simply use a normal slider and dynamically adjust the upper bound to handle as many orbs as necessary. Delving into it, there was enough pixel resolution in the UI to handle selections up into the thosusands.

This would obviously be the most straightforward solution, cheapest to build, and most familiar to users.
It presented significant drawback, though. As the range got larger, it would be harder and harder for users to accurately select the desired value. Fine tuning increment/decrement buttons can help, but the adjustments would not necessarily be a useful amount, based on the size of the range.

• Small Slider with Magnitude Selection

I could solve the problems presented by the dynamic range by using a smaller slider of a fixed size, and adding buttons that would project the selection into the hundreds or thousands. UX best practices are that a slider should have its range set to a scale appropriate to the selection the user will be working with. Dividing the selection into amount times magnitude would allow the UI to follow that best practice while still handling all ranges necessary.

This solved the dynamic range problem well, and was understandable and easy to build.
However, the interaction would be kind of clunky, requiring several interactions of different types to select a single value.

• Quasi-Logarithmic Slider

I found I could get all the values on a single slider, with a single interaction, by dividing it up into sections. Each section would represent a different magnitude, and each notch on the slider would increment an amount appropriate to that section's magnitude. i.e. the first section would select from 10 - 100, with each notch incrementing by 10, the second section would select from 110 - 1000, with each notch incrementing by 100, and so one.

This was an elegant solution that would solve the difficult use case
This was also the riskiest option, as I could not find any similar pattern anywhere in the games space, or even in non-games applications. It would also require our engineers to innovate in order to deliver the solution.

As the feature owner, it was on me to decide which solution to move forward with. I conferred in depth with the engineer assigned to the implementation. He felt confident that he could deliver the quasi-log slider solution, and was excited by the challenge it presented. I felt it was the only solution that truly solved that problem and met the requirements I had defined, so I decided to move forward with it despite the risks.

My preferred methodology would be to create an interactive prototype of this solution to make sure the concept holds up, and then test it on a handful of users to make sure they could complete a set of relevant tasks with it. Or at the very least run it informally by some of my teammates for quick feedback.

However, this was a high priority feature, that was tasked with shipping as quickly as possible. I had already used my good-will within the team to get an expanded feature set on the roadmap with myself running it; I could not justify pushing for this kind of diligence with leadership.

Sometimes we have to recognize the situation we are in and know when to keep pushing, and when we need to move forward using the best assessment we are able to make.

I moved on to developing a complete spec for the full functionality of the feature

(Partial view of spec)

Working with talented development partners that I trusted, the actual implementation of the feature was very smooth. I worked closely with engineers, who did deliver exactly what was specced out. I also worked with a UI artist on our team to get the UI skinned appropriately.
‍

But I wasn't done yet! Since this was a high priority, highly visible feature, whose success hinged on a successful rollout generating positive sentiment, it was imperative that we develop a strong rollout strategy.

I started by working with our engineers and dev ops to craft a release schedule. Despite our engineers' confidence in the new backend technology, we felt it wise to do a staggered rollout to prevent undue server strain as all our players went to use the new feature at once. We had to consider the fact that, with the previous solution turned off for a couple months, many players had stopped opening their orbs, resulting in massive piles of hoarded orbs, sometimes numbering in the tens of thousands. There was a very real risk of the new system taking on an immediate load that was orders of magnitude greater than intended, and causing a devastating failure at launch that we could not afford.

We ended up crafting a rollout that saw the feature release to small groups of players at a time over the course of several days.

How the release was communicated would be important too. We wanted to generate excitement with the player base, to help boost the desired positive sentiment, but we also wanted to be careful not to overpromise, and not to be too specific in details, to prevent a stampede that might, despite the staggered rollout, threaten the health of our servers.

I worked with our community team to craft a blog post on a Friday, announcing a release that would happen the following Monday (though the specifics of the timing were not disclosed).
‍

Due to the vagaries and thrash of development, I ended up negotiating the release of the feature with leadership right up until the last minute. In the ends, it was deemed important enough that we got our own point release, and shipped it live!

Due to our careful planning, the rollout went off without a hitch!

As we watched all channels for player feedback, we saw that the response was enthusiastically positive!

In a live operated game such as this, there is always a certain amount of tension between the developer and the player base. Getting a huge positive sentiment win like this is fairly rare, and very valuable. This feature ended up being an unqualified success.

For a smaller feature like this, it is generally quite difficult to tease out the individual impact in the data, but this feature, along with a number of other efforts going on simultaneously, created a period where all core KPI's increased steadily. In the end, everyone was happy with the process and result of this effort.

A couple key takeaways stood out upon reflection on the entire process:

If you want to improve the UX maturity of your organization, make sure you do the work to show you deeply understand the problem space, and then demonstrate the impact you can make using strong story telling and consensus building processes.

While quality-of-life features might be often overshadowed by more glamorous, large feature releases, they can often punch above their weight in terms of impact delivered vs. cost of development. Try to get a regular cadence of hitting some of these issues on target!