Driving Engagement and Valuation Through Challenge-Oriented Experiences

Setting the Stage

Challenges with a Textured Loyalty Framework

In a loyalty platform, there are a lot of ways to build a framework for valuating customer behaviors. And many companies build theirs around an easy to understand transactional mechanism — for example, buying coffee to build value as a customer.

On Liquid+, the valuation framework is however a little more complicated than “buy something, get something.” Fans build value by engaging with Team Liquid on digital services, rewarding them for many activities/actions they were already doing as fans

This approach creates a lot of texture around what value looks and feels like, but also creates a few challenges for an engagement-driven user experience:

• The variety of actions that exist make it harder for fans to know how to be successful.
• Some actions have the potential to be high-volume, and need to be valued low. But doing so creates a weak engagement incentive for these actions.
• Unstructured actions (those that exist without contextualization) don’t create strong motivations to engage with the org.
• Unstructured actions also don’t help to build positive and meaningful engagement behaviors.
• Rewarding unstructured actions is a brittle value differentiator for when other orgs develop their own platforms.

There are also two important reasons why this scenario existed…

Why this Approach was Chosen

At the heart of Liquid+ were two overarching goals guiding the project.

Quests as a Unified Solution

Every project is a little different when exploring the problem space. With Liquid+, when we considered the main goal of the project with the challenges the valuation framework we wanted would create,

we quickly realized that a single solution could be used to create a valuation experience that both motivated and drove engagement, and also helped fans succeed in their efforts.

That framework was Quests.

Quests are a universal engagement mechanism in gaming — they are great vehicles for storytelling, driving engagement, tracking progress, and rewarding users for their effort. And Liquid+, they would enable many different benefits:

Most of these benefits can be encapsulated by a few core outcomes that the team wanted to see. Quests would be successful if:

1. Fans were excited about completing challenges.
2. Fans easily knew how to complete a challenge.
3. Fans easily knew where they are within a given challenge.
4. Creating and managing challenges (for staff) was easy.

But there’s one very important detail needed to meet these outcomes. In order to sustain fan engagement and satisfaction in a long-term live-service model, there had to be enough texture so that Quests wouldn’t become stale. And as a result,

Quests needed to be a highly configurable, and complex feature.

And it was clear that my biggest challenge would be breaking down complexity into its clearest form in order to create a simple and easy-to-use experience for everyone.

A Short Note on Constraints

Before diving in, there are some important constraints that existed that shaped how I approached this part of the project:

• Early on, it was decided that Liquid+ had to be “first to market.” The hyper-compressed timeline that resulted however meant that I often had to rely on market and secondary research to guide my efforts in order to keep pace with deadlines.
• Before the beta, many decisions around live content had to be made without the guidance of a dedicated team (formed just before the beta).
• COVID required us to park live/in-person ideas mid stream to change focus until the pandemic subsided.

Designing a Simple Fan Experience that Drives Success

From the perspective of a fan, knowing how to complete a Quest successfully meant being able to answer any question they might have along their journey. And as we worked through the complexity of the feature, there were several that needed answering:

• What challenges are available?
• How long do I have to complete a challenge?
• How do I complete a challenge?
• Where do I go to complete a challenge?
• How will I know that I’ve completed a challenge?
• What do I get for completing a challenge?
• How close am I to completing a challenge?
• What do I need to do to collect a reward?
• Have I collected my rewards?

To help answer these questions, I started organizing my approach by getting more context around how challenges were built in the gaming world. With an already complex framework, we wanted to leverage the mental models that gamers already had with Quests to make them easier to learn.

The most important thing that I learned was that most challenges — barring some minute differences — primarily revolved around knowing

what action(s) were needed to complete an objective at a specific place to receive a reward.

This basic “needs framework” along with the questions we knew helped to guide my approach.

V1: Challenge-Focused Quests

For the first version of Quests, we wanted to provide a laser-focused experience. So Quests were organized around a single goal that had two possible difficulty levels.

Taking this approach provided some helpful benefits. But the most important one that shaped the user journey was being able deliver a concise, accurate snapshot of a fan’s progress to them:

Another benefit was that it was possible to streamline the number of objective variations around a very small number of design configurations.

Extending the User Journey

Of course, a compact summary couldn’t do everything. Some Quests had more granular details that couldn’t be communicated here. So, to help solve the remaining user needs another step in the user journey was needed.

Designing a dedicated page to handle these needs seemed a natural outcome, but this approach also was the most strategic choice and proved to be the right call once we started getting real user feedback.

Feedback in the Beta, and Adjusting our Approach

During the Beta we received a lot of great feedback. But some of it showed that there were a few issues to resolve.

• For fans, certain challenges just weren’t that fun (fan vs fan).
• Some variations of Quests encountered legal hurdles that were too challenging.
• The content team found that working with such a focused end-result made it harder to deliver more interesting experiences to fans.

