Project: Creator Continuum Arena™ Player Registration System

Project Overvuew

A tournament registration form can collect names. A registration system should help operate the tournament. That distinction became the foundation for the Creator Continuum Arena™ Player Registration System. As I developed Arena’s tournament operations, I realized that player registration touched nearly every stage of the event. The information collected before a tournament affects:

• team rosters

• player communication

• platform compatibility

• scheduling

• check-in

• streamer participation

• staff preparation

• match instructions

• results

• post-event reporting

​

Managing those pieces across forms, Discord messages, spreadsheets, and manual staff follow-up could become increasingly difficult as Arena grows. I designed the Player Registration System to turn registration into the entry point of a larger tournament workflow.

 

The project combines:

UX strategy + information architecture + product design + tournament operations + player experience + workflow design + web prototyping

 

I then began translating that system into an actual web prototype using Next.js and a local development workflow.

 

The Problem

Tournament registration looks simple until you consider what happens after someone submits the form.

​

Arena staff still need to know:

• Who registered?

• Which team are they on?

• Who is the team contact?

• Is the roster complete?

• What platform are they using?

• What region or time zone applies?

• Who is streaming?

• Has the team checked in?

• Where should match information go?

• Did the team actually participate?

• How should results connect back to the participant record?

​

If each answer lives somewhere different, tournament operations become increasingly manual.

The challenge became:

How do I design a registration experience that is simple for players while collecting and organizing the information Arena staff need throughout the entire tournament?

 

Project Objectives

The initial objectives were to:

• Create a clearer digital entry point for Arena tournaments.

• Reduce dependence on scattered registration information.

• Structure player and team data around actual tournament operations.

• Make team registration easier to understand.

• Support roster collection and verification.

• Connect registration information with later check-in and event processes.

• Improve communication between players and Arena staff.

• Design around both the participant experience and staff experience.

• Create a reusable structure for future Arena tournaments.

• Identify which operational tasks could eventually be automated.

• Build a prototype before investing in a larger production platform.

• Use early tournaments to determine what the finished system actually needs.

 

My Role

I approached this project as both the Founder operating Arena and the person designing the system that Arena needed.

 

My work included:

• Product Concept Development

• Operational Requirements Analysis

• Player Journey Mapping

• UX Strategy

• Information Architecture

• Registration Flow Design

• Team & Roster Workflow Design

• Tournament Process Mapping

• Staff Workflow Design

• Product Scope

• Feature Prioritization

• Web Prototyping

• Development Environment Setup

• Next.js Development

• GitHub Version Control

• Product Iteration

• Future Automation Planning

 

This meant moving through the project from:

operational problem → user journey → product requirements → interface structure → prototype

rather than starting with technology and trying to find a use for it afterward.

 

Why I Did Not Just Design A Form

A basic tournament form can collect:

Name
Email
Username
Team

 

But that does not solve the operational problem. Arena needs registration information to remain useful throughout the event. I therefore approached the product as a system connecting:

Registration → Readiness → Check-In → Tournament Participation → Results

 

The question was not simply:

What fields belong on the page?

​

It was:

What information will Arena need later, and how should the registration experience prepare both the player and the staff for what happens next?

​

That decision fundamentally changed the product.

 

The Player Journey

I mapped the broader Arena participant journey as:

Tournament Discovery

↓

Registration

↓

Team / Roster Information

↓

Confirmation

↓

Pre-Event Communication

↓

Check-In

↓

Match Instructions

↓

Competition

↓

Result Reporting

↓

Tournament Progression

↓

Final Results

↓

Post-Event Feedback

​

Registration sits at the beginning, but the information collected there influences nearly everything that follows.

 

Information Architecture

I worked backward from the information Arena staff would need to successfully operate an event.

That produced several major information categories.

 

Player Identity

Potential information includes:

• gaming handle,

• contact information,

• Discord identity,

• relevant player information,

• and event participation status.

 

Team Information

Team-based tournaments create additional requirements such as:

• team name,

• team leader/contact,

• roster members,

• roster completeness,

• substitutes where applicable,

• and team branding.

 

This information needs to remain organized as one team rather than becoming disconnected player submissions.

 

Competition Information

Arena may also need:

• tournament selection

• game

• platform

• region

• team size

• event requirements

• and eligibility information

​

Collecting this early helps reduce operational issues later.

 

Scheduling & Readiness

Tournament staff may need information relating to:

• time zone

• event availability

• registration status

• roster readiness

• check-in readiness

​

These requirements became part of the larger product model rather than being treated as separate administrative tasks.

 

Creator & Streamer Information

Arena also includes creator participation. For tournaments that require designated streamers, the registration system needs to account for information such as:

• which players are designated creators

• streaming platform

• channel information

• participation expectations

​

This connects tournament registration directly to Arena’s creator-activation strategy.

 

Team-Based Registration Design

One of the important product questions was determining how team registration should work. A team tournament is different from five unrelated players filling out five unrelated forms.

 

The system therefore needed to support the idea of:

Team → Team Contact → Roster → Individual Players

​

rather than treating every participant as an isolated record. That creates a clearer operational relationship between:

