Goals: A Quest System

The Marketing team had a legacy format that required thorough UX planning and UI organization to achieve a flexible system that could accommodate their combinations of options programmatically.

The Product team had a plan to combine short-term and long-term goals that would allow players to track their progress and gain bonuses for milestones. Our team had identified that measurable advancement was an important part of the gameplay experience, and this would reinforce that skill growth.

It was my job to design a quest system that incorporates the Marketing team's plan for scheduled events and the Product team's goals for a user incentivization program. Here's how it went:

The Marketing team had a legacy format that required thorough UX planning and UI organization to achieve a flexible system that could accommodate their combinations of options programmatically.

The Product team had a plan to combine short-term and long-term goals that would allow players to track their progress and gain bonuses for milestones. Our team had identified that measurable advancement was an important part of the gameplay experience, and this would reinforce that skill growth.

It was my job to design a quest system that incorporates the Marketing team's plan for scheduled events and the Product team's goals for a user incentivization program. Here's how it went:

A long time ago, in a version far, far away...

Goals first began life before the addition of the Marketing promotional events, so they were fairly simple to begin with.

Goals V1-V1.1

On the left you can see the original designs for V1, and the same page re-skinned (you can read more about here on the Sunshine case study.)

It was a very straightforward design! A collection of text, progress bar, reward, and a CTA. Easy peasy! The "Weekly Challenge" that you see beneath the goals was a part of the legacy Marketing initiative, and would be rolled into the new promo tool that our engineers were building internally. Until that tool was released, goals were hard-coded like you see here, and we referred to this release as V1.

Goals V2

Here's where the (soy) meat and potatos come in! When Marketing's internal tool was complete, we rolled all of their promotions and events into the goals system as well. This required solving design solutions for four different types of events that Marketing was running:

Basic:

Title & short description
Category
"Progress X of Y" copy
Progress bar
Reward amount
CTA
Optional: time remaining
Optional: additional details
Optional: Daily reset indicator

Bundle:

Title & short description
Category
"Progress X of Y" copy
Progress bar
Reward amount
Number of repeats available X of Y
No CTA - autoclaims
Optional: time remaining
Optional: additional details

Sure! Still not bad. The repeats and changes between manual and auto claim might be a tad hard on player education. If we give them different enough visual differences then players should be able to recognize the patterns fairly easily.

Cluster:

Multiple goals that can be completed in parallel!
Has a parent & children
Children can be bundles / can have multiple repetitions

Parent container

Parent title
Parent short description
Rewards collected so far
Category

Child container

Child title
Child short description
Progress X/Y copy
Progress bar
Reward amount
Number of repeats available X of Y
CTA
Optional: time remaining
Optional: additional details

Chains

Multiple goals that must be completed in sequence.
Has a parent & children.
Children cannot be bundles.
Children can be manual or autoclaim

Parent container

Parent title
Parent short description
Rewards collected so far
Category
Optional: time remaining
Optional: additional details
CTA to show all child goals
Parent CTA

Child container

Child X of Y
Child title
Progress X of Y copy
Progress bar
Reward amount

Oh. Oh my. Alright then!

Something that is helpful to know when designing is that too many options can lead to poor experience and sloppy interfaces.

Here we have two types of goals that look very similar, but have different behaviors. There are different limits on how you complete them and how you collect the reward.

This is where the complex problem solving needed to happen. There was a visual design challenge of fitting all of these attributes into a single, readable card (not to mention the Product request to show as many cards on the screen at once as possible). The usability problem to solve was to use tutorials, popups, and micro-animations to teach players to recognize and understand each quest.

Step 1

Determine what was the minimum necessary information for a player to accomplish a goal, and make all other information progressive or discoverable. Using what I call "just-in-time design", I choose only to reveal the specific information needed for each particular part of the player's journey in completing each goal.

Step 2

Create prototypes of multiple ways to access or discover the extra details if more clarity was necessary. Usability tests will give insight into what questions players are asking.

Two prototypes for interactions. One is an accordion that opens on tap, the other is a button that brings you to the next screen.

Results

Here are the UI kits that were built for the goal cards and their behaviors. Creating a set of definitions for the anatomy of the cards was essential, and helped the engineers with building the elements into collections of components.