Taking all of this feedback into account, we decided to perform a major refactor of the Quest feature.

V2: Widening the Possibilities for Quests

The biggest objective with refactoring was giving the content team more flexibility to build unique experiences. And we did this by going back and modularizing the entire feature.

Objectives and Rewards were packaged into a new organizational layer called Missions. And Missions differed from the previous experience in three important ways:

• Any number of Objectives could be added to a Mission.
• Each Objective was itself a unique challenge.
• Any number of Missions could exist.

These adjustments transformed quests into a more experiential package and meant that several changes to the fan experience were going to be necessary:

• Because of the multiple layers of progress that existed, exact summaries were now impossible to deliver in a small component.
• Because both Missions and Objectives were now self-contained pieces, I would need to find a way to manage the significant jump in informational complexity for fans.
• The back-end refactoring also created new variations and behaviors for objectives, so I needed to re-examine how progress and state was communicated.

Reorganizing, Adjusting, and Polishing the New Experience

The biggest change to the user journey was that the summary component was only capable of communicating a "fuzzy" context to users. And as a result, the Quest page now became the focal point of the user journey.

Changes to the Quest Page

There were several changes to the Quest page itself. But the most challenging piece was creating the simplest experience with Missions that had multiple Objectives.

Streamlining the Objective Progress Experience

With version 2, there were three types of progression. The first two were relatively simple to craft so that the design itself communicated what was needed to complete that Objective to fans — e.g. its "action context":

With the third version, there were two possible options. Either the design could clearly communicate the action context (1), or, minimize variations (2).

I eventually chose the latter option because it also accomplished two additional goals. First, it simplified the multi-objective design to make it easier to digest. And second, it enabled a much bigger benefit for fans: creating additional informational swim lanes.

Objective Details and Secondary Actions

Another big need was managing the amount of secondary information that could exist when a Mission had many complex objectives. And using disclosure helped to provide a number of important benefits.

First, it maintained the central focus of providing a clear snapshot of all the objectives in a Mission., and provided a clear separation in information hierarchy, helping to streamline and focus the user journey:

It provided a consistent mechanism to deliver secondary information that could have any number of variations (there were 5 in total).

Finally, it also enabled this secondary action to not only facilitate information gathering, but also help fans get to where they needed to go much faster; reinforcing the success criterion to fans:

Outcome and Results

Impact

As Quests are the driving force for engagement on the platform, it has a large influence over the overall success of the product. In 2022, just over a year after the product launched, growth and engagement metrics were in an encouraging place:

• Over 100K users had joined the platform.
• The fan activation rate was 70%, and retention was 99%.
• Engagement on digital platforms increased up to 150%.
• More than 1.6B points were earned by fans, with 12+ users reaching the 1M point milestone.

Future Improvements

As successful as Quests have been, there are several places where improvements could (potentially) be made.

The Power of Quests is Not Being Utilized

A number of Objective variations are not currently being used in part due to bugs, COVID, and the content team’s current approach. And if nothing else, a usability study I conducted suggested that a more in-depth assessment might be valuable in determining if Quests are truly meeting the needs of everyone.

Folding Live Events Back In

While COVID parked our plans for Objectives that incorporated live event features, at some point things will go back to normal and these features should be re-evaluated.

Many Experiential Improvements are Needed

Largely due to the lack of time, but there is a lot of room for many small improvements to the user experience to be made. In particular, providing more robust state tracking for Quest Objectives both for regular users — and especially for those using assistive technologies.

Learnings

I’m proud of the work I did on Quests. But as much as that’s true, there are two big things that I wish I had done differently in retrospect.

Being a Driver for Consensus and Collaboration

Especially early on, efforts around Liquid+ were given to separate teams across the organization. And this led to a number of timeline, communication, and priority challenges for everyone.

In retrospect, I should have better recognized that the team needed to build the right collaborative process more than delivering the highest quality product and carved out more time to drive that result sooner. It sounds a little weird to say not focusing on quality is the right call… but the likely effect would have been more alignment creating more space to do better work overall.

Missed Learning Opportunities

Because of the lighting-fast pace of the project I was constantly handling multiple tasks that were needed very quickly. This was extremely challenging to manage, and an unfortunate side-effect was that I felt overly pressured to deliver work rather than stepping back and contextualizing the problem space a lot more.

Quests for example do a decent job of driving the experience of the service. However, because we didn’t conduct enough primary research around the kind of relationship fans truly wanted to have with us I worry that a number of challenges risk turning into “chores” over time rather than continuing to be a driver for a meaningful and enriching experience.

That said, the great thing about a long-term product is that it’s never too late to make adjustments and learn the right things. And after 2 years in, the team has been adjusting their approach and is in a much better place to make better and better decisions.