• the team

• its members

• Arena staff

• the tournament

 

Designing the Registration Flow

The prototype was structured around breaking registration into understandable steps instead of confronting the user with one long administrative form.

 

The flow was designed around areas such as:

• Tournament Selection

• Understanding which event the team is entering

• Team Details

• Establishing the team’s primary identity and contact

• Roster

• Adding the players participating in the event

• Event Information

• Collecting relevant competition details

• Review / Confirmation

• Allowing the information to be checked before submission

• Breaking the process into stages makes a more complex registration task easier to understand

 

UX PRINCIPLES

Several principles guided the product design.

 

CLARITY

Players should know exactly what they are registering for and what is required.

 

PROGRESSIVE DISCLOSURE

Information should be requested in logical stages rather than overwhelming the player with everything at once.

​

PREDICTABLE NEXT STEPS

The user should understand what happens after registration.

​

OPERATIONAL RELEVANCE

Every important data point should exist for a reason.

 

REUSABILITY

The system should eventually support multiple Arena tournaments rather than being designed exclusively around one event.

 

PLAYER-FIRST LANGUAGE

The interface should make sense to participants, not only to the staff members who designed the tournament.

 

Designing for Staff As Well As Players

One of the most important product decisions was recognizing that the registration system has two users:

 

The Player / Team

Needs a simple and understandable experience.

 

Arena Staff

Needs structured and actionable information.

​

A beautiful registration interface would still fail if staff had to manually reorganize everything afterward. That required thinking about:

• how information is grouped

• how teams relate to players

• how staff identify incomplete information

• how registration connects to check-in

• and how the data may eventually support tournament administration

 

From Operations to Product Requirements

Arena’s tournament planning helped establish requirements such as:

• team registration,

• roster management,

• platform information,

• region and time-zone information,

• registration deadlines,

• check-in,

• communication,

• streamer participation,

• match setup,

• result reporting,

• and tournament progression.

 

I began translating those operational requirements into product behavior.

This was an important transition:

Manual Process → Defined Workflow → Digital Product

​

The system became a way of formalizing how Arena itself operates.

 

Building the Prototype

After defining the user journey and requirements, I moved beyond documentation and began building an early web prototype. The prototype development environment included:

 

Next.js

Used to begin building the web-based registration experience.

 

GitHub

Used to establish version control and preserve development progress.

​

Node.js / npm

Used to support the local web-development workflow.

 

VS Code

Used as the development environment while building and testing the prototype. This was my first step toward converting Arena’s operational system into a functional digital experience.

 

Learning Through Development

Building the prototype created a different kind of feedback than planning the system on paper.

Once I began translating the registration journey into screens and components, I had to make more concrete decisions around:

• page structure

• navigation

• form progression

• terminology

• information hierarchy

• what belonged together

• what should happen first

• what could wait until later versions

​

That process reinforced an important product lesson:

A workflow can sound clear in a document and still need to change once someone actually has to use it. Prototyping helped expose those decisions earlier.

 

Scope Control

Arena could eventually require a much larger technology platform. Potential future systems include:

• persistent player profiles

• team profiles

• tournament registrations

• check-in

• queues

• scheduling

• brackets

• match communication

• result reporting

• notifications

• tournament history

• staff dashboards

• payment processing

• Discord integration

​

Building all of that at once would have dramatically increased the complexity of the first version.

I instead focused the prototype around a smaller question:

Can we create a better structured entry point into Arena tournaments first?

​

That allowed the product to remain useful without attempting to solve every Arena technology problem immediately.

 

Build VS. Platform Decision

An important part of product development is knowing when not to keep building everything from scratch. After developing the initial Next.js prototype, I later evaluated whether Arena needed a fully custom-coded production registration platform immediately. I decided that the near-term production workflow could instead move toward a website platform such as Wix while the underlying product model continued to evolve through live tournament testing. The Next.js prototype was retained as:

• proof of concept

• product-development experience

• portfolio work

• evidence of how the registration workflow could function digitally

​

This was not abandoning the product. It was a scope and resource decision. The goal is to use the simplest technology that can reliably support Arena’s current stage, then increase technical complexity when actual usage requires it.

 

Validation Before Overbuilding

The next tournaments provide an opportunity to learn what the registration system actually needs before investing heavily in a larger custom platform. Areas to evaluate include:

• registration completion

• incomplete registrations

• roster problems

• staff follow-up requirements

• check-in issues

• player questions

• communication gaps

• data staff repeatedly need

• information collected but never used

• features participants actually request

​

Those observations can inform the next product version.

 

Free Events As Product Research

Arena’s early free tournaments are useful not only for validating the tournament model but also for validating the registration system. They provide an opportunity to study:

• Where do users struggle?

• What does staff repeatedly have to fix manually?

• What should be automated?

• Which information needs to persist between tournaments?

• What becomes necessary once tournaments become paid?

​

That makes the tournament itself part of the product-development process.

 

Future Paid Registration

Arena’s longer-term plan may include paid tournament participation after the early free events validate the model. That creates additional future requirements such as:

• payment processing

• transaction status

• registration confirmation

