Beta Registration & Invites

Growing a user base through an invitation only experience, sent from a known and trusted community member.

Problem Statement

What gets players hyped to play together? Shared experience and community!

To create hype around their launch on Playstation and XBOX, VALORANT wanted to drive engagement through trusted relationships.

Historically, Riot was primarily a PC player audience, and this experience was tied to VALORANT'S launch on console play, and expanding to that player-base.

Value Proposition

The case theory was playing together with people you know, would:

Drive users previously unable to play the game, to get a first time experience together with people they trust, and/or want to with.
Valorant has a strong community, so new users, increases that community/user-base
The ability to play with friends likely means happy users, and an increase in engagement time for all parties involved.
Happy users = user growth and retention.
Increased engagement + happy new and existing users = increased revenue.
Increased revenue = creating new cool experiences for players moving forward!

Future Offerings

Additionally, our goal was for this to serve as a test case towards future offerings.

After VALORANT, we would be supporting the Alpha launch of 2XKO follow a few months later.

The more re-usable and scaleable we could make this, the lower the cost and effort might be when launching 2XKO.

Challenges

How can we make the experience consistent across products, given we’ll need to adhere to guidance and requirements from external platform partners?
What does the process looks like from initial sign up, through an invited friend obtaining access?
How do we inform users about what they are signing up for? Does that model change for a new game vs an existing one with an established brand and user base?
What's the best way to minimize friction, getting players invites, and quickly into game?
Is there a scalable process that creates continuity of experience across games, while allowing game teams to customize their own processes?

Audience

Who are we designing for?

Primary Audience

Game Teams

VALORANT

Players

Current Players who also have an XBOX and/or Playstation account
New players with an XBOX and/or Playstation account
Players with an XBOX and/or Playstation account invited by a registered friend.

Secondary Audience

Future Game Teams

2XKO

Project Roles

Who was involved in getting this to the finish line?

Cross-team Collaboration

Program Manager
Product Managers (Multiple Teams)
Game Team Brand Managers
Design Lead
Visual Design Lead
Epic Captain
QA Leads (Multiple Teams)
Copy Writers (Multiple Teams)

Stakeholders

VALORANT
Player Platform Teams (SDK, Marketing, InfoSec etc)
External Console Partners (XBOX + Playstation)

Project scope

What do we need for a frictionless and trusted experience, providing key information to users?

Work across teams to create a scalable web solution that aligns with game team needs and partner guidelines.
Create a dual registration and marketing page, and simplify inviting friends.
Deliverables including UX website and email mocks with annotations, E2E user flows, and functional flows, User copy and SOT repo.
Flows need to account for current and new players, as well as established and new linking of console to Riot accounts.

Pivot - Granting Access

Shortly before UX lock, we got feedback from one of our partners changing how we could grant users access to the game.

This forced an emergency pivot to reassess our flows, though fortunately we were able to still deliver the feature on schedule.

Approaching The Work

How do we make the traditional beta experience unique and branded for a live game with a passionate community?

This was a fast moving process with a live game, establishing its first footprint on consoles.

Before engaging with VALORANT we researched what is typically part of the marketing/sign up page of other of beta experiences.

There were also cross-discipline conversations around “how” to minimize friction within the sign up / acceptance / invitation processes.

Starting Point

Simple flow, marketing the game

We'd create a marketing page with game specific content that doubled as the start of the sign up flow.

Find ways to reuse elements and processes for both the initial registration and invitation acceptance flows, reducing potential unnecessary extra work.

Key Event Details

We knew the core pieces of information users needed front and center were how to register, key dates, and how you could play.

Simple Sign In

To reduce as much friction as possible for users, the plan was completing any pre-requisites within the initial registration flow, using our systems to validate user access.
This way when invitations were sent out users could just download the game, sign in, and start playing.

Invitation Flexbility

Users granted access after registration were presented with a code to send to friends, so they could play together.
These were essentially pre-auth codes, allowing the friend to use the code to login or sign up for an account, with immediate access to download the build. To simplify sharing, we emailed the code to the registered user, who could send the code via slack, email, text, to whomever they wanted.

New players don't feel left out

Part of the goal was to expand the existing user base.
We worked with the game team to provide relevant content on the registration page, for new users could easily learn about the game before playing.

Branded Marketing Elements

We presented the potential options how we could include their marketing content on the landing page, appealing to new and existing users, including “how to” written tutorials, and “hype videos”.
We also created a standalone FAQ information section about this limited experience, as well as general game info.

Designing The Experience

Multiple User Situations

User Flows

Multiple user paths needed to be accounted for, which takes into account the users account status, if they were logged in, invited etc.
E2E flows contextualized how users would interact with each step, including any emails that we send out.
To keep costs down, the plan was to reuse pages where possible (Ex a user trying to redeem an invite that has already been consumed, would be sent to the registration flow.)

Multi-Functional Hub

Registration + Game Information

The registration page doubled as a marketing page. reusable for multiple situations with easy access to information about the experience, and general game info.

Masthead is kept simple and clean, focusing on the priority of registration.
Wanting to reuse the page, this button could double for accepting an invite. This meant content continuity for users, and reduced cost to make changes between user scenarios.
Additional "where" and "when" details easily found just below the header section.
Game marketing content linked out for users to learn about the game and experience.
FAQ info is kept to high level info so the user isn't overwhelmed, and content links out to articles for more detail.

Accepting Access

Using our system logic

Once the account is logged in, we could use existing information about the player within their account to guide next steps.
Users could only play on once console and codes were platform specific.
If a they selected a console with a pre-connected account, they were sent to the success screen to obtain their access code.
Without a pre-connected console, they would be sent to the flow to connect that account, before returning to the success screen.

Inviting Friends

Security = potential scope creep

To deter bad actors, and further streamline things, I explored the option of sending invites through account management.
The primary upside was improving our ability to troubleshoot invitation issues, making things easier for users and player support.
However that would have greatly increased the project scope, so for MVP we included a sharable code on the invitation acceptance success screen.

Invited by A Friend

Wanting to reduce the potential for bad actor fraud, I explored the option of Riot controlling the inviting of players. However, we lacked the existing capability to send invitations within system, and to achieve that would have greatly increased the project scope.

So we landed on a simple solution to include a sharable code on the invitation acceptance success screen,trusting users wouldn't abuse the system.

Accepting An Invite

Invited friends would follow the same flow logic as the initial registration, but would bypass any waiting period to access the game.
This would reduce completion timeline by reducing the need to create unnecessary standalone pages.

Handoff Collaboration

Work was being handed off across teams and disciplines, so proper organization of assets was key.

UX designs were handed off to VD, which included individual screens and complete flows with annotations, and links to the project brief.
I helped organize the collaboration between our initiative copy writer and VALORANT'S, including who was responsible for what content.
To create a clear source of truth for copy and the latest mocks, I spun up a new content repo in Notion, linked to it from Figma and added the latest content in both locations.
Using notion provided a clear historical ledger of update work, in a universal and accessible location for all disciplines.

Final Thoughts

Broad project results

Growth Achieved

Direct increases for user base, time in game, and revenue.

The project launched on time and was a huge success, and no surprise, players invited by a friend spent more time playing the game together.
It can be challenging to sync up and play together, and this method provided a method to connect in game, and momentum or an incentive to stay in game.
Despite the emergency pivot, we were able to quickly align on a solution that could be implemented without changing timelines. The intended path would have simplified the process and reduced a little friction, but the bare bones goals of the MVP were ultimately achieved.

What would I have done differently?

Secure Invites

Increased trust around invite consumption

There was a concern bad actors could try to sell an invite on social media, and getting multiple people to pay for a code that has already redeemed.
This would create negative user sentiment, and player's would direct their frustration towards the brand, particularly as Player Support didn't have an easy way to reverse engineer a fix.
Running the invite process run through our systems to increase security, was something I explored and would have preferred.
After some discussions we decided a trade-off was required to keep the timeline in tact and not increase scope.
To get the MVP out the door, we would present users a sharable code on the success screen, and revisit invitation by Account Management down the line.

Entitlement vs Keys

Innovate to improve our users experience

Our initial aligned on plan was to leverage our entitlements systems, to validate user access within the registration flow.

Connecting your console and Riot accounts was required to play, and we wanted to include this check in the registration process. By controlling access, we could instantly see connected accounts.
This would also reduce user friction by letting users with pre-connected accounts skip that step, while prompting others to finish the setup early so they could jump into the game when invited.

Hang on a second - we can't do that

Just before locking UX, we got feedback from partners and stakeholders forcing us to pivot to unique-access keys entered into the platform store, to download the game.

This meant revising our flows to reflect the updated requirements, while adding as little friction as necessary.

Connecting your console account became an optional step at the end of the registration flow, or a pre-requisite to obtain a key once invited.
Upon accepting an invitation, a pre-connected account would just need to select that platform, to be sent to the success screen for the specific key.
Requiring beta codes meant we couldn't then grant access upon login, making us reliant on users inputting codes into the store redemption flow to download the build.
Though this might add steps and remove some of our control from the process, it was required by our partners, and though this is how other games operate, we took a shot at improving the experience for our players.

Project Coda

Pivots are inevitably part of the process, but ideally earlier alignment conversations could have helped avoid the change in this project. Our initial plan would have been good for users, but assessing it’s viability earlier on could have resulted in more time to assess alternate paths.

Future scalability was a good thought, and with more time and information, we might have created a stronger future proof version. How that played out for 2XKO is a different, future story to tell.

Despite twists and turns, we were successful in delivering the feature in the required timeline, while creating a huge value for the game team.