• refunds

• cancellation handling

• player accounts

• policies

• stronger administrative controls

​

Rather than building those systems before they are needed, the product roadmap allows them to be added when Arena reaches the appropriate stage.

 

Future Player Profiles

One longer-term direction for the registration system is the possibility of persistent Arena player profiles. Instead of entering the same information for every tournament, a future player account could potentially support:

• identity

• platform information

• team history

• tournament registrations

• participation history

• results

• creator/streaming information

• and future Arena activity

​

This would shift the product from:

Tournament Registration Tool

​

toward:

Arena Player Platform

​

That represents a future direction rather than completed prototype functionality.

 

Automation Opportunities

The product also revealed several opportunities for future automation. Potential examples include:

• registration confirmation

• missing-information reminders

• roster verification

• check-in status

• event reminders

• staff notifications

• tournament updates

• match instructions

• result reporting

• player history

 

Automation can reduce repetitive staff workload while maintaining human oversight where judgment is required.

 

Connection to Discord

Because Creator Continuum Arena operates heavily through community infrastructure, the registration system also has potential to connect with Discord. Future possibilities could include:

• account identification

• event-role assignment

• registration confirmation

• team communication

• check-in notifications

• match notifications

• and tournament updates

​

These remain future integration opportunities rather than completed prototype functionality.

 

PRODUCT & BUSINESS VALUE

The registration system is not valuable simply because Arena can say it has a website.

 

The real potential value comes from improving:

PLAYER EXPERIENCE

Clearer registration and expectations.

​

STAFF EFFICIENCY

Less scattered information and repetitive follow-up.

​

DATA QUALITY

More consistent player and team information.

​

EVENT READINESS

Better understanding of who is actually prepared to participate.

​

REPEATABILITY

A structure that can support more than one tournament.

 

MEASUREMENT

Cleaner participation information for evaluating Arena programs.

 

FUTURE MONETIZATION

Infrastructure that can eventually support paid tournament registration if the business model is validated.

 

Selected Work & Deliverables

Product Strategy

• Registration-system concept

• Product scope

• Feature prioritization

• Future roadmap

​

UX

• Player journey mapping

• Team registration flow

• Multi-stage registration structure

• User-language decisions

• Progression logic

​

Information Architecture

• Player information

• Team information

• Roster structure

• Competition data

• Scheduling/readiness information

• Creator/streamer information

​

Tournament Operations

• Registration requirements

• Check-in relationship

• Staff information needs

• Communication requirements

• Results workflow connection

​

Web Development

• Next.js prototype

• Local development environment

• GitHub repository workflow

• Node.js/npm setup

• Interface prototyping

​

Product Evaluation

• Build-vs-platform decision

• Prototype preservation

• Future Wix implementation direction

• Live-event validation strategy

​

Future Systems Planning

• Player profiles

• Staff dashboards

• Automation

• Discord integration

• Paid registration

• Tournament history

 

Current Outcome

The Creator Continuum Arena™ Player Registration System currently exists as an early working prototype and product-design foundation. I do not present it as:

• a fully deployed production application

• a completed player-account platform

• a finished tournament-management system

• a validated paid-registration product

​

The major outcome so far is that a previously manual tournament requirement has been transformed into:

• a defined user journey

• structured information architecture

• team-based registration model

• operational workflow

• digital product concept

• working web prototype

• technical development experience

• roadmap for future Arena infrastructure

​

The prototype is also preserved as part of my professional portfolio while Arena’s production registration approach continues to evolve.

 

What This Project Demonstrates

Product Strategy

Identifying a real operational problem and defining a focused digital solution.

​

UX Strategy

Designing around what players need before, during, and after registration.

 

Information Architecture

Determining what information should be collected and how it relates to later tournament operations.

 

Systems Thinking

Connecting registration to rosters, check-in, communication, competition, and results.

 

Web Prototyping

Moving from documentation into a functional Next.js prototype.

​

Technical Learning

Establishing and working inside a modern local development and version-control environment.

​

Product Scope

Separating what is necessary now from what belongs in later versions.

​

Operational Technology

Using digital systems to reduce friction inside real-world event operations.

​

Product Decision-Making

Recognizing when a custom build creates value and when an existing platform may be more appropriate for the organization’s current stage.

​

Iterative Development

Using prototype work and live-event testing to inform future product decisions.

​

Founder-Led Product Development

Moving from identifying the organizational need through workflow design, prototype development, technology evaluation, and product roadmap planning.

 

The Bigger Picture

The Arena Registration System started with a practical problem:

How do we register tournament players more effectively?

​

But designing it exposed a much larger opportunity. Registration is the first digital interaction many players may have with Arena. If that system eventually connects:

identity → teams → tournaments → check-in → results → participation history

​

then registration becomes the foundation of a much larger player experience. The prototype represents the first step toward that possibility. Not technology for the sake of technology. A digital system designed around how the tournament actually works.

 

Creator Continuum Arena™ Player Registration System

UX Strategy • Product Design • Information Architecture • Web Prototyping • Tournament Technology • Systems Thinking

*NOTE: Working Prototype / Continued